Servidor MCP de Air Pipe

• Nombre en el registroio.airpipe/airpipeverificado en el registro MCP

El nombre en el registro está bajo airpipe.io. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-19
• Herramientas19
• El servidor se llamaairpipe
• Versión del servidor3.11.0
• Versión del protocolo2025-06-18

El 2026-10-19 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 362 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCP72 de 100responde 100 · definiciones 68 · contexto 100 · conexión 100 · rebajada por las señales de aviso de abajo
• Respondióel 100% de los días9 de 9 comprobaciones diarias
• Mediana de la primera respuesta377 ms
• Espacio en el contexto del agente≈ 1845 tokenslas definiciones de todas sus herramientas (19), que el agente lleva en cada turno
• Definiciones de herramientasC · 68 de 100
• Resultados tipados0 de 19 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin descripción: en 18 de 19
• Sin indicar si solo lee o puede destruir: 19 de 19

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y números →

• delete_module

  Delete one or more reusable modules by module_uuid.

• plan_config

  Get airpipe config-authoring instructions plus RAG-retrieved real action examples for a natural-language request, so YOU (the calling model) write the YAML yourself instead of the server generating it. Returns { instructions, context…

• undeploy_module

  Undeploy a reusable module from an environment (STAGING or PRODUCTION).

• undeploy_config

  Undeploy a configuration from an environment (STAGING or PRODUCTION).

• update_config

  Update an existing AirPipe configuration by config_uuid (config_yaml is base64-encoded YAML) and optionally redeploy.

• list_modules

  List the organization's reusable modules (pass revisions=true to include revision history).

• validate_config

  Schema-validate an airpipe YAML config. Send { "yaml": <the full YAML string> }. Returns { valid: true } when it passes, or { valid: false, error: <message> } when it fails — feed the error back into your fix and call again until valid…

• toggle_config

  Enable or disable one or more configurations by config_uuid.

• list_configs

  List the organization's AirPipe configurations.

• deploy_config_revision

  Deploy a specific past revision of a configuration to staging or production.

• list_organizations

  List the organizations you belong to and their organization_uuid. Call this first to get an organization_uuid for the config tools.

• get_module

  Get a single reusable module by uuid, including its revision history and spec.

• get_config

  Get a single configuration's data by config_uuid, optionally with its revisions.

• delete_config

  Delete one or more AirPipe configurations by config_uuid.

• edit_config

  Edit an AirPipe configuration YAML with a natural-language instruction.

• create_config

  Create a new AirPipe configuration (config_yaml is base64-encoded YAML) and optionally deploy it to staging or production.

• create_module

  Create a reusable module (a typed config fragment referenced by handle) and optionally deploy it to staging or production. spec_yaml is base64-encoded YAML of the module body; module_type is the config struct it represents (e.g. Database).

• deploy_module_revision

  Deploy a specific past revision of a module to staging or production.

• update_module

  Update an existing reusable module by module_uuid (adds a new revision; spec_yaml is base64-encoded YAML) and optionally redeploy.