How to Build an AI Agent with MCP and Claude

What MCP is and why it beats bespoke integrations

MCP is an open protocol that standardises how AI applications connect to tools and data: you write one MCP server exposing your system's capabilities — search the knowledge base, create a ticket, read a calendar — and any MCP-capable client can use it, including Claude, Claude Code and a growing ecosystem of agent frameworks. Before MCP, every assistant-to-system connection was a custom integration owned by nobody; with it, the integration is a product with a schema, versioning and access control. The protocol is now governed by the Agentic AI Foundation, which is the strongest signal that it has become infrastructure rather than a vendor feature: building on MCP in 2026 is the boring, durable choice.

The anatomy of an agent

Strip away the framework branding and every agent has four parts. The model (Claude via the API, in this guide) does the reasoning: reading context, choosing actions, interpreting results. Tools are the verbs it may use — each one a typed function with a name, a description the model reads, and a schema for its inputs. Memory is whatever persists across steps: the conversation so far, retrieved documents, a scratchpad of intermediate results. And the loop is the orchestration: send state to the model, receive either an answer or a tool call, execute the tool, append the result, repeat. Everything else — planning styles, multi-agent topologies, human-in-the-loop gates — is elaboration on those four parts, and most production agents need less elaboration than the demos suggest.

Designing MCP tools: read, write, and least privilege

Tool design is where agent projects are won or lost, and the first rule is to separate reads from writes. Read tools — search, fetch, list — are safe to grant freely; the worst failure is a useless answer. Write tools — create, update, send, delete — change the world, so each one deserves scrutiny: does the agent need it at all, should it be gated behind human approval, and what is the blast radius if the model calls it with confused arguments?

• Grant least privilege: an agent that answers support questions needs read access to the knowledge base — not write access to the CRM it might "find useful."
• Authenticate the user, not just the agent: the MCP server should enforce the calling user's permissions, so the agent can never read or do more than the human it acts for.
• Make tools narrow and typed: "create_ticket(title, body, priority)" with an enum for priority beats "do_admin_action(json)" — the schema is a guardrail the model actually respects.
• Return structured errors: when a tool fails, a machine-readable reason lets the model recover sensibly instead of hallucinating success.
• Log every call: the tool-call transcript is your audit trail and your debugging tool. An agent whose actions cannot be replayed cannot be trusted in production.

A worked example: a support-ops agent

As an illustrative architecture — not a claimed client project — consider an agent that handles first-line support for a SaaS product. It has three MCP tools: search_docs(query) over the help centre (read), lookup_account(email) returning plan and billing status (read, scoped to the requesting user's org), and file_ticket(summary, severity) into the help desk (write, capped at severity "normal" — anything urgent routes to a human). The loop: a customer message arrives; Claude retrieves relevant documentation and the account state; if the docs answer the question, it drafts a grounded reply citing the source; if not, it files a ticket with a structured summary of what it tried. Two design choices carry the system: the agent can only escalate, never resolve billing issues itself, and every reply includes the doc passage it relied on, so a human reviewer can audit any answer in seconds. Notice how much of this is ordinary engineering — permissions, schemas, logging — and how little is prompt magic.

Evals and guardrails: the difference between a demo and a system

An agent without evals is a liability with a chat interface. Build a test set of representative tasks — real support questions, real edge cases, adversarial inputs — each with expected properties: the right tool was called, the answer cites a source, no write tool fired without grounds. Run it on every prompt or tool change; agents regress silently, and the eval suite is the only thing that notices before your users do. Layer guardrails on top: schema validation on every tool input, spend and iteration caps on the loop (an agent that can retry forever will), human approval gates on consequential writes, and a kill switch that is a config flag rather than a deployment. In development, Claude Code accelerates this work considerably — it can scaffold the MCP server, generate eval cases from your docs, and exercise your tools interactively — but the discipline is yours to keep.

When not to build an agent

If the workflow is deterministic, build a workflow. A sequence of known steps — receive invoice, extract fields, post to ledger, notify channel — wants a pipeline with a single LLM step for the genuinely fuzzy part (extraction), not an agent deciding the sequence anew each run. Agents earn their complexity when the path genuinely varies with the input: triage, research, multi-system troubleshooting, tasks where "figure out what to do" is the job. The honest design question is: would a competent human doing this task follow a checklist? If yes, encode the checklist and spend a tenth as much. Rules are cheaper, faster, auditable and do not hallucinate — put the model only on the steps that need judgement.

Where to start

Start with one agent, three tools and twenty eval cases. Pick a task that is annoying, frequent and low-blast-radius; wire read tools first and prove the agent answers well before granting any writes; put the whole thing behind a feedback button so failures become eval cases. Most teams' first production agent is embarrassingly narrow — and that is precisely why it makes it to production while the ambitious ones stay demos.