--- title: Design Multi-Context Processing Tools as Capabilities,... description: A common mistake in building MCP servers is mapping tools one-to-one onto REST API endpoints, which bloats the model's context window with unnecessary schemas... canonical: https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Design Multi-Context Processing Tools as Capabilities, Not Endpoints | daily.dev og:description: A common mistake in building MCP servers is mapping tools one-to-one onto REST API endpoints, which bloats the model's context window with unnecessary schemas... og:url: https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb og:image: https://api.daily.dev/og/posts/4ZRYpL5Lb.png og:image:alt: Design Multi-Context Processing Tools as Capabilities, Not Endpoints og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Design Multi-Context Processing Tools as Capabilities, Not Endpoints **[Arpit Bhayani](https://daily.dev/sources/arpit-bhayani)** · 2 min read · 1 upvotes · 0 comments ## Summary A common mistake in building MCP servers is mapping tools one-to-one onto REST API endpoints, which bloats the model's context window with unnecessary schemas and wastes tokens. Instead, MCP tools should be designed as capabilities that bundle related operations (like create, update, and permissions for a user) into a single tool that returns a clean summary, while the underlying API stays granular. The MCP layer should act as a service layer deciding what the model needs to see, not a pass-through proxy, though some newer clients now support lazy tool discovery to ease this constraint. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Should I create a separate MCP tool for each REST API endpoint like createUser, updateUser, and getUser? No, mapping MCP tools one-to-one onto REST endpoints is an anti-pattern because every registered tool schema typically loads into the model's context window before a prompt is processed, which wastes tokens and pollutes context. Instead, combine related operations, such as user creation, updates, and permissions, into a single capability-oriented tool like manage_user that returns a clean summary while the underlying API stays granular. _daily.dev surfaces practical MCP design patterns for developers wiring LLM agents to real APIs._ ### Do all MCP clients load every tool schema into context upfront? Most MCP clients today load every registered tool's schema into context before processing a prompt, making a small tool surface important for cost and context efficiency. A growing number of clients now support dynamic or lazy tool discovery, searching for and loading tools on demand instead, but this is not yet the default everywhere, so designing for the common upfront-loading case still matters. _Developers architecting MCP servers can track shifts like lazy tool discovery on daily.dev._ ## Similar posts on daily.dev - [Why MCP Shouldn’t Wrap an API One-to-One](https://daily.dev/posts/why-mcp-shouldn-t-wrap-an-api-one-to-one-m1d3gzxtr) · Nordic APIs · 2 upvotes · 0 comments - [System Design — Designing Intelligent UIs as MCP Client](https://daily.dev/posts/system-design-designing-intelligent-uis-as-mcp-client-jvut4xow4) · Faun · 22 upvotes · 1 comments - [Context Engineering for MCP Servers](https://daily.dev/posts/context-engineering-for-mcp-servers-4wx9ee6ee) · Daily Dose of Data Science \| Avi Chawla \| Substack · 2 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#ai-agents](https://daily.dev/tags/ai-agents), [#mcp](https://daily.dev/tags/mcp), [#rest-api](https://daily.dev/tags/rest-api) [View this post on daily.dev](https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Design Multi-Context Processing Tools as Capabilities, Not Endpoints","url":"https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb"},"datePublished":"2026-09-02T20:27:18.944Z","dateModified":"2026-09-02T22:05:54.640Z","description":"A common mistake in building MCP servers is mapping tools one-to-one onto REST API endpoints, which bloats the model's context window with unnecessary schemas...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3261bb6d4ee67dcc8b0aa276bd4f899c?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3261bb6d4ee67dcc8b0aa276bd4f899c?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Arpit Bhayani","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Arpit Bhayani","logo":"https://media.daily.dev/image/upload/s--Hd9jPPXT--/f_auto,q_auto/v1780213724/logos/arpit-bhayani?_a=BAMAMiWQ0","url":"https://daily.dev/sources/arpit-bhayani"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,ai-agents,mcp,rest-api","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Arpit Bhayani","item":"https://daily.dev/sources/arpit-bhayani"},{"@type":"ListItem","position":3,"name":"Design Multi-Context Processing Tools as Capabilities, Not Endpoints"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/design-multi-context-processing-tools-as-capabilities-not-endpoints-4zrypl5lb#faq","mainEntity":[{"@type":"Question","name":"Should I create a separate MCP tool for each REST API endpoint like createUser, updateUser, and getUser?","acceptedAnswer":{"@type":"Answer","text":"No, mapping MCP tools one-to-one onto REST endpoints is an anti-pattern because every registered tool schema typically loads into the model's context window before a prompt is processed, which wastes tokens and pollutes context. Instead, combine related operations, such as user creation, updates, and permissions, into a single capability-oriented tool like manage_user that returns a clean summary while the underlying API stays granular. daily.dev surfaces practical MCP design patterns for developers wiring LLM agents to real APIs."}},{"@type":"Question","name":"Do all MCP clients load every tool schema into context upfront?","acceptedAnswer":{"@type":"Answer","text":"Most MCP clients today load every registered tool's schema into context before processing a prompt, making a small tool surface important for cost and context efficiency. A growing number of clients now support dynamic or lazy tool discovery, searching for and loading tools on demand instead, but this is not yet the default everywhere, so designing for the common upfront-loading case still matters. Developers architecting MCP servers can track shifts like lazy tool discovery on daily.dev."}}]} ```