Wiring MCP Tools Into an AEI-Style Analytics Agent

A measurement pipeline like the Anthropic Economic Index does not live in a vacuum. To classify real work, the agent doing the labeling has to reach out: pull the latest taxonomy from a service, write fact rows to a warehouse, look up an occupation mapping, maybe enrich a conversation with metadata. The moment your Claude agent needs to touch external systems, you are in Model Context Protocol territory — and getting the wiring right is where most teams quietly accumulate bugs.

This post is about the unglamorous half of building an AEI-style analytics agent: connecting MCP servers correctly. Authentication, schema design, error handling, and idempotency are what separate a demo that classifies ten conversations from a system that reliably classifies ten million. We will go tool by tool through the decisions that matter.

Key takeaways

• Model Context Protocol is an open standard that lets Claude call external tools and data sources through MCP servers with a consistent contract.
• Keep tool schemas narrow and self-describing so Claude calls them correctly without trial and error.
• Auth belongs in the MCP server, never in the model's context — Claude should never see a raw credential.
• Every write tool must be idempotent so retries from a non-deterministic agent never double-count.
• Return structured errors the model can reason about, not stack traces it will hallucinate around.

What MCP gives the analytics agent

Model Context Protocol is an open standard, introduced in late 2024, that connects Claude to external tools and data through a uniform server interface — each server exposes a set of tools with declared schemas, and Claude calls them as needed during a task. For an analytics agent, that means the taxonomy service, the warehouse, and any enrichment APIs all present the same shape to the model: named tools with typed inputs and structured outputs.

The value is decoupling. Your classification prompt does not hardcode how to write a fact row or fetch the current taxonomy; it just calls append_fact or get_taxonomy, and the MCP server handles the messy specifics. This is what lets the same agent run against a dev warehouse and a prod warehouse by pointing at a different server — no prompt changes.

Designing the tool surface

The agent for an AEI-style system needs a small, deliberate set of tools. Resist the temptation to expose your whole database; expose exactly the verbs the classification loop performs. The flow below shows how a single conversation moves through those tools.

flowchart TD
  A["Conversation arrives"] --> B["get_taxonomy (MCP, read)"]
  B --> C["Claude classifies task + mode"]
  C --> D["map_occupation (MCP, read)"]
  D --> E{"append_fact idempotent?"}
  E -->|Dup key| F["Server returns existing, no-op"]
  E -->|New| G["Insert fact row"]
  G --> H["Return ack to agent"]

Three tools carry the whole workload: a read tool for the taxonomy, a read tool for occupation mapping, and a write tool for facts. Keeping the surface this small means Claude almost never picks the wrong tool, and each tool is easy to secure, version, and test in isolation.

Schemas: narrow, typed, self-describing

The single biggest predictor of whether Claude uses a tool correctly is the quality of its input schema and description. Be specific about types, enums, and required fields, and write descriptions that explain when to call the tool, not just what it does. The write tool's definition should look like this:

{
  "name": "append_fact",
  "description": "Record ONE classified conversation. Call exactly once per conversation after classification. Idempotent on conversation_id.",
  "input_schema": {
    "type": "object",
    "properties": {
      "conversation_id": {"type": "string"},
      "task_id": {"type": "string"},
      "interaction_mode": {"enum": ["augmentation", "automation"]},
      "observed_date": {"type": "string", "format": "date"}
    },
    "required": ["conversation_id", "task_id", "interaction_mode", "observed_date"]
  }
}

Note the description telling the model to call it exactly once and that it is idempotent. Schemas are documentation the model actually reads — a precise one removes whole classes of misuse before they happen.

Auth: keep credentials out of the model

The hard rule of MCP auth is that Claude should never see a secret. The MCP server holds the warehouse credentials and the API keys; the model only sees tool names and schemas. When the agent calls append_fact, the server authenticates to the warehouse using credentials from its own environment, not from anything in the conversation. This keeps secrets out of logs, out of context windows, and out of any chance of being echoed back in a response.

For multi-tenant setups, scope auth per connection at the server, not per tool call in the prompt. The server should know which tenant's warehouse it is wired to from its configuration, so a misclassified tenant id in the model's output can never cross a data boundary. Authorization is an infrastructure concern; do not push it into the prompt.

Idempotency: the rule that saves your counts

Agents are non-deterministic and they retry. A network blip, a timeout, a re-planned step — any of these can cause the agent to call append_fact twice for the same conversation. If your write is not idempotent, you have just double-counted, and double-counted facts silently corrupt every aggregate downstream. The fix is to key writes on the conversation_id and make the second insert a no-op.

Implement it at the storage layer with a unique constraint and an upsert: insert if absent, return the existing row if present. The server then reports success either way, so the agent never sees an error that would tempt it to retry yet again. Idempotency here is not an optimization — it is a correctness requirement for any system whose entire purpose is accurate counts.

Error handling the model can reason about

When a tool fails, what you return to Claude shapes what it does next. A raw stack trace invites hallucinated recovery; a structured, intentional error message guides correct behavior. Return a small object: a stable error code, a human-readable message, and whether the operation is retryable. For a transient warehouse timeout, {"error":"warehouse_timeout","retryable":true} tells the agent to back off and retry; for a bad task_id, {"error":"unknown_task_id","retryable":false} tells it to stop and re-classify instead of looping.

The principle is that the MCP server, not the model, decides what is recoverable. By encoding retryability explicitly, you keep the agent from burning tokens on doomed retries or, worse, fabricating a success it never achieved.

Common pitfalls when wiring MCP

• Exposing too many tools. A broad tool surface confuses the model and widens your attack surface. Expose only the verbs the loop needs.
• Leaking credentials into context. If an API key ever appears in a prompt or tool argument, it can be logged or echoed. Keep all auth server-side.
• Non-idempotent writes. Retries will double-count facts and quietly inflate your metrics. Key writes on a stable id and upsert.
• Returning raw exceptions. Stack traces make the agent improvise. Return coded, retryable-flagged errors instead.
• Vague tool descriptions. If the description does not say when to call a tool, Claude will guess. Spell out the contract in the description.

Wire it up in 6 steps

1. List the minimal verbs your classification loop needs and expose only those as MCP tools.
2. Write narrow, typed input schemas with descriptions that state when to call each tool.
3. Put all credentials in the MCP server's environment; never pass secrets through the model.
4. Make every write tool idempotent on a stable key with a unique constraint and upsert.
5. Return structured errors with a code and a retryable flag, and let the server decide recoverability.
6. Scope auth per server connection for multi-tenant safety, not per model-supplied argument.

Read tools vs. write tools

Concern	Read tools (get_taxonomy)	Write tools (append_fact)
Idempotency	Naturally safe	Must enforce on a key
Caching	Cache aggressively	Never cache
Error retry	Cheap to retry	Retry only if idempotent
Auth scope	Read-only credential	Scoped write credential

Treating reads and writes differently — caching reads, hardening writes — is the mental model that keeps an MCP-backed analytics agent both fast and correct under real load.

Frequently asked questions

What is Model Context Protocol in one sentence?

Model Context Protocol is an open standard that connects Claude to external tools and data through MCP servers, each exposing tools with declared input schemas that the model calls during a task.

Where should authentication live in an MCP setup?

Entirely in the MCP server. The server holds credentials in its own environment and authenticates to downstream systems itself, so Claude only ever sees tool names and schemas — never a secret.

Why does idempotency matter so much here?

Because agents retry non-deterministically, and a duplicated write double-counts a fact, which corrupts every aggregate built on top of it. Keying writes on a stable conversation id and upserting makes retries safe.

How should tool errors be returned to Claude?

As small structured objects with a stable error code and an explicit retryable flag, decided by the server. This guides the agent to back off, re-classify, or stop — rather than improvising recovery from a raw stack trace.

Tool-using agents on your phone lines

CallSphere brings these same MCP-backed agentic patterns to voice and chat — assistants that answer every call, call tools mid-conversation with proper auth and idempotency, and book work 24/7. See it live 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.