MCP o API HTTP: cuándo usar cada uno

AI Tasker publica dos superficies sobre el mismo producto: un servidor MCP con 40 tools y una API REST con un contrato OpenAPI de 102 paths. Esta guía explica qué resuelve cada acceso, cuándo conviene cada uno y por qué elegir entre los dos no es una decisión de precio.

Qué resuelve MCP aquí

MCP es aquí una superficie de descubrimiento y de tools, no un segundo producto. El servidor MCP de AI Tasker expone 40 tools sobre el transporte streamable-http en https://mcp.ai-tasker.theboomer.dev/mcp. Un cliente que habla MCP no necesita conocer ninguna ruta REST: pide el catálogo con tools/list, recibe cada tool con su nombre, su descripción y el esquema de sus argumentos, y decide qué llamar. Esa es la diferencia con una API clásica: aquí el contrato viaja dentro de la propia sesión en lugar de estar escrito de antemano en el cliente.

Dos mecánicas hay que tener presentes antes de la primera llamada. La API key viaja en la cabecera Authorization: Bearer atkr_… y se valida contra la API antes de abrir la sesión: sin cabecera, initialize responde 401, y una key revocada responde 401 con INVALID_API_KEY en lugar de fallar más tarde en la primera tool call. Y initialize devuelve un identificador de sesión que hay que devolver en la cabecera mcp-session-id de todas las llamadas siguientes: una petición posterior sin identificador de sesión válido se rechaza.

El catálogo llega dentro del protocolo: 40 tools con nombre, descripción y esquema de argumentos. El cliente no adivina rutas porque no las hay.
El workspace se resuelve por la clave: el servidor MCP toma el workspace que posee la API key, así que una lectura no necesita que el cliente sepa el identificador.
La credencial es por petición, no por proceso: un servidor desplegado sirve a muchos agentes y las keys se pueden rotar sin reiniciar nada.
Cada petición deja rastro: la fila de uso registra apiKeyId, workspaceId, método, ruta y canal (human, cli, llm, agent).

Qué resuelve la API HTTP aquí

La API HTTP es un contrato REST estable. El documento OpenAPI se publica en https://api.ai-tasker.theboomer.dev/api/openapi.json con 102 paths, y la documentación navegable está en https://api.ai-tasker.theboomer.dev/docs. Aquí no hay nada que descubrir: se sabe el método, la ruta y el cuerpo antes de llamar. Las dos superficies son el mismo producto con el mismo ámbito de workspace: la API key resuelve el mismo workspace en los dos casos, y una tarea creada por MCP se ve por HTTP y al revés.

La autenticación tiene una diferencia que conviene copiar bien: la API acepta Authorization: Bearer atkr_… o x-api-key: atkr_…, mientras que el endpoint MCP lee únicamente la cabecera Bearer, porque la clave se resuelve de las cabeceras de la petición y nunca del entorno del servidor. Un cliente que no puede mandar cabeceras HTTP por sí mismo no puede hablar MCP: para eso está el puente local que se explica más abajo.

MCP frente a la API HTTP: cuándo usar cada uno

La tabla no compara dos productos distintos: compara dos formas de llegar al mismo. Cada fila es una situación real de integración, y cada celda dice qué puede y qué no puede hacer esa superficie.

Qué resuelve cada superficie en AI Tasker: descubrimiento, llamadas, eventos, scripts, clientes sin MCP y lectura del contrato.
Situación	MCP	API HTTP
Descubrir qué se puede hacer	El cliente pide `tools/list` y recibe las 40 tools con su descripción y su esquema de argumentos. No hace falta saber ninguna ruta.	No hay descubrimiento: el contrato es el documento OpenAPI de 102 paths, que hay que leer o del que hay que generar un cliente antes de la primera llamada.
Llamar a una tarea concreta	Una llamada a la tool (`get_task`, `update_task`, `move_task`) con argumentos tipados, dentro de una sesión que lleva su identificador en la cabecera `mcp-session-id`.	Una petición a la ruta del recurso con la API key: `GET /api/tasks/{idOrCode}`, `PUT /api/tasks/{idOrCode}` o `PATCH /api/tasks/{id}/move`. Sin sesión y sin handshake.
Recibir eventos sin preguntar	No hay entrega push: MCP es petición y respuesta, y el cliente no se entera de un cambio hasta que vuelve a preguntar.	Tampoco hay push en el contrato REST. La entrega de eventos es el webhook: `task.created`, `task.updated`, `task.moved` y `task.archived`, con firma HMAC-SHA256.
Scriptar un flujo	Se puede, con más ceremonia: hay que abrir sesión con `initialize`, conservar el identificador de sesión en cada llamada y hablar JSON-RPC.	Es el caso natural: una petición HTTP con la cabecera Bearer, sin estado entre llamadas y con un cuerpo JSON que ya se conoce.
Integrar con un cliente que no tiene MCP	No sirve: sin soporte de MCP en el cliente, el protocolo no se puede usar.	Sirve: vale cualquier cliente HTTP —curl, `fetch`, un script en Python— con la API key en la cabecera.
Que una máquina lea el contrato	El catálogo se puede auditar aparte en `/llms-full.txt` y el manifiesto en `/server.json`, pero eso es un documento, no el protocolo.	El contrato es un documento OpenAPI en `/api/openapi.json`, con 102 paths: se puede generar un cliente, validar un mock o leerlo en un pipeline.

