The Problem: Tool APIs Mix Concerns That Should Be Separate
Your agent calls a tool to "get customer data." The tool API executes a database query, formats the results, applies business logic, checks permissions, logs the action, and returns formatted JSON. This seems reasonable until you realize you've just coupled execution logic with context retrieval in a way that makes your entire agent system harder to build, debug, and govern.
This is the fundamental mistake in how most teams build agent tool APIs today. They treat tools as black boxes that do everything: fetch data, transform it, enforce policy, and return results. The agent has no visibility into what happened. It can't cache results. It can't retry just the failed part. It can't enforce consistent access control. It just gets back whatever the tool decided to return.
The failure mode is subtle. In demos, this works fine. The agent calls get_customer_data(customer_id="123"), gets back nicely formatted JSON, and moves on. But in production, you discover that different tools format data differently. Some return paginated results, some don't. Some include metadata, some don't. Error handling is inconsistent. Rate limiting is per-tool, not per-agent. Observability is a nightmare because you can't see what happened inside the tool.
Worse, every new capability requires a new tool API. Need to filter customer data? New tool. Need to aggregate it? New tool. Need real-time vs. cached data? Two different tools. Your agent's tool catalog explodes. Context windows fill with tool definitions. The model spends more time deciding which tool to call than actually reasoning.
The root cause: tool APIs bundle execution (what to do) with context (what data to provide). These are orthogonal concerns that should be handled separately. Execution is about actions with side effects: sending emails, creating records, triggering workflows. Context is about data availability: what information exists and how to access it.
Model Context Protocol separates these concerns. MCP servers provide context through a standardized protocol. Tools remain for execution. This isn't just cleaner architecture—it fundamentally changes what's possible in agent systems. Better caching, simpler governance, easier debugging, and fewer API endpoints to maintain.
The Mental Model: Execution vs. Context as Separate Capabilities
Stop thinking of tools as general-purpose API endpoints that do everything. Start thinking about two distinct capabilities: execution and context.
Execution tools perform actions with side effects. They change state in external systems. Send an email. Create a database record. Deploy code. Charge a credit card. These operations are not idempotent. Running them twice produces different outcomes than running once. They need explicit authorization, audit trails, and often human approval.
Context providers make data available. They don't execute actions—they surface information. Database state, file contents, API responses, cached results, computed aggregates. These operations should be idempotent. Reading the same data twice gives you the same result (modulo updates). They need access control but not execution approval.
Traditional tool APIs mix these. When you define get_customer_orders() as a tool, is that execution or context? It queries a database (context) but might also log access (side effect) and apply complex filtering (execution logic). The agent can't tell. The tool definition doesn't distinguish.
MCP forces separation. Context lives in MCP servers that advertise resources and capabilities. The agent discovers what data is available, requests specific resources, and receives structured responses. No side effects. No execution logic. Just data availability.
Execution remains in tools, but they become simpler. Instead of get_customer_orders() being a tool, it becomes context available through an MCP server. Tools are reserved for actual actions: send_order_confirmation_email(), process_refund(), escalate_to_human().
The key invariant: context access is declarative, execution is imperative.
With tool APIs, the agent must imperatively decide: "Call this tool with these parameters." The tool does whatever it does, and the agent observes results. This is sequential, opaque, and hard to optimize.
With MCP, context access is declarative: "I need customer data and order history." The MCP layer figures out how to assemble that context—potentially from multiple sources, potentially in parallel, potentially from cache. The agent just receives assembled context. Execution is still imperative (the agent decides which actions to take), but context assembly is infrastructure.
This separation has profound implications for governance. You can audit context access separately from action execution. You can cache context without caching actions. You can evolve context schemas without changing tool definitions. You can enforce consistent access control across all context providers.
Architecture: MCP Servers vs. Traditional Tool APIs
Traditional Tool API Architecture
Every tool is an independent endpoint. Each implements its own data access, caching, logging, error handling, and authorization. The agent calls tools sequentially, waiting for responses. There's massive code duplication—three different tools query the same database with slightly different logic.
Problems with this architecture:
Tools couple data access with execution logic. Calculate Analytics fetches data, computes aggregates, and returns results. The agent can't cache intermediate results or retry just the computation if it fails.
No standardization across tools. Each tool has custom error formats, rate limiting, and retry logic. The agent must handle each differently.
Sequential execution is enforced. Even when tools could run in parallel (fetching customer data and order history simultaneously), the agent must call them one at a time.
Observability is fragmented. Logs go to different places. Metrics are per-tool, not per-agent or per-task.
Tool proliferation is inevitable. Every new data access pattern requires a new tool. Want customer data with different filters? New tool. Want cached vs. fresh data? Two tools.
MCP-Based Architecture
Context lives in MCP servers. The agent declares context needs, and the MCP layer assembles it from appropriate sources. Execution tools are separate, reserved for actions with side effects.
Benefits of this architecture:
Context assembly is separate from execution. The agent requests "customer data" as context. The MCP layer decides whether to fetch from database, cache, or API. The agent doesn't care.
Parallel context gathering is default. MCP can query multiple servers simultaneously. The agent gets assembled context faster than sequential tool calls.
Standardized protocol across all context. Every MCP server speaks the same protocol. Error handling, pagination, metadata—all consistent.
Centralized governance is possible. All context access flows through the MCP layer. You can enforce uniform access control, audit logging, and rate limiting.
Tool reduction is dramatic. Instead of ten tools for different data access patterns, you have one or two MCP servers that expose resources flexibly.
Component Responsibilities
MCP Servers expose resources and capabilities. They don't execute business logic—they make data available. Database MCP server exposes tables and views. File system MCP server exposes directories and files. API MCP server exposes endpoints and responses.
MCP Context Layer orchestrates access to MCP servers. It handles protocol negotiation, parallel requests, caching, retries, and result assembly. This is infrastructure the agent doesn't manage.
Execution Tools perform actions. Send emails, create records, trigger workflows. These remain as traditional tool APIs because they're actually executing operations, not just providing context.
Agent makes decisions using assembled context and invokes execution tools when needed. It doesn't manage context assembly or handle MCP protocol details.
Implementation: Converting Tool APIs to MCP Servers
Before: Traditional Tool API
Here's what most teams build today.
from typing import Dict, List, Anyfrom datetime import datetimeclass CustomerToolAPI: """ Traditional tool API that mixes everything. """ def __init__(self, db_connection, cache, logger): self.db = db_connection self.cache = cache self.logger = logger def get_customer_data(self, customer_id: str, include_orders: bool = False) -> Dict[str, Any]: """ Tool that fetches customer data. Couples: data access, caching, logging, formatting. """ cache_key = f"customer:{customer_id}" # Check cache if cache_key in self.cache: self.logger.info(f"Cache hit for {customer_id}") return self.cache[cache_key] # Fetch from database self.logger.info(f"Fetching customer {customer_id}") customer = self.db.query( "SELECT * FROM customers WHERE id = ?", (customer_id,) ).fetchone() if not customer: raise ValueError(f"Customer {customer_id} not found") result = { "id": customer["id"], "name": customer["name"], "email": customer["email"], "created_at": customer["created_at"].isoformat() } # Optionally include orders (execution logic in data access) if include_orders: orders = self.db.query( "SELECT * FROM orders WHERE customer_id = ?", (customer_id,) ).fetchall() result["orders"] = [ { "id": o["id"], "total": float(o["total"]), "status": o["status"] } for o in orders ] # Cache result self.cache[cache_key] = result return result def get_customer_analytics(self, customer_id: str) -> Dict[str, Any]: """ Another tool that fetches similar data differently. More coupling, more duplication. """ # Get customer (duplicate logic) customer = self.get_customer_data(customer_id, include_orders=True) # Compute analytics (execution logic) total_spent = sum(o["total"] for o in customer.get("orders", [])) order_count = len(customer.get("orders", [])) return { "customer_id": customer_id, "total_spent": total_spent, "order_count": order_count, "avg_order_value": total_spent / order_count if order_count > 0 else 0 }# Agent tool definitiontools = [ { "name": "get_customer_data", "description": "Fetch customer information, optionally including orders", "parameters": { "customer_id": {"type": "string"}, "include_orders": {"type": "boolean", "default": False} } }, { "name": "get_customer_analytics", "description": "Get analytics for a customer", "parameters": { "customer_id": {"type": "string"} } }]Problems in production:
Two tools do similar things differently. Both fetch customer data, apply different logic, cache differently.
Caching is per-tool. If one tool caches customer data and another fetches it fresh, you get inconsistency.
The agent must know implementation details. It has to decide whether to use include_orders=True or call a separate tool.
Adding new access patterns requires new tools. Want to filter orders by status? New tool. Want to aggregate across multiple customers? New tool.
After: MCP Server for Context
Convert data access to MCP server.
from typing import Dict, List, Any, Optionalimport asyncioclass CustomerMCPServer: """ MCP server that exposes customer data as resources. No execution logic, no caching (handled by MCP layer), just data access. """ def __init__(self, db_connection): self.db = db_connection async def list_resources(self) -> List[Dict[str, Any]]: """ Advertise available resources. MCP protocol method. """ return [ { "uri": "customer://{customer_id}", "name": "Customer Data", "description": "Individual customer information", "mimeType": "application/json" }, { "uri": "customer://{customer_id}/orders", "name": "Customer Orders", "description": "Orders for a specific customer", "mimeType": "application/json" }, { "uri": "customers://analytics/{customer_id}", "name": "Customer Analytics", "description": "Computed analytics for customer", "mimeType": "application/json" } ] async def read_resource(self, uri: str) -> Dict[str, Any]: """ Fetch resource data. MCP protocol method. """ if uri.startswith("customer://"): # Parse URI parts = uri.replace("customer://", "").split("/") customer_id = parts[0] if len(parts) == 1: # Fetch customer data return await self._fetch_customer(customer_id) elif len(parts) == 2 and parts[1] == "orders": # Fetch customer orders return await self._fetch_orders(customer_id) elif uri.startswith("customers://analytics/"): customer_id = uri.replace("customers://analytics/", "") return await self._compute_analytics(customer_id) raise ValueError(f"Unknown resource URI: {uri}") async def _fetch_customer(self, customer_id: str) -> Dict[str, Any]: """Pure data access, no caching or logging""" customer = await self.db.query_one( "SELECT * FROM customers WHERE id = ?", (customer_id,) ) if not customer: raise ValueError(f"Customer {customer_id} not found") return { "id": customer["id"], "name": customer["name"], "email": customer["email"], "created_at": customer["created_at"].isoformat() } async def _fetch_orders(self, customer_id: str) -> List[Dict[str, Any]]: """Pure data access""" orders = await self.db.query_all( "SELECT * FROM orders WHERE customer_id = ?", (customer_id,) ) return [ { "id": o["id"], "total": float(o["total"]), "status": o["status"], "created_at": o["created_at"].isoformat() } for o in orders ] async def _compute_analytics(self, customer_id: str) -> Dict[str, Any]: """ Compute analytics using other resources. This demonstrates composition through MCP. """ # These would actually go through MCP layer with caching customer = await self._fetch_customer(customer_id) orders = await self._fetch_orders(customer_id) total_spent = sum(o["total"] for o in orders) return { "customer_id": customer_id, "total_spent": total_spent, "order_count": len(orders), "avg_order_value": total_spent / len(orders) if orders else 0, "computed_at": datetime.utcnow().isoformat() }class MCPContextLayer: """ Layer that handles caching, parallel access, and protocol details. This is what sits between agent and MCP servers. """ def __init__(self, servers: Dict[str, Any]): self.servers = servers self._cache: Dict[str, tuple[Any, datetime]] = {} self.cache_ttl_seconds = 300 async def get_context( self, resource_uris: List[str], use_cache: bool = True ) -> Dict[str, Any]: """ Fetch multiple resources in parallel with caching. This is what the agent calls. """ results = {} # Separate cached from uncached to_fetch = [] for uri in resource_uris: if use_cache and uri in self._cache: data, cached_at = self._cache[uri] age = (datetime.utcnow() - cached_at).total_seconds() if age < self.cache_ttl_seconds: results[uri] = data continue to_fetch.append(uri) # Fetch uncached resources in parallel if to_fetch: tasks = [self._fetch_resource(uri) for uri in to_fetch] fetched = await asyncio.gather(*tasks, return_exceptions=True) for uri, data in zip(to_fetch, fetched): if isinstance(data, Exception): results[uri] = {"error": str(data)} else: results[uri] = data self._cache[uri] = (data, datetime.utcnow()) return results async def _fetch_resource(self, uri: str) -> Any: """Route to appropriate MCP server""" # Determine which server handles this URI if uri.startswith("customer://") or uri.startswith("customers://"): server = self.servers["customer"] return await server.read_resource(uri) raise ValueError(f"No server for URI: {uri}")# Agent usageasync def agent_with_mcp(): """ Agent using MCP for context. Much cleaner than tool API approach. """ mcp_layer = MCPContextLayer({ "customer": CustomerMCPServer(db_connection) }) # Agent declares what context it needs context = await mcp_layer.get_context([ "customer://123", "customer://123/orders", "customers://analytics/123" ]) # All fetched in parallel, with caching # Agent just uses assembled context customer = context["customer://123"] orders = context["customer://123/orders"] analytics = context["customers://analytics/123"] # Agent reasons with context, decides on actions # Execution tools are separate (not shown here)Production benefits:
Single MCP server replaces multiple tool APIs. All customer-related context comes from one server with consistent protocol.
Parallel context fetching is automatic. MCP layer handles this. Three resources fetched in one roundtrip instead of three sequential tool calls.
Caching is centralized. MCP layer caches all resources uniformly. No per-tool cache duplication.
Resources compose naturally. Analytics resource uses customer and orders resources. Agent doesn't need to know this.
Adding new access patterns is cheap. New URI pattern, no new tool definition.
Governance Through MCP
The killer feature: centralized governance becomes possible.
class GovernedMCPLayer(MCPContextLayer): """ MCP layer with governance: access control, auditing, rate limiting. """ def __init__(self, servers, access_control, audit_logger): super().__init__(servers) self.access_control = access_control self.audit = audit_logger async def get_context( self, resource_uris: List[str], user_context: Dict[str, Any], use_cache: bool = True ) -> Dict[str, Any]: """ Governed context access. """ # Check access control for ALL resources upfront for uri in resource_uris: if not self.access_control.can_access(user_context, uri): self.audit.log_denied_access(user_context, uri) raise PermissionError(f"Access denied to {uri}") # Audit access request self.audit.log_access_request( user=user_context["user_id"], resources=resource_uris, timestamp=datetime.utcnow() ) # Fetch with standard caching results = await super().get_context(resource_uris, use_cache) # Audit successful access self.audit.log_access_success( user=user_context["user_id"], resources=list(results.keys()), timestamp=datetime.utcnow() ) return resultsGovernance advantages:
Uniform access control across all context. One policy applies to all MCP servers. With tool APIs, each tool implements auth differently.
Centralized audit logging. Every context access logged consistently. With tools, logging is fragmented.
Rate limiting at context layer. Limit requests per user per time window across all resources. With tools, rate limiting is per-tool.
Policy evolution is independent. Change access control rules without modifying MCP servers or agent code.
Pitfalls & Failure Modes
Treating MCP Servers Like Tool APIs
Teams port tool APIs to MCP but keep the same design: one MCP server per operation.
Symptom: You have dozens of MCP servers, each exposing one or two resources. The agent still has to know which server to use for what.
Why it happens: Direct translation from tool APIs. Teams think "one tool becomes one MCP server."
Detection: Count MCP servers. If you have >10 servers for a single domain (e.g., customer data), they're too granular.
Prevention: MCP servers should be domain-based, not operation-based. One customer MCP server exposes all customer-related resources, not separate servers for customer-data, customer-orders, customer-analytics.
Putting Execution Logic in MCP Servers
Teams put side effects in MCP resource reads because it's convenient.
Symptom: Reading a resource triggers actions. Fetching "customer://123" sends a notification or logs an event.
Why it happens: Legacy tool APIs had side effects. Teams port the behavior without rethinking.
Detection: Audit logs show resource reads correlating with action executions. Reading the same resource twice produces different outcomes.
Prevention: MCP resources must be read-only. No side effects. Actions belong in execution tools, not context providers.
Ignoring Protocol Standards
Teams build custom protocols on top of MCP instead of using MCP's resource model.
Symptom: Every MCP server has different URI schemes, error formats, and metadata structures. Agents need server-specific logic.
Why it happens: MCP allows flexibility. Teams use it to replicate their old tool API designs.
Detection: Check if different MCP servers are truly interchangeable. If agent code has conditional logic per server, protocol isn't standardized.
Prevention: Follow MCP conventions strictly. URI formats, resource listings, error responses—standardize across all servers.
Over-Granular Resources
Teams expose every database column as a separate resource.
Symptom: Agents request dozens of tiny resources to assemble context. Latency from roundtrips dominates.
Why it happens: Over-application of "separation of concerns." Teams think finer granularity is always better.
Detection: Measure resource requests per agent task. If >20 resources for typical tasks, granularity is too fine.
Prevention: Resources should match agent reasoning granularity. If agents always need customer name, email, and status together, make that one resource, not three.
Bypassing MCP Layer for "Performance"
Teams let agents call MCP servers directly to avoid MCP layer overhead.
Symptom: Caching doesn't work. Access control is inconsistent. Some agent code uses MCP layer, some doesn't.
Why it happens: Latency concerns. Teams see MCP layer as overhead and optimize it away.
Detection: Trace access patterns. If MCP servers receive requests not logged by MCP layer, bypass is happening.
Prevention: Optimize the MCP layer, don't bypass it. If it's slow, fix caching or parallelize better. Don't create two paths to context.
Summary & Next Steps
MCP servers will replace most agent tool APIs because they separate concerns that tool APIs incorrectly bundle. Tools mix execution with context, making systems harder to cache, debug, and govern. MCP provides context through a standardized protocol, leaving tools for actual execution. This architectural separation makes agent systems cleaner, faster, and easier to manage at scale.
The core insight: most "tools" in agent systems aren't really executing actions—they're fetching context. Converting them to MCP servers eliminates coupling, enables parallel fetching, standardizes protocols, and centralizes governance. Execution tools become simpler and fewer. Context becomes infrastructure managed by the MCP layer.
Start migrating now:
This week: Audit your current tool APIs. Classify each as execution (has side effects) or context (pure data access). This tells you how many should become MCP servers vs. staying as tools.
Next sprint: Convert your highest-traffic context tools to MCP servers. Measure before and after: tool call counts, latency, cache hit rates. You should see fewer calls and better performance.
Within month: Build a governed MCP layer with centralized access control and audit logging. Compare governance overhead vs. maintaining per-tool authorization. MCP governance should be simpler and more consistent.
The transition won't happen overnight. But every tool API you convert to MCP makes your agent system more maintainable. Start with the biggest pain points: tools that duplicate data access, tools with inconsistent caching, tools with complex authorization. Convert these first and let the benefits compound.
MCP isn't just a protocol—it's an architectural pattern that forces better separation of concerns. Embrace it, and your agent systems will be cleaner than you thought possible.