Author MCP

Author an MCP driver (AIP-32)

Use when wrapping an MCP server (local or remote) as a conformant driver for AIP-14 TOOL contracts. The skill produces a frontmatter-only DRIVER.md when standard MCP dispatch suffices.

Process

1. Identity: pick id ending in -mcp, set name, description, version, kind: mcp.
2. Server location: declare server per kind:
   • npm — package + args
   • docker — image + env (with ${secrets.X} substitutions)
   • binary — path + args
   • remote — url
3. Transport: stdio for local subprocess, sse for streaming remote, http for request-response remote.
4. Connect once (during authoring) and run tools/list to discover available MCP tool names.
5. Map TOOLs: for each contract-to-implement, pick the matching MCP tool name. Author metadata.mcp.tool_name, argument_mapping (when contract input keys differ from MCP arg names), result_extract (when MCP response wraps the contract output).
6. Auth: if the server needs secrets, declare in auth.ref → sibling SECRETS.md, with auth.state.env listing required env vars. For local servers, secrets are passed via server.env. For remote servers, auth is HTTP-style.
7. Sandbox: network.egress for remote, [] for local. policy_tags (self-hosted, third-party-api).
8. Optional integration: declare prompts[] for skill_block integration and resources[] for ref_kind integration.
9. Validate against MCP.schema.json AND DRIVER.schema.json.
10. Wire: loadProvider(...); the runtime spawns/connects on first call, lists tools, validates declared tool_names exist.

Common mistakes

• Hardcoded paths in stdio servers — vendored binaries are workspace-relative; document this in server.path.
• Missing tool_name validation — server-supplied schemas must match the contract; mismatches MUST fail at registration, not at first call.
• Long-lived stdio process leaking tenant state — pass tenant context in tools/call.arguments, never bind at spawn.
• Remote MCP without TLS — refuse http:// URLs in production.