Preface: The Problem With Hardcoded Tools

The MCP Developer — The Pramana Framework, Companion 6

By the end of Companion 4, ShopBot could act.

It could place an order. It could look up a product. It could route a complaint, confirm a shipment, escalate a failed payment. The Action Layer was in place — grounded in retrieval, bounded by rules, auditable down to the individual tool call. Arjun had built an agent that did not merely speak correctly but acted correctly. The loop terminated. The audit trail held. The test suite passed.

What Companion 4 did not ask was: what happens when the thing the agent needs to act on is not a function Arjun wrote?

ShopBot's tools in Companion 4 were Python functions. get_product_details. place_order. check_inventory. Arjun wrote them. Arjun knew their inputs. Arjun knew their return shapes. Arjun hardcoded the exact schemas the agent would call against. It worked because Arjun was both the builder of the agent and the builder of every system the agent touched.

That is not how production systems work.

In production, the inventory system is a service that another team built three years ago. The order management system is a vendor platform with its own API versioning schedule. The customer CRM is managed by a different business unit and requires an OAuth token that expires every twelve hours. None of these systems were designed to be called by an AI agent. None of them expose a Python function. None of them know or care that ShopBot exists.

The agent — however intelligent, however well-grounded — has no path to any of them. It knows what to ask. It has no one to ask.

This is the problem Companion 6 solves.

The Model Context Protocol — MCP — is the answer to the question: how does an agent reach a system it did not know about when it was built? Not by hardcoding a function. Not by guessing the API. By a contract — a defined specification of what a system exposes, what it accepts, and what it returns — published before the conversation begins, consumed by any agent that can read it.

An MCP server is a process that speaks that contract. An MCP client — the agent — reads the contract and calls tools defined within it. The agent does not need to know that the inventory system is a PostgreSQL database behind a FastAPI service. It needs to know that the get_inventory tool accepts a product SKU and returns a stock level. The MCP server knows the rest.

This separation is not a convenience. It is what makes the architecture composable. The same agent can call the inventory MCP server, the order MCP server, and the CRM MCP server without knowing — or caring — how any of them are implemented. The contract is the only thing the agent needs to read.

Sahadeva joined zUdyog three months after Companion 4 ended.

He was not Arjun's hire exactly. Draupadi — who ran Vastralaya, who had watched the multi-tenant architecture go into production in Book 4 — had mentioned him first. She had worked with him on a deployment in Nagpur, a system integration that required connecting four internal services to a single interface. Sahadeva had designed the integration layer. It had worked without modification for eleven months. Draupadi described this as unusual.

Arjun met him once before making the decision. Sahadeva sat across from him in the office — the same second bedroom where the whiteboard had been accumulating problems for four books — and said almost nothing. Arjun asked what he would do differently about ShopBot's current architecture. Sahadeva picked up a piece of paper and drew a diagram. It was not a diagram of what ShopBot currently was. It was a diagram of what ShopBot would need to be when zUdyog had three internal systems instead of one.

Arjun had not been planning for three systems. He hired Sahadeva the next day.

This book follows the construction of the MCP layer at zUdyog — the infrastructure that connects ShopBot to the inventory service, the order management system, and the CRM that came later, all through a consistent contract that the agent can read without knowing what sits behind it. Each chapter solves one piece of that infrastructure: the transport that carries calls, the auth that governs who can call, the versioning that handles when servers change, the security posture that prevents what should not be callable from being called.

By Chapter 9, ShopBot will have a nervous system. Not a collection of hardcoded functions that Arjun must update every time a downstream system changes. A layer of defined contracts between the agent and the systems it is permitted to reach — extensible, auditable, and replaceable without touching the agent itself.

There is a Pramana that knows its own reach — that does not invent tools that do not exist, or call tools that were not offered, because the contract was drawn before the conversation began.

The agent that hallucinates a tool call is doing what ungrounded LLMs have always done: completing the pattern of what an answer looks like, without the boundary that prevents fabrication. The MCP contract is that boundary. It tells the agent exactly what is there, what it accepts, and what it returns. It does not ask the agent to guess.

This book is not about teaching the agent new things. It is about building the infrastructure it can honestly reach.