Servidor MCP de Air Pipe

• Nome no registroio.airpipe/airpipeverificado no registro MCP

O nome no registro fica sob airpipe.io. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-19
• Ferramentas19
• O servidor se chamaairpipe
• Versão do servidor3.11.0
• Versão do protocolo2025-06-18

Em 2026-10-19 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 362 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCP72 de 100responde 100 · definições 68 · contexto 100 · conexão 100 · reduzida pelos sinais de alerta abaixo
• Respondeuem 100% dos dias9 de 9 verificações diárias
• Mediana da primeira resposta377 ms
• Espaço no contexto do agente≈ 1.845 tokensas definições de todas as ferramentas (19), que o agente carrega a cada turno
• Definições das ferramentasC · 68 de 100
• Resultados tipados0 de 19 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem descrição: em 18 de 19
• Sem dizer se só lê ou se pode destruir: 19 de 19

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e 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.