Air Pipe MCP server

• Registry nameio.airpipe/airpipeverified in the MCP registry

The registry name sits under airpipe.io. The registry only lets a publisher use that namespace after proving control of the domain through DNS or HTTP.

• Stateanswerschecked 2026-10-19
• Tools19
• Server calls itselfairpipe
• Server version3.11.0
• Protocol version2025-06-18

On 2026-10-19 the server answered initialize and tools/list without a sign-in. First answer in 362 ms.

• Whether its tools do the product's job has not been judged yet.

Said by rules from the measurements above. The likely first call is a model's pick from the tool list; read its description before relying on it.

• INITE MCP score72 of 100answers 100 · definitions 68 · context 100 · connects 100 · lowered by the warning signs below
• Answered100% of days9 of 9 daily checks
• Median first answer377 ms
• Space in an agent's context≈ 1,845 tokensthe definitions of all its tools (19), which an agent carries on every turn
• Tool definitionsC · 68 of 100
• Typed results0 of 19 toolsdeclared outputSchema: results come typed, read once

• Parameters without a description: in 18 of 19
• Not saying whether it only reads or can destroy: 19 of 19

A program checks the server once a day: initialize and tools/list, no model. Tokens are the definitions' length at about four characters a token. The grade averages six checks of every tool's name, description, schema and annotations; it says how well the tools are described, not whether they work. The score weighs what was measured and nothing else: answering (25%), doing the product's job (25%), definitions (20%), context (10%), use (10%) and how readily a client connects (10%). A part that was not measured is left out, and a hidden instruction caps the score at 40. The state of vendors' MCP servers: method and numbers →

• 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.