Building Production-Grade AI Agents with Claude and MCP Servers

← All Articles

When my team at Albertsons Companies first started integrating large language models into our Cart & Checkout platform, we quickly realized that simple API calls to Claude weren't enough. We needed agents — systems that could reason, use tools, and act autonomously across our internal services. That journey led us to the Model Context Protocol (MCP), and it fundamentally changed how we think about AI in enterprise engineering.

This article shares real lessons from integrating Claude with MCP servers into a production e-commerce platform serving 2,300+ Albertsons and Safeway stores.

What is MCP and Why Does It Matter?

The Model Context Protocol is an open standard that defines how AI models connect to external tools, databases, and APIs in a secure, structured way. Think of it as a USB standard for AI — instead of writing bespoke integrations for every LLM and every tool, MCP gives you a universal connector.

Before MCP, our integrations looked like this: hardcoded API wrappers, brittle prompt templates, and no standard way to handle tool responses. With MCP, we define tools once with a clear schema, and Claude knows exactly how to invoke them and interpret results.

Architecture: How We Wired Claude into Our Platform

Our MCP setup at Albertsons consists of three layers:

• MCP Host: The process running Claude and managing tool calls — in our case, a Spring Boot microservice
• MCP Servers: Lightweight Node.js or Java services exposing tools like cart lookup, pricing APIs, and order status
• Transport Layer: stdio for local tools, HTTP/SSE for remote services behind our API gateway

Here's a simplified version of how a tool definition looks in our cart MCP server:

// cart-mcp-server/tools/getCartSummary.js
{
  "name": "get_cart_summary",
  "description": "Retrieves the current cart for a given user session including items, prices, and promotions",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sessionId": { "type": "string", "description": "User session identifier" },
      "storeId": { "type": "string", "description": "Store location identifier" }
    },
    "required": ["sessionId"]
  }
}

Real Use Cases: What the Agent Actually Does

Once we had the MCP infrastructure in place, we built several agent workflows that run in production:

1. Checkout Anomaly Detection

An agent monitors checkout sessions in real time. When it detects anomalies — a cart that's been idle for 45 minutes with high-value items, or a promo code being attempted more than 3 times — it uses MCP tools to pull the session state, check the customer's history, and decide whether to trigger a recovery flow or flag for review. What used to be a set of brittle rule-based scripts is now a single agent with clear reasoning.

2. Document Analysis Pipeline

Our architecture decision records, runbooks, and incident reports are PDFs scattered across Confluence. We built an MCP server that exposes document search and retrieval, and Claude can now answer questions like "What was the resolution for the checkout timeout incident in March?" with cited sources. This alone saved hours per week across the team.

3. Engineering Task Automation

Using MCP tools connected to our Jira and GitHub APIs, Claude can triage incoming tickets, suggest assignees based on past work patterns, draft PR descriptions from commit history, and even generate boilerplate for new microservice scaffolding.

Production Considerations

Getting agents to demo is easy. Getting them to behave reliably in production is hard. Here's what we learned:

• Tool schemas are contracts. Treat them like API contracts — version them, document them, and don't break them silently.
• Always cap tool call chains. Set a maximum number of sequential tool calls per agent turn (we use 10). Unbounded loops are real.
• Log every tool invocation. Pipe all MCP tool calls and results to Splunk. When something goes wrong, you need the full trace.
• Human oversight is non-negotiable for write operations. Our agents read freely but write (update cart, trigger refund) only after a confidence threshold check and, for high-value operations, a human approval queue.
• Test tools independently. Unit test your MCP tool handlers before wiring them to Claude. A broken tool produces confusing agent behavior that's hard to debug.

Measuring Impact

Since deploying these agent workflows, we've seen measurable improvements: engineering toil on repetitive documentation tasks has dropped significantly, our checkout anomaly detection catches edge cases our rule-based system missed, and onboarding new engineers has accelerated because the agent can answer "how does X work in our system?" directly from our internal docs.