The 4 MCP Design Principles for Enterprise-Grade Tools
What makes an MCP tool trustworthy and reliable in production comes down to four principles that most teams discover by breaking them first.
Why These Four Principles?
Most teams discover these principles by breaking them. They build MCP tools that mirror REST APIs, return raw system responses, expose CRUD operations directly, and assume the LLM will figure out the rest. The agents built on these tools behave unpredictably, require constant prompt engineering to correct, and eventually lose user trust.
The four principles are the distillation of what production-grade MCP tools have in common. Apply them from day one and you avoid the failure modes that plague the first generation of enterprise MCP implementations.
Principle 1: Describe Capabilities, Not APIs
MCP tool names and descriptions tell the LLM what the tool does and when to use it — not how the underlying API works. The LLM reads the tool description to decide whether to call it. If the description is a technical specification, the LLM either won't call it correctly or will call it in contexts where it shouldn't.
Wrong: A tool named salesforce_query_v2 with description "Executes a SOQL query against Salesforce using the REST API v57."
Right: A tool named get_open_opportunities with description "Returns all open sales opportunities for a given account, including deal value, stage, and expected close date. Use when you need to understand the current sales pipeline for an account."
The right version tells the LLM exactly when to call it and what it will get back. The wrong version requires the LLM to know what SOQL is, know the Salesforce data model, and figure out when "querying Salesforce" is the appropriate action.
Principle 2: Return Structured, LLM-Readable Results
Tool responses must be structured for LLM consumption, not human display. Return field names the LLM can reference in subsequent reasoning. Return status context so the LLM knows what happened. Avoid HTML, complex nested structures, or raw API responses that weren't designed for agent consumption.
Wrong: Returning a Salesforce API response verbatim — 47 fields, nested objects, system timestamps, internal IDs the LLM can't interpret.
Right: Returning a structured object with the fields the agent needs: account name, opportunity name, stage, value, close date, owner, and a status field indicating whether the query succeeded, returned no results, or failed.
The LLM will use what you return to decide what to do next. Give it exactly what it needs and nothing it doesn't.
Principle 3: Scope Tools to Business Actions, Not CRUD
Enterprise MCP tools should map to business actions — approve_expense_report, onboard_employee, escalate_support_ticket — not database operations. Each tool should correspond to something a business user would recognize as a distinct action.
CRUD-scoped tools (create record, update record, delete record) force the LLM to reason about data structures rather than business intent. When an agent calls update_opportunity_stage, everyone understands what happened. When it calls update_record with a payload, the audit log is unreadable and the agent's intent is ambiguous.
Business-action-scoped tools also enforce the right guardrails. approve_expense_report can validate the approver's authority, check the amount threshold, and enforce the approval workflow — none of which is possible with a generic update_record call.
Principle 4: Build for Composability
Individual tools should be combinable. Design tools so that the output of one can serve as input to another. The agent, not the tool, orchestrates the sequence.
A composable tool set for a sales use case might include: get_account_profile, get_open_opportunities, get_recent_activity, and generate_account_summary. The agent can call these in sequence, using the output of each to inform the next. Each tool does one thing well. The agent assembles the workflow.
Non-composable tools combine multiple operations into one, require specific parameter formats that only work in one context, or return data structures that can't be passed to other tools. They seem convenient until the use case changes slightly and the whole thing breaks.
The Four Outcomes
| Principle | What You Get When You Follow It | What You Get When You Don't |
|---|---|---|
| Describe capabilities | Agents that call the right tool at the right time | Agents that call wrong tools or miss obvious ones |
| Structured results | Reliable reasoning across tool chains | Hallucination filling the gaps in unstructured output |
| Business actions | Auditable, governed, understandable agent behavior | CRUD operations with no business context in the audit log |
| Composability | Flexible agents that combine tools for new use cases | Brittle agents that break when requirements change |