Agents And Tool Use hard
A platform team wants the same internal tools (ticket search, docs lookup, deploy status) available from an IDE assistant, a chat app, and a CI bot. Each is built on a different model host. An engineer proposes exposing the tools through the Model Context Protocol (MCP). What does that decision actually buy?
- A A shared model runtime that executes tool calls on behalf of every connected host, so hosts can drop their own execution and retry logic.
- B A security layer that sandboxes each tool and enforces per-user permissions automatically, regardless of which host connects.
- C One integration per tool via a standard discovery and invocation protocol; auth, approval gates, and selection quality stay with you.
- D A shared schema format that is trained into each host's model, so tool definitions no longer consume tokens in the prompt.
Answer: C. One integration per tool via a standard discovery and invocation protocol; auth, approval gates, and selection quality stay with you.
**MCP is a protocol**, not a model or an enforcement layer. It standardizes how servers expose tools and how hosts discover and call them, so N hosts and M tools need N plus M integrations instead of N times M. Authorization, approval gates, and keeping the tool set small remain your job, and a remote server adds a network hop. For a single host with two tools, direct function calling is simpler.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- You are defining a 'schedule_meeting' tool for an agent. Which schema decision most reduces wrong or malformed calls?
- A model emits three parallel tool calls: `get_inventory`, `get_price`, and `get_shipping`. To cut latency, the host appends each result to the transcript as it arrives and immediately re-invokes the model. Runs start failing with malformed-request errors, and some produce hallucinated shipping costs. What should the host do?
- A team splits a coding agent into planner, coder, tester, and reviewer agents, and each receives the full transcript of the previous agent. The expected quality gains did not appear. Cost tripled, and the reviewer often fixates on approaches that earlier agents abandoned. When is a multi-agent split actually justified?
- A support agent should remember each customer's preferences across months of sessions. The team appends every past session summary to the system prompt. After six months, prompts exceed 80,000 tokens, latency has doubled, and the agent sometimes ships to an address the customer replaced weeks ago. What redesign fixes both problems?
- A teammate proposes splitting a single coding agent into five agents, arguing that more agents means smarter results. When is a multi-agent split actually justified?
- A data-analysis agent runs model-generated Python inside the same container as your API service. That container has database admin credentials in environment variables. A security review flags this as critical. What is the best mitigation?