Wiring MCP servers into Claude agents the right way (Built With Opus Hackathon)

The fastest way to lose half a hackathon is a flaky tool integration. At a Built-with-Opus event, the demos that died on stage almost always died at the tool boundary — an expired token, a schema the model couldn't satisfy, a retry that double-charged a card. This post is specifically about wiring tools and MCP servers into a Claude Code agent so they hold up: auth, schemas, error handling, and idempotency, in that order of how often they bite.

Model Context Protocol is an open standard, introduced in late 2024, that connects Claude to external tools and data sources through MCP servers — small programs that expose typed tools the agent can call across a process or network boundary. Getting that boundary right is unglamorous and absolutely decisive.

Auth: the failure that happens at the worst time

Authentication failures love to surface mid-demo because tokens expire on their own schedule, not yours. The first rule is to keep credentials entirely out of the model's context. The agent should never see an API key; the MCP server holds the secret and the agent simply calls a named tool. This is both a security boundary and a reliability one — a token that lives only server-side can be refreshed without touching the agent at all.

The second rule is to handle expiry proactively. Wrap outbound calls in the MCP server so that a 401 triggers a single token refresh and one retry, transparently, before the tool ever returns to the agent. The model should not have to reason about auth lifecycle; that is plumbing, and plumbing belongs in the server. The teams that exposed raw auth errors to the model watched it invent creative, wrong workarounds. The teams that handled refresh in the server just kept working.

flowchart TD
  A["Claude emits tool call"] --> B["MCP server validates args vs schema"]
  B -->|Invalid| C["Return structured arg error"]
  B -->|Valid| D["Check idempotency key"]
  D -->|Seen before| E["Return cached result"]
  D -->|New| F["Attach auth + call external API"]
  F -->|401| G["Refresh token, retry once"]
  F -->|5xx| H["Backoff retry, then structured error"]
  G --> F
  F -->|200| I["Store result under key, return"]

Schemas: design them for the model, not just the API

An MCP tool's input schema is a prompt as much as a validation rule. If your schema mirrors a messy underlying API — fifteen optional fields, cryptic enum codes, nested objects three levels deep — the model will fill it out badly. Design a clean, narrow schema that expresses the few things the agent actually needs to decide, and let the server translate that into the full API payload. Fewer, well-named, well-described fields produce dramatically more reliable tool calls.

Put a human-readable description on every field, and prefer explicit enums over free strings wherever the API expects a fixed value. An enum turns a guessing game into a multiple-choice question the model rarely gets wrong. And always validate on the server: when arguments fail validation, return a structured error naming the offending field, so the model can correct itself on the next turn instead of failing opaquely.

Error handling: make failures legible

Tools fail constantly in the real world — rate limits, timeouts, transient 5xxs — and the agent needs to reason about those failures, not crash on them. The discipline is to convert every failure into a structured result with a stable shape: a success flag, an error code, a human message, and where relevant a retry hint. { ok: false, error: "rate_limited", retry_after: 30, message: "Hit provider rate limit" } tells the model exactly what to do next.

Distinguish three error classes because the agent should treat them differently. Transient errors (timeouts, 5xx, rate limits) warrant a bounded retry, ideally inside the server with backoff. Permanent errors (bad input, not found) should return immediately so the model can change approach. Fatal errors (auth permanently broken) should surface clearly to the user via the agent rather than being silently retried into a token-burning loop. Collapsing all three into one generic failure is how agents waste budget hammering a wall.

Idempotency: the one that double-charges customers

This is the rule that, when skipped, causes the scariest bugs. Agents retry. Loops re-run. A model that doesn't see a clear success will often call a tool again. If that tool creates an order, sends an email, or charges a card, a naive retry does the action twice. The fix is idempotency keys: for any tool with a side effect, require or generate a stable key derived from the meaningful arguments, and have the server deduplicate on it. If the same key arrives twice, return the original result instead of repeating the action.

Implement this at the server, never trust the agent to remember. Store a short-lived map from idempotency key to result; on a repeat call, short-circuit to the cached outcome. This single mechanism turns "the agent retried and sent three confirmation emails" into a non-event. For read-only tools you can skip it, but the moment a tool mutates external state, idempotency is mandatory, not optional.

Putting the wiring together

The order of operations inside a well-built MCP tool handler is the same every time: validate arguments against the schema, check the idempotency key, attach credentials, call the external system with bounded retries on transient failure and token refresh on auth failure, then store the result under the key and return a structured payload. That sequence — visible in the diagram above — is reusable across nearly every integration. Once a team internalized it, new MCP tools went from an hour of debugging to fifteen minutes of filling in a known template.

The meta-lesson from the hackathon: tool wiring is where correctness lives, and the model cannot fix a broken boundary by being smart. Invest the unglamorous hour in auth, schemas, errors, and idempotency, and the agent on top of it suddenly looks reliable.

Frequently asked questions

Should auth tokens ever be passed to the model?

No. Credentials stay server-side in the MCP server. The agent calls named tools; the server attaches auth. This keeps secrets out of transcripts and lets you refresh tokens without touching the agent.

How do I choose idempotency keys?

Derive them deterministically from the meaningful arguments of the action — for an order, the customer and line items; for a message, the recipient and a content hash. The same logical action should always produce the same key so a retry deduplicates cleanly.

Where should retries live — in the agent or the server?

Bounded retries for transient errors belong in the server, with backoff, so the agent isn't burning model turns on plumbing. The agent should only see a failure after the server has exhausted sensible automatic recovery.

How narrow should an MCP tool's schema be?

As narrow as the decision the agent actually makes. Expose only the fields the model must choose, name them clearly, use enums for fixed values, and let the server expand them into the real API call.

Bringing agentic AI to your phone lines

CallSphere's voice and chat agents call MCP-wired tools mid-conversation — booking, lookups, payments — with this exact auth and idempotency discipline so nothing double-fires on a live call. See it working at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.