Prototipo · Versión preliminar: todos los servidores del registro oficial, sincronizados cada 30 minutos. Las reseñas y las cuentas llegarán en una etapa posterior.
PopNx MCPServidores MCP para quienes usan IA · explicados con palabras sencillas

ImageStep

de imagestepversión 0.2.1i★ –iComputadora o nube
Nombre en el registrodev.imagestep/mcp

Instalar

Resumen

Descripción del creador (original en inglés)

The image pipeline for agents: presets, assets and jobs. Answers with asset ids and stable URLs.

Los tres pilares de PopNx MCP

Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.

Qué puedes hacer con él

Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.

  • Conexión: Computadora o nube
  • Transporte: stdio, Streamable HTTP
  • Categoría: Diseño, imágenes y audio
  • Debes completar: IMAGESTEP_API_KEY, Authorization

Instalación

Elige la app de IA que usas y copia la configuración.

Antes de instalar

Los valores marcados como secretos son llaves de tu cuenta. Nunca los compartas ni los pegues en un chat.

Necesitas

¿Qué app usas?

Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.

Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.

O ejecútalo en tu computadora

Abre Claude Desktop → Settings → Developer → Edit Config y pega esto en claude_desktop_config.json

{
  "mcpServers": {
    "imagestep": {
      "command": "npx",
      "args": [
        "-y",
        "@imagestep/mcp"
      ],
      "env": {
        "IMAGESTEP_API_KEY": "your-value"
      }
    }
  }
}

Ejecuta esto en tu terminal

claude mcp add --transport http imagestep https://mcp.imagestep.dev/mcp --header 'Authorization: your-value'

O ejecútalo en tu computadora

claude mcp add imagestep --env IMAGESTEP_API_KEY=your-value -- npx -y @imagestep/mcp

Completa los valores vacíos antes de ejecutarlo.

Abrir en Cursor

O copia la configuración tú

Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json

{
  "mcpServers": {
    "imagestep": {
      "url": "https://mcp.imagestep.dev/mcp",
      "headers": {
        "Authorization": "your-value"
      }
    }
  }
}

O ejecútalo en tu computadora

Abrir en Cursor

O copia la configuración tú

Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json

{
  "mcpServers": {
    "imagestep": {
      "command": "npx",
      "args": [
        "-y",
        "@imagestep/mcp"
      ],
      "env": {
        "IMAGESTEP_API_KEY": "your-value"
      }
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Abrir en VS Code

O copia la configuración tú

Pégalo en .vscode/mcp.json de tu proyecto

{
  "servers": {
    "imagestep": {
      "type": "http",
      "url": "https://mcp.imagestep.dev/mcp",
      "headers": {
        "Authorization": "your-value"
      }
    }
  }
}

O ejecútalo en tu computadora

Abrir en VS Code

O copia la configuración tú

Pégalo en .vscode/mcp.json de tu proyecto

{
  "servers": {
    "imagestep": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@imagestep/mcp"
      ],
      "env": {
        "IMAGESTEP_API_KEY": "your-value"
      }
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.

Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.

Valores que debes completar

  • IMAGESTEP_API_KEY secreto obligatorio env
    An ImageStep API key, created at https://imagestep.dev/keys?utm_source=mcp-registry&utm_medium=registry-entry
  • Authorization secreto obligatorio HTTP header
    Bearer followed by an ImageStep API key, created at https://imagestep.dev/keys?utm_source=mcp-registry&utm_medium=registry-entry

Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.

Qué puede hacer

Todavía no hemos leído la lista de herramientas de este servidor; revisamos los endpoints por turnos.

Revisiones básicasi

Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 6 nov 2026

  • ✓ Superada

    El creador coincide con el repo

    El nombre en el registro se verificó con el dominio imagestep.dev (el registro comprueba quién es dueño del dominio)

  • … Aún sin revisar

    Sigue en mantenimiento

    Todavía no hemos leído este repo en GitHub

  • … Aún sin revisar

    Tiene licencia

    Todavía no hemos leído este repo en GitHub

  • … Aún sin revisar

    El endpoint responde

    Aún sin revisar; revisamos los endpoints por turnos

  • … Aún sin revisar

    Inicio de sesión con OAuth

    Aún sin revisar; revisamos los endpoints por turnos

  • … Aún sin revisar

    Sin instrucciones ocultas en las descripciones de herramientas

    Aún sin revisar; leemos la lista de herramientas cuando revisamos el endpoint

Comparado con otros en Diseño, imágenes y audioi

  • Más estrellas que el 0% de los otros 2182 servidores de esta categoría
  • Publicado en el registro más recientemente que el 73% de los otros 2182 servidores de esta categoría
  • Revisiones básicas iguales o mejores que el 100% de los otros 2182 servidores de esta categoría

Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.

Preguntas frecuentes

¿Es seguro ImageStep?

Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.

¿Qué claves o códigos necesita?

Debes completar: IMAGESTEP_API_KEY, Authorization

¿Se ejecuta en mi computadora o en la nube?

Funciona de las dos formas: instálalo en tu computadora o conéctate a la versión en la nube.

¿Sigue en mantenimiento?

El repo de GitHub cambió por última vez –, y la última versión (0.2.1) llegó al registro hace 11 días.

¿Qué apps pueden usarlo?

Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. Se conecta por URL, así que también funcionan las apps que aceptan servidores MCP remotos, como ChatGPT en modo desarrollador.

¿Qué puedo usar en su lugar?

En la misma categoría: Figma Context MCP, Claude Real Video, Figma MCP Server

Alternativas

Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.

Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi

Give your coding agent access to your Figma data. Implement designs in any framework in one-shot.

Se ejecuta en tu computadora★ 16.165MITActualizado hace 5 meses
Instalar

Claude Real Video

de HUANGCHIHHUNGLeo

Let any LLM watch a video locally — and search everything it has ever watched.

Se ejecuta en tu computadora★ 2284MITActualizado hace 2 meses
Instalar

The Figma MCP server brings Figma design context directly into your AI workflow.

Se ejecuta en la nube★ 2152Actualizado hace 13 meses
Instalar

README del creador

Abrir el README

Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.

@imagestep/mcp

The image pipeline for agents: presets + assets + jobs, as MCP tools. Images never enter the context window — every tool takes and returns asset references (ids, sizes, public URLs).

ToolWhat it does
generateprompt → image(s); returns asset ids + CDN URLs. preset runs it through a saved preset whose subjects keep a character or product identical across a batch (slug@version to pin)
transformone atomic op — every op in GET /api/v1/ops but generate, read at startup (stdio) or per request (hosted), falling back to edit remove_bg upscale restore_face colorize analyze resize convert compress crop pad grayscale rotate flip flop trim flatten adjust mask blur_region overlay caption render_template read_metadata when the catalogue cannot be reached. render_template takes no images — parameters: {templateId, items}, one PNG per item. variants (≤ 20) runs the op once per variant in one job, every social size from one call. Two modes, chosen by the input — see below
run_presetrun a saved, versioned preset — a list of steps, by slug or slug@version (the way to chain ops and keep batches consistent)
job_statusper-item progress + outputs of a job (an analyze job answers with analyses). A write tool whose wait_seconds runs out returns the job handle with timedOut: true — not an error: the job keeps running and is charged for what completes, so poll this instead of submitting again. Read-only by default: pass publish: true to publish the outputs and get their public URLs. An answer carries at most 20 outputs (search_assets' page; past that outputsTruncated / outputsNote say to read on with search_assets {job_id, cursor}) — publish: true still publishes all of them. Items come a page at a time (the service's page): past the first, itemsCursor goes back as items_cursor for the next, and items_status (FAILED: what a resume would run again) reads only the items in one state; a chain item carries step / failedStep
search_assetsfind assets by collection, keyword, mime, size — or, with group_by: "collection", list your collections. One page per call; the answer's nextCursor, sent back as cursor, reads the next
save_presetsave a chain you will run again as a named, versioned preset — L1 op steps only, checked by the service before anything is stored; answers slug@version for run_preset to run pinned
send_feedbackreport what ImageStep could not do (capability_gap · bug · other) instead of working around it — free

Every tool declares an outputSchema: the keys it can answer with in structuredContent, all optional (which ones come back depends on the mode — a finished job, a wait that ran out, a dry run, a synchronous result, a refusal).

Inputs are asset_ids, urls (public http(s), fetched and ingested by the service — never downloaded by this server) or — when the server runs on your machine over stdio — file_paths. Every tool that spends money has dry_run (exact price, nothing created or uploaded — asset_ids are priced as themselves, file_paths / urls by how many) and returns structured errors with retryable, param and the service's requestId (quote it when reporting a failure), so a parameter mistake is refused before any credit is charged.

file_paths are files on your machine, and the agent naming them may be following an instruction it read in a page or a mail, so the server checks each one before reading a byte of it:

  • a path through a hidden file or folder — any name starting with . (~/.ssh, ~/.imagestep, .env) — is refused, also when a symlink leads there; ./ and ../ are resolved first;
  • when your client declares MCP roots, only files under them are read; when it declares none, IMAGESTEP_MCP_FILE_ROOTS (folders separated like PATH) does the same job; with neither, any other folder is readable;
  • roots are compared on real paths, so a symlink inside a root cannot lead out of it.

A refusal is invalid_param on file_paths and names the path by its index, never its contents. And a job over local files does not publish its outputs unless the call says publish: true — publish defaults to on only when the inputs are asset_ids or urls (and for generate).

The write tools (generate · transform · run_preset · save_preset · send_feedback) take an optional idempotency_key. An MCP client that times out makes the agent call the tool again; with the same key and the same arguments that second call returns what the first one answered — the job it created, the preset it saved — instead of submitting (and charging for) another. The same key with different arguments is refused with idempotency_key_reuse. Without a key, every call is a new submission.

Every tool carries MCP annotations, the hints a client reads to decide what needs your confirmation: job_status and search_assets are readOnlyHint; the write tools are not idempotent (without a key), and none is destructiveHint: every job writes new assets and never overwrites the one it read.

transform has two modes and the agent does not choose

Synchronous when all of these hold: exactly ONE local file or URL, a deterministic op, and wait: true. Nothing is stored in the account — no asset id exists afterwards, because none was created. Sub-second, and the account stays clean.

Where the result goes depends on which of the two servers you are talking to, because the two do not share a filesystem:

answerlifetime
stdio (this package on your machine)path — a temp file named for what the service says it produced (convert- .avif, not .bin)until the server exits; every result of one server lives in one temp directory
hosted (https://mcp.imagestep.dev/mcp)url — a signed link, plus expiresInSeconds~5 minutes; download it, or run the work as a job if you need a permanent URL

Both carry mimeType, width and height, so the next tool does not have to guess. The hosted answer is a URL for the obvious reason and it took a bug to notice it: your agent is not on the machine the server runs on, so a path into that container's /tmp is an answer it cannot read. Under the hood that is the API's own ?response=url, which writes the bytes to a short-lived temp object — still nothing in your asset catalogue.

As a job for everything else: several images, asset_ids, any AI op, or wait: false. You get asset ids and public URLs, plus progress, cancellation and webhooks.

Which ops may go the first way is read from GET /api/v1/ops (syncEndpoint), never hard-coded — a deterministic op added to the API is fast here without this package changing. If the catalogue cannot be reached, the job path is used: slower is a better failure than wrong.

A urls input is judged the same on both paths: it must resolve to a public address, and it is refused here — before anything leaves the process — not only by the service that would fetch it. One input never gets two answers because of which transport happened to carry it.

Neither mode ever returns image bytes. An image in the context window is tokens the agent pays for and cannot read; the answer is always a path, an id or a URL.

Resources

URIWhat it is
imagestep://opsGET /api/v1/ops as is — every op with its parameter contract (type, default, description), prompt and asset requirements, default model and pricing
imagestep://ops/{op}one op's entry (template; listed per op when the catalogue was readable at startup)
imagestep://models/{mode}GET /api/v1/ai-models?mode= — ai_image or analyze, with prices
imagestep://usageGET /api/v1/usage?groupBy=op — what the account spent over the last 30 days, per op
imagestep://agent-guidelinesthe operating contract (below)

The catalogue resources exist because an MCP-only client (Claude Desktop) cannot curl the API or open the console, and "never invent a parameter" is a rule it can only follow if it can read them. transform also carries a one-line-per-op summary — name(type=default), plus the values a parameter takes when the catalogue lists them, what a required one means, and for an AI op the model's own parameters object — generated from the same catalogue; when that could not be read, it falls back to a built-in summary and says so. All five are read live: a read that cannot reach the service fails rather than answering from a copy.

imagestep://agent-guidelines is the operating contract — read the op catalogue instead of carrying a list, price with a dry run before spending, branch on retryable rather than the status code, keep a batch consistent with a preset, and report a missing capability instead of working around it. It is a resource rather than a tool because a tool is something an agent decides to call and the rules are something it should have read, and it is fetched from the service on every read, so a copy of this package released months ago still serves today's contract.

Connect

Get an API key at https://imagestep.dev/keys?utm_source=npm&utm_medium=mcp-readme.

Claude Desktop (claude_desktop_config.json) — local, can upload files from disk:

{

"mcpServers": { "imagestep": { "command": "npx", "args": ["-y", "@imagestep/mcp"], "env": { "IMAGESTEP_API_KEY": "is_sk_…" } } } }

Cursor (.cursor/mcp.json) — same shape:

{ "mcpServers": { "imagestep": { "command": "npx", "args": ["-y", "@imagestep/mcp"], "env": { "IMAGESTEP_API_KEY": "is_sk_…" } } } }

Claude Code — local:

claude mcp add imagestep -e IMAGESTEP_API_KEY=is_sk_… -- npx -y @imagestep/mcp

Remote (any client that speaks Streamable HTTP) — nothing to install:

claude mcp add --transport http imagestep https://mcp.imagestep.dev/mcp --header "Authorization: Bearer is_sk_…"

The remote server is stateless: each request is served by a fresh server bound to the API key in the Authorization header (Bearer or ApiKey). file_paths is disabled there; pass urls or asset_ids. It logs one JSON line per request on stdout: the JSON-RPC method, the tool name of a tools/call, the clientInfo an initialize reports, your key's prefix (the 12 characters the console shows — never the key), whether the key is valid, the HTTP status and the duration. Never a tool's arguments or your prompt. The validity comes from a side request to the API (3 s timeout, not counted as a use of the key), and the answer, valid or not, stands for five minutes. The handshake never waits for it. A request that can call the API on your key (a tool call, a resource read) does, when the server has not seen that key yet, so a wrong key is turned down there with the same unauthorized error the API gives and never reaches the API. An address whose keys turned out invalid 20 times in a minute gets HTTP 429 with Retry-After for any key the server has not seen yet, until the minute is up; a key it already knows to be good keeps working.

The remote server waits at most 90 s per tool call (wait_seconds above that is clamped; the default there is 90). It answers each call as one JSON body, so nothing reaches your client until the tool returns, and Cloudflare's edge drops a response that has not started after 100 s — you would get an HTML 524 with no job id while the job kept running. Past 90 s you get the job handle with timedOut: true instead; poll job_status. Over stdio the wait is what you ask for (default 180 s, max 600 s).

Try it

Upload ./product.jpg, remove the background, upscale it 2×, and give me the URL.

The agent calls transform (remove_bg, file_paths), then transform (upscale, asset_ids = the previous output, `parameters:

Solo se muestra el principio; lee el resto en el repo

Pregunta a PopNx