Why We Scrapped Custom API Wrappers for Model Context Protocol (MCP)

If you have ever connected an LLM to an internal REST API by stuffing OpenAPI specs into a system prompt, you know the exact point of failure:

JSON
// What you asked for:
{ "action": "update_user", "user_id": "usr_9912", "status": "active" }

// What the model hallucinated at 2 AM:
{ "action": "modify_account", "id": 9912, "state": "enabled", "force": true }
When an LLM hallucinates parameters or invents nonexistent query strings, it isn't just an error—it can corrupt production database states.

At Omnifys, our agents interact directly with CRMs, ERPs, and internal SQL databases. We quickly learned that writing custom JSON-schema glue code for every tool call is unmaintainable. That is why we migrated our agent execution layer entirely to the Model Context Protocol (MCP).

The Core Problem with Custom Tool Calling
Custom prompt-based tool calling fails because of three architectural flaws:

Schema Drift Vulnerability: If you alter a backend endpoint, updating every system prompt and fine-tuned instruction across your pipeline is brittle.

Context Window Waste: Shoving massive API documentation into prompt tokens inflates latency and burns your compute budget.

Weak Sandboxing: Direct API keys embedded in agent contexts expose backend services if an indirect prompt injection occurs.

The MCP Blueprint: Standardized Tool Execution
MCP treats tools as independent, typed servers rather than static prompt text. The agent queries an MCP server to discover capabilities at runtime:

[ Inbound Request ]
│
▼
[ LLM Reasoning Step ]
│
▼
[ MCP Client ] ── (Discovers available tools via standardized schema)
│
▼
[ MCP Server ] ── (Validates types, checks row-level auth, executes handler)
│
▼
[ Production API / DB ]

1. Strongly Typed Schemas
   Tools expose standardized schemas with strict JSON Schema validation. If a model tries to pass "id": 9912 when a string UUID is required, the MCP boundary rejects the payload before it ever touches your network.

2. Ephemeral Context Discovery
   Instead of loading your entire backend API surface into the system prompt, the agent queries the MCP server dynamically based on task intent. This keeps prompt tokens minimal and keeps response latency under 400ms.

3. Least-Privilege Scoping
   Tool permissions are handled at the transport layer. The agent never receives raw database credentials; it only receives a session-scoped token that permits specific read or write operations within strict tenant boundaries.

Practical Takeaway
Treating AI tools as standard protocol endpoints rather than custom prompt strings turns chaotic model outputs into reliable, deterministic code execution.

If you are evaluating agent architectures or building governed automation pipelines, see how we implement MCP and agentic workflows at https://omnifys.com/.

Over to You 👇
Are you currently using MCP, Function Calling, or custom prompt wrappers for your agent tools? What has been your biggest headache with tool schema validation?