Wiring MCP Tools into a Claude Cowork Sales Book

Everything an agent does to the real world goes through a tool, and in Claude Cowork those tools arrive as MCP connectors. On a 4,000-account sales book the difference between a system you trust and one you fear is almost entirely in how the tools are wired — not in the prompts. A perfectly written skill calling a sloppily wired CRM tool will still create duplicate emails, corrupt records on retries, and fail in ways nobody can debug. This post is about getting that wiring right: authentication, schemas, error handling, and idempotency.

Model Context Protocol (MCP) is an open standard, introduced in November 2024, that connects Claude to external tools and data through MCP servers; each server exposes a set of typed tools the model can call, and Skills teach the model when and how to use them. That separation — servers expose capability, skills supply judgment — is the frame for everything below.

Authentication: scope narrow, rotate, and never trust the model with secrets

The first wiring decision is auth, and the rule is least privilege. The MCP server should authenticate to your CRM and email provider with the narrowest scope that still does the job. If today's run only needs to read accounts and write activity notes, the credentials should grant exactly that and nothing else. The model never sees the secret; it sees only the tools the server exposes. The server holds the API key, swaps it for the underlying call, and returns results. This means a prompt-injection attempt that convinces the model to "export all credentials" simply has no tool to do it.

Rotate credentials on a schedule and scope them per environment so a staging run can never touch production records. For a sales book specifically, separate read and write scopes into distinct phases of your rollout: ship the server with read tools first, add write tools only after the gate and review queue are proven. The server is also the right place to enforce hard caps — a maximum number of writes or sends per run — so even a runaway orchestrator cannot blow through the whole book in one go.

Schemas: typed, minimal, and self-documenting

A tool's schema is the contract the model reasons against, and tight schemas prevent whole classes of errors. Every parameter should be typed and constrained: an account ID is a string matching a known format, an action is an enum of allowed values, a send target is validated server-side against the account record. Describe each field in plain language in the schema itself, because that description is what the model reads to decide how to call the tool. Vague schemas produce creative, wrong tool calls.

flowchart TD
  A["Skill decides to act"] --> B["Build typed tool call + idempotency key"]
  B --> C["MCP server validates schema & scope"]
  C -->|Invalid| D["Return structured validation error"]
  C -->|Valid| E{"Idempotency key seen?"}
  E -->|Yes| F["Return prior result, no-op"]
  E -->|No| G["Execute against CRM / email API"]
  G --> H["Persist key + result, return to agent"]

The flow above shows where validation lives: at the server, before anything executes. The server re-validates scope and schema on every call — never assume the model honored the contract. Critically, the server is also where the idempotency check sits, before execution, so the protection holds even if the model retries on its own. Keep schemas minimal: expose the handful of tools the book actually needs, well described, rather than a sprawling surface the model can misuse.

Error handling: structured, actionable, and never silent

Tools must return errors the model can act on. A rate-limit error should say it is a rate limit and how long to wait. A validation error should name the offending field. A not-found should be distinct from an empty list. The catastrophic failure mode is the silent one: a tool that swallows an error and returns an empty result, which the model reads as "this account has no recent activity" and then drafts a cold message to a hot, mid-conversation prospect. On a 4,000-account book that pattern, repeated, destroys trust fast.

Classify every error as retryable or terminal at the server, and surface that classification in the response. The agent's logic then becomes simple: retry retryable errors once with the same idempotency key, and turn terminal errors into a clean failure record routed to human review. Because retries carry the original key, a retry after a timeout that actually succeeded on the backend returns the prior result instead of acting twice. This single discipline eliminates the most common and most embarrassing class of agent bug.

Idempotency: the rule that makes retries safe

Idempotency deserves its own section because it is non-negotiable on a book where the same prospect might be touched by multiple runs. Every state-changing call carries a key derived deterministically from the account, the action type, and a logical occurrence — for example a hash of account ID plus "daily-note" plus the date. The server records keys it has executed and their results. A second call with the same key does not act; it returns the first result. Timeouts, network blips, and over-eager model retries all become harmless.

Design the key so that legitimately distinct actions get distinct keys while accidental duplicates collide. A follow-up email on Tuesday and a different follow-up on Thursday are distinct occurrences and should both go through; two attempts at the same Tuesday follow-up must collide. Getting this granularity right is what lets you run the system aggressively — multiple times a day, with parallel sub-agents — without ever fearing a double-send. Pair it with the per-run write cap on the server and you have hard, mechanical guarantees that no prompt can violate.

Putting it together: a tool call that cannot misbehave

Stack these and a single write becomes hard to get wrong. The skill decides to act and builds a typed call with an idempotency key. The server validates scope and schema, rejecting malformed calls with a structured error. It checks the key and no-ops if it has seen it. It enforces the per-run cap. Only then does it touch the CRM or email API, persisting the key and result. Every layer is deterministic code on the server side, outside the model's control — which is exactly where your irreversible-action guarantees belong.

The payoff is operational calm. You can let parallel sub-agents work hundreds of accounts knowing the worst a misbehaving agent can do is generate a structured error or hit a cap. That confidence is what makes autonomous operation on a large book practical rather than terrifying, and it all lives in the wiring, not the prompts.

Frequently asked questions

Where should authentication live — in the agent or the MCP server?

In the server. The model never sees secrets; it only sees the tools the server exposes. The server holds credentials, scopes them to least privilege, and swaps them for the underlying API call, so prompt injection has no credential to leak.

How do idempotency keys prevent double-sends?

Each state-changing call carries a key derived from the account, action, and occurrence. The server records executed keys and returns the prior result for repeats, so retries after timeouts or model re-tries become harmless no-ops.

What's the worst way to handle a tool error?

Silently returning an empty result. The model can't distinguish it from "no data" and acts on a false premise. Always return structured, classified errors that say what failed and whether to retry.

Should read and write tools ship at the same time?

No. Ship read tools first so you can build and test the full pipeline with zero risk, then add write tools only after the gate, dedup, and review queue are proven. The server can also cap writes per run as a hard backstop.

Bringing agentic AI to your phone lines

CallSphere wires MCP tools the same way for voice and chat — least-privilege auth, typed schemas, structured errors, and idempotent writes — so its agents can answer every call, act mid-conversation, and book work 24/7 without ever double-acting. 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.