Ninguna de las dos superficies tiene más alcance que la otra: son dos entradas al mismo producto, con la misma jerarquía (workspace, proyecto, tarea, subtarea) y el mismo ámbito por workspace. La diferencia es de ergonomía y de encaje con el cliente que ya tienes, no de capacidades.

El transporte: por qué no hay un servidor stdio que instalar

AI Tasker publica el transporte remoto streamable-http. No hay un paquete stdio publicado que instalar para tener un servidor MCP local: stdio significa que el cliente arranca un proceso en tu máquina y habla con él por entrada y salida estándar, mientras que lo que AI Tasker publica es un endpoint remoto ya desplegado, con su autenticación y su cuota. Si tu cliente solo habla stdio, necesita un puente local que hable stdio en tu lado y reenvíe las peticiones al endpoint remoto streamable-http. Ese puente es el que convierte un transporte en el otro; no es un producto distinto de AI Tasker.

El endpoint remoto es el que se publica: https://mcp.ai-tasker.theboomer.dev/mcp, con POST /mcp para las llamadas y GET /health para la liveness.
La sesión es obligatoria después del handshake: sin mcp-session-id válido, la petición se rechaza. Los clientes que hablan MCP lo gestionan solos, y por eso no se nota.
Una clave por petición, no por proceso: el mismo servidor desplegado sirve a muchos agentes y las keys se rotan sin reiniciar.
Cada cliente tiene su formato: Claude Code usa .mcp.json, Cursor usa mcp.json y Codex CLI usa config.toml. Cambia el fichero de destino y el nombre de algunas claves, no la estructura.

La configuración que se copia

Este es el patrón común para un servidor MCP remoto con transporte streamable-http y una API key en la cabecera Authorization. Pégalo en el archivo que use tu cliente y sustituye el marcador por la clave real, con prefijo atkr_.

Configuración mcpServers para el servidor remoto de AI Tasker. La cabecera Authorization es lo que valida la clave.

{
  "mcpServers": {
    "ai-tasker": {
      "type": "http",
      "url": "https://mcp.ai-tasker.theboomer.dev/mcp",
      "headers": {
        "Authorization": "Bearer <AI_TASKER_API_KEY>"
      }
    }
  }
}

Y lo mismo, sin cliente MCP, por HTTP. El bloque de abajo hace las tres comprobaciones que importan antes de dar por buena una integración: abrir la sesión, listar las tools con el identificador de sesión ya puesto en la cabecera, y hacer la lectura equivalente por la API REST.

Las tres llamadas a mano: initialize devuelve el identificador de sesión, tools/list lo necesita en la cabecera mcp-session-id, y la tercera es la misma lectura por la API REST.

# 1. initialize: devuelve la cabecera mcp-session-id
curl -i -X POST https://mcp.ai-tasker.theboomer.dev/mcp \
  -H "Authorization: Bearer <AI_TASKER_API_KEY>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"mi-cli","version":"1.0.0"}}}'

# 2. tools/list con el identificador de sesion en la cabecera
curl -X POST https://mcp.ai-tasker.theboomer.dev/mcp \
  -H "Authorization: Bearer <AI_TASKER_API_KEY>" \
  -H "mcp-session-id: <MCP_SESSION_ID>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'

# 3. La misma lectura, por la API REST
curl https://api.ai-tasker.theboomer.dev/api/workspaces \
  -H "Authorization: Bearer <AI_TASKER_API_KEY>"

Lo que cuesta cada acceso

La cuota se cobra por operación, no por transporte. El catálogo que publica la API en /api/plans dice qué operaciones existen y qué consume cada una; esa es la lista completa y se puede releer en vivo.

Operaciones y unidades publicadas por la API de AI Tasker (/api/plans).
Operación	Bucket	Unidades	Qué cubre
AGENT_READ	agent	1	Lectura o listado de una colección por MCP o por API.
AGENT_MUTATION	agent	1	Crear, actualizar, mover o comentar una tarea desde el agente.
AI_SPRINT_PLAN	hosted_ai	1	Planificar el sprint con IA alojada.
AI_GENERATE_TASKS	hosted_ai	1	Generar tareas desde lenguaje natural.
AI_BREAKDOWN	hosted_ai	1	Desglosar una tarea en subtareas.
WEBHOOK_DELIVERED	agent	0	Entrega de un webhook: no es una operación semántica del agente.
RETRY	agent	0	Reintento por 5xx o timeout: un fallo de plataforma no se cobra.
HUMAN_READ	human	0	Lectura humana en el dashboard: incluida.
X402_MCP_PAID_TOOL	agent	0	Llamada MCP pagada vía x402 (piloto): el pago va fuera de la cuota y aquí solo queda la auditoría.

La consecuencia es la que zanja el debate: la llamada MCP y la llamada HTTP equivalente consumen la misma cuota. Leer o listar es AGENT_READ con 1 unidad; crear, actualizar, mover o comentar es AGENT_MUTATION con 1 unidad; las tres operaciones de IA alojada son 1 unidad cada una; y la entrega de webhooks, los reintentos por error de plataforma, la lectura humana en el dashboard y la llamada MCP pagada vía x402 son 0 unidades. Elegir MCP o HTTP no cambia lo que se paga: es una decisión de integración.

El techo diario tampoco distingue entre las dos vías: dailyAgentOps son 200 requests autenticados con API key al día, MCP y HTTP directo juntos, y dailyHostedAiOps son 10 operaciones de IA alojada al día. El plan gratuito da 1 workspace, 1 humano, 2 API keys, 100 operaciones de agente al mes, 100 operaciones de IA alojada al mes, 3 webhooks y 30 días de retención de actividad. Y la unidad facturable es de 2,00 € al mes por unidad aprobada (miembro humano aceptado, API key de agente creada o workspace adicional del owner), con packs de créditos de pago puntual para el consumo.

Un cálculo de coste que no salga de /api/plans es una estimación. La operación publicada es la que se cobra, tanto si la llamada entró por MCP como si entró por REST.

Cómo decidir: seis preguntas

¿El cliente con el que va a hablar el agente tiene soporte MCP? Si no tiene, la pregunta está respondida: API HTTP.
¿El flujo ya está escrito en un lenguaje cualquiera y no quieres tocarlo? API HTTP: añadir un handshake de sesión no aporta nada.
¿El agente necesita descubrir lo que puede hacer, o ya lo sabe? Descubrir: MCP. Ya lo sabe: HTTP.
¿Necesitas enterarte de un cambio sin preguntar? Ninguna de las dos: eso es un webhook.
¿Lo va a leer una máquina que entiende un contrato? OpenAPI: HTTP. Un catálogo de tools también se lee, pero el contrato documentado es el de la API.
¿Te importa el precio? No debería darte igual: la cuota es la misma por operación. Si la respuesta es que sí, es que hay otro problema debajo.

Lo que MCP no resuelve por ti

MCP resuelve el descubrimiento y la invocación con argumentos tipados. Todo lo demás sigue siendo trabajo tuyo, y conviene ponerlo por escrito para no prometer capacidades que el producto no tiene.

No entrega eventos. Ni MCP ni una llamada REST avisan de un cambio por sí solos: los eventos (task.created, task.updated, task.moved, task.archived) llegan por webhook, con la firma HMAC-SHA256 del cuerpo en la cabecera x-ai-tasker-signature.
No sustituye a la API en una llamada puntual desde un script. Si el flujo ya existe y funciona, la sesión MCP solo añade estado que mantener.
No gestiona los webhooks. Configurar un webhook exige una sesión humana en el dashboard y hace que el servidor haga POST a una URL del cliente, así que no forma parte de la superficie MCP.
No abarata nada. La unidad es la misma por operación y el techo diario cuenta las dos vías por igual.
No reemplaza al contrato para una máquina. El contrato que una máquina puede leer es el documento OpenAPI, no una sesión de protocolo.

Lo que queda por decidir

La pregunta que queda no es qué protocolo conviene, porque la respuesta depende del cliente que ya tienes y del flujo que ya escribiste. Es si vas a mantener dos integraciones o una. La guía de MCP para gestión de tareas tiene el catálogo de 40 tools y esta guía el contrato de 102 paths, y en el centro está lo mismo: un workspace con una jerarquía de proyecto, tarea y subtarea. El precio tampoco desempata, porque la unidad es de 2,00 € al mes por unidad aprobada y el consumo se mide por operación, no por protocolo. Cuando las dos superficies dan el mismo resultado, elige la que te cuesta menos mantener.

Cómo conectar un agente por MCP o por HTTP y comprobar el coste

Del credencial al primer tool call por las dos vías, con el bloque de configuración copiable y la comprobación del consumo en la tabla de operaciones.

Crea la API key y decide la vía
En el dashboard, en Settings → API keys, crea una key del workspace y copia el secreto con prefijo atkr_: se muestra una sola vez. Si el cliente habla MCP, la vía es MCP; si el flujo es un script propio, es la API REST. La misma key vale para las dos.
Abre la sesión MCP y descubre las tools
Pega el bloque mcpServers en el archivo que use tu cliente y pide tools/list: deben aparecer 40 tools. El initialize devuelve un identificador de sesión que hay que devolver en la cabecera mcp-session-id de todas las llamadas siguientes; sin él, la petición se rechaza.
Haz una lectura y una escritura por cada vía
Por MCP, una tool de lectura (por ejemplo list_tasks, que resuelve el workspace por la clave) y una de escritura (create_task). Por HTTP, GET /api/workspaces para saber el workspace y GET /api/tasks?workspaceId=<id> para el listado, o POST /api/tasks para crear. El resultado tiene que ser el mismo por las dos vías.
Contrasta el consumo y el rastro
Abre /api/plans y comprueba qué operaciones se han creado y qué unidades ha consumido cada una: leer y listar es AGENT_READ (1 unidad) y crear o mover es AGENT_MUTATION (1 unidad), mientras que un reintento por error de plataforma es 0 unidades. Después, mira la fila de uso con método, ruta y canal para confirmar que las dos vías quedaron registradas.

Preguntas frecuentes

¿MCP o API HTTP: cuál debería usar?

Si el cliente habla MCP y el agente va a descubrir qué puede hacer, usa MCP: el catálogo de 40 tools llega por el protocolo. Si el flujo ya está escrito, si necesitas que te avisen de un cambio o si tu cliente no tiene soporte MCP, usa la API REST con su contrato OpenAPI de 102 paths. El precio no decide: las dos superficies consumen la misma cuota por operación.

¿Puedo usar MCP y la API HTTP a la vez?

Sí, y es lo normal: son el mismo producto con el mismo ámbito de workspace, así que una tarea creada por MCP aparece por la API y al revés. Lo que hay que vigilar es la cuota, porque dailyAgentOps (200 requests autenticados al día) cuenta las dos vías por igual, y la que se use más es la que agota el techo.

¿Hay un servidor MCP por stdio que pueda instalar?

No hay un paquete stdio publicado de AI Tasker: lo que se publica es el transporte remoto streamable-http en https://mcp.ai-tasker.theboomer.dev/mcp. stdio significa que el cliente arranca un proceso en tu máquina, así que si tu cliente solo habla stdio necesita un puente local que reenvíe al endpoint remoto. Con un cliente que acepte streamable-http, el bloque mcpServers de la configuración resuelve el resto.

Fuentes

AI Tasker — endpoint MCP
https://mcp.ai-tasker.theboomer.dev/mcp
AI Tasker — manifiesto del servidor MCP
https://ai-tasker.theboomer.dev/server.json
AI Tasker — catálogo legible por máquina
https://ai-tasker.theboomer.dev/llms-full.txt
AI Tasker — contrato OpenAPI de la API (102 paths)
https://api.ai-tasker.theboomer.dev/api/openapi.json
AI Tasker — documentación navegable de la API
https://api.ai-tasker.theboomer.dev/docs
AI Tasker — planes y operaciones en vivo
https://api.ai-tasker.theboomer.dev/api/plans
MCP Registry oficial — dev.theboomer/ai-tasker
https://registry.modelcontextprotocol.io

Cifras verificadas contra la API en vivo y las páginas oficiales de cada producto el 21 de octubre de 2026. Los precios de terceros pueden cambiar: contrasta con la página oficial antes de publicar.

Guías relacionadas

Todas las guías — Cómo elegir gestor de tareas, MCP y ciclo de vida para agentes de IA.
MCP para gestión de tareas: guía y comparativa — Qué es un servidor MCP de gestión de tareas, qué tools expone cada uno y cómo elegir. Tabla con precios reales de cada servidor.
Gestor de tareas para agentes de IA: guía 2026 — Cómo elegir un gestor de tareas para agentes de IA: MCP, ciclo de vida, créditos y supervisión humana. Comparativa y checklist.
Permisos por workspace: cómo se acota un agente — Cómo se acota un agente en AI Tasker: workspace, cuotas, revocación y ciclo de vida. Qué limitan hoy los scopes y qué no.
Precios — Precios reales: plan gratuito y unidad facturable de 2,00 €/mes.
Integración MCP — https://mcp.ai-tasker.theboomer.dev/mcp
/llms.txt — Contrato legible por máquina.

Esta guía existe para ser indexada y citada. No está en el menú a propósito.