# A Connected MCP Server Is Not the Same as a Correct Tool Call > Source: > Published: 2026-08-19 13:32:31+00:00 If you've wired up an MCP server in the last few months, you've probably noticed the icon turns green, the tool list populates, and it feels like the hard part is done. It isn't. The hard part starts right after that. MCP is an access protocol, not a competence protocol. It answers "can this agent reach that API" — it says nothing about whether the agent is calling that API correctly. Those are separable failures, and conflating them is why a lot of debugging time gets spent in the wrong place. A connected MCP server will happily let an agent: None of this shows up as a connection problem. The server is up, the handshake succeeded, the tool icon is green. What's wrong is one layer up, in how the agent is using a tool it can technically reach — and that's much easier to miss because everything upstream of it looks healthy. **1. Read the raw response, not the agent's summary of it.** Ask for the literal JSON/output the tool call returned before the agent's paraphrase. A response that got quietly truncated, paginated, or partially erred often reads as a clean success once summarized — the summary smooths over exactly the thing you needed to see. **2. Spot-check write operations before trusting them in a loop.** A read that's slightly wrong wastes a turn. A write that's slightly wrong — wrong ID, wrong field, wrong scope — persists. If an agent is about to run the same write repeatedly (bulk updates, batch inserts), verify one manually against the actual system before letting it run the rest unattended. **3. Watch for parameter-guessing when the schema is thin.** Some MCP servers expose tools with sparse or ambiguous schemas. An agent facing an underspecified parameter will pattern-match to something plausible rather than stop and ask — which is exactly the confident-wrong-call failure mode, just moved one level earlier. If a tool's schema doesn't fully constrain its inputs, that tool needs closer supervision than one that does, regardless of how reliable the server itself is. The protocol was designed to solve interoperability — one tool built once, usable by any compliant agent — and it does that well. But interoperability and judgment are different problems. MCP standardizes *how a call is made*; it has no opinion on *whether this was the right call to make with these arguments*. That opinion has to come from somewhere else — a system prompt, a skill, a human watching the first few calls — and a green connection status will never tell you it's missing. The practical takeaway: treat "the MCP server connected" as step one of two, not step one of one. The second step — verifying the agent is actually using the tool well — doesn't show up in any status indicator. You have to go look. Full write-up: [https://agentkitworks.com/answers/what-is-mcp](https://agentkitworks.com/answers/what-is-mcp)