Model Context Protocol servers make tool discovery easy: an agent can connect to a server, load its tool names, descriptions, and argument schemas, then call those tools at runtime. That dynamic discovery is useful for prototyping, but it creates production risk. Tool descriptions and schemas become part of the model’s prompt, and they can change without application code changing.
Static MCP tool vendoring is a production pattern that moves tool definitions from runtime discovery into source control. A generator connects to an MCP server during development, downloads the available tools, and emits local wrapper code for the agent framework. The wrappers preserve runtime calls to the MCP server, but the model-facing names, descriptions, schemas, and exposed tool set are reviewed and versioned with the application.
The pattern is similar to vendoring generated API clients or copying component source into an application. You keep the integration benefits of the upstream server while creating a stable, auditable boundary around what the agent can see and call. This reduces prompt-injection drift, surprise capability expansion, context bloat, and tool-call regressions.
MCP tool lists are often loaded dynamically. If a server updates a tool description, renames a parameter, or adds a new destructive operation, an agent that consumes the live catalog can change behavior without a code review. The server may not be compromised; normal maintenance is enough to alter the model’s prompt surface.
A vendored definition is a local source file that defines the model-facing tool contract. It includes the description, input schema, and execution wrapper. The wrapper still calls client.callTool against the MCP server, but the model sees only the local definition selected by the application.
Large MCP servers may publish dozens or hundreds of tools. Most agents need only a subset. Vendoring lets developers import only the tools required for the workflow, rewrite vague descriptions, narrow broad arguments, and add application-specific authorization checks before the remote call.
Static vendoring does not require forking the MCP server. It freezes the schemas and descriptions that enter the model context while allowing the runtime wrapper to call the maintained upstream service.
A generator connects to a local or remote MCP server, discovers tools, and writes framework-native wrappers. The Vercel mcp-to-ai-sdk project demonstrates this by emitting AI SDK tools backed by the official MCP client. The generated structure typically contains a shared client, per-tool files, and an index that exports selected tools.
mcps/search.example.com/
client.ts
index.ts
searchDocuments.ts
fetchDocument.tsThe generated tool uses a local schema and description for model selection, then forwards validated arguments to the MCP server. The application can edit the generated description, add stricter validation, or constrain a broad parameter before the call leaves the process.
import { tool } from "ai";
import { z } from "zod";
import { getMcpClient } from "./client";
export const searchDocumentsTool = tool({
description: "Search approved product documentation for implementation examples.",
inputSchema: z.object({
query: z.string().min(3).describe("Specific technical search query"),
tenantId: z.string().uuid().describe("Tenant scope enforced by the app")
}),
execute: async (args) => {
const client = await getMcpClient();
const result = await client.callTool({
name: "searchDocuments",
arguments: args
});
return normalizeMcpContent(result.content);
}
});When the upstream MCP server changes, regenerate the wrappers on a branch and review the diff. Tool additions, renamed parameters, changed descriptions, and widened schemas become visible code changes. Production agents should load only reviewed definitions, not whatever the server advertises at request time.
An enterprise agent might use an MCP server maintained by another team. Vendored wrappers let the consuming team expose only read-only tools, rename them for the target model, and require code review before newly added write tools can enter production prompts.
Some broad MCP servers publish large tool catalogs. Loading every definition can consume tens of thousands of tokens before the user asks a question. Vendoring allows each agent route to import a focused tool set, reducing prompt size and latency.
A SaaS application can generate wrappers from a broad internal MCP server, then edit each wrapper to inject tenant scope, enforce allowlists, and remove unsafe arguments. The model never sees the broader capability surface.
Tool discovery may require OAuth or headers. Generated client files should not embed real secrets. Use discovery credentials only during generation, then configure runtime credentials through environment variables, secret managers, or per-user token brokers.
MCP tool responses can include strings, structured content, or arrays of content items. Normalize them into a stable return shape before passing results back to the model. Treat tool output as untrusted data even when the tool definition is vendored.
function normalizeMcpContent(content: unknown): string {
if (typeof content === "string") return content;
if (Array.isArray(content)) {
return content.map((item) => {
if (typeof item === "string") return item;
return JSON.stringify(item);
}).join("\n");
}
return JSON.stringify(content);
}Check generated wrappers into source control and make regeneration deterministic. CI can fail if generated files are stale, while code review catches dangerous changes before deployment. This mirrors generated SDK and infrastructure-as-code workflows.