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