Addressing security and quality issues with MCP tools in AI Agents (vercel.com)

Enterprises adopting Model Context Protocol (MCP) for federating agent tool calls face real production risks: tool names, descriptions, and schemas are dynamically injected into agent prompts, enabling prompt‑injection, unexpected capability escalation, token/latency bloat (e.g., GitHub’s MCP can use ~50k tokens just for definitions), and reduced tool‑call accuracy from upstream drift and generic descriptions. To address this, the mcp-to-ai-sdk CLI was introduced: it connects to any MCP server, downloads definitions, and generates static, AI‑SDK–compatible tool stubs you check into your codebase. That “vendoring” approach locks schemas and descriptions behind version control and code review, preventing stealthy prompt changes and surprise tool additions while still letting agents call the upstream MCP at runtime. Technically, the tool produces local wrappers (example CLI: npx mcp-to-ai-sdk https://mcp.example) that include typed input schemas (zod) and execute functions that invoke the MCP client. You import only the tools you want into your agent, reducing prompt context/tokens, enabling custom descriptions, argument restrictions, and app‑specific auth logic. Important caveats remain: runtime responses must be treated as untrusted input, and upstream behavior can still change; however, vendoring brings clearer security, performance, and reliability tradeoffs for moving MCP use from prototype to production.