Naive API-to-MCP Conversion Hold

Overview

Naive API-to-MCP conversion means automatically wrapping existing APIs as Model Context Protocol tools without redesigning the capability, permissions, descriptions, errors, and approval model for agent use. MCP is valuable because it provides an open standard for connecting AI assistants to data sources and tools, replacing fragmented integrations with a single protocol (Anthropic).

The risk is that APIs designed for backend services or human operators are rarely safe agent affordances. Microsoft warns that MCP servers can be over-permissioned, misconfigured, vulnerable to token theft, and exposed to tool poisoning attacks where malicious instructions are embedded in tool descriptions (Microsoft Security Blog).

Hold on blanket conversions. Agent tools should be intentionally designed, narrow, typed, auditable, permission-aware, and safe by default, especially when they perform side effects.

Adoption Signals

• MCP adoption is accelerating because it lets developers expose data through MCP servers and build AI applications that connect to them as clients (Anthropic).
• Anthropic’s initial MCP ecosystem included prebuilt servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, demonstrating the appeal of quickly exposing tools and data sources (Anthropic).
• Microsoft describes MCP as a standardized way for AI models to request external actions through a consistent API and structured data exchange, which makes conversion from existing APIs tempting (Microsoft Security Blog).
• The NSA warns that MCP’s rapid proliferation has outpaced development of its security model and that secure-by-default behavior depends on implementation rigor, validation tools, and clearer specifications (NSA).
• MCP’s flexibility around dynamic tool discovery is useful, but the NSA recommends treating it with caution unless coupled with origin verification or authorization checks (NSA).

Risks

Naive wrappers expose too much surface area. A complete API may include destructive operations, administrative endpoints, bulk export paths, internal-only parameters, and ambiguous semantics that are unsafe for autonomous agents.

Tool descriptions become part of the prompt surface. Microsoft highlights tool poisoning attacks where malicious instructions in MCP tool descriptions are invisible to users but interpreted by the model, leading to unintended actions and potential data exfiltration (Microsoft Security Blog).

Authentication and authorization cannot be assumed. The NSA notes that many MCP implementations omit authentication entirely, and that implementations with authentication often lack role-based enforcement such as separate Create, Read, Update, and Delete permissions (NSA).

Auditability often disappears in prototypes. The NSA recommends logging all tool and model invocations with exact parameters, identities, and result hashes where feasible, because without traceable audit logs incident response and accountability are difficult (NSA).

Recommendation

Prefer intentionally designed MCP tool contracts over automatic API wrapping. Start from user jobs and safe agent actions, not from the full API surface. Expose narrow read-only tools first, add side-effecting tools only with scoped identity, explicit confirmation, idempotency, rate limits, validation, and audit logs.

A smaller agent-safe interface is usually better than a complete but dangerous conversion. Require security review for tool descriptions, permissions, token handling, error messages, and downstream effects before exposing internal APIs to agent clients.

Sources

• Anthropic: Introducing the Model Context Protocol
• Microsoft Security Blog: MCP security risks and mitigations
• NSA: MCP Security Design Considerations