Week7 Server

Part of my journey leveling up automation skills as the field shifts toward AI. This week is about Model Context Protocol (MCP) — instead of pasting data into a prompt, the LLM is handed a small set of tools and decides for itself which ones to call, in which order, to answer a question.

Why this week matters: hardcoding data into a prompt doesn't scale past a demo. MCP is the emerging standard for "here are your tools and data sources, go" — it's what lets an agent plug into a live system instead of a snapshot.

The architecture

[client.py asks a question]
            |
            v
[Claude sees 3 tool definitions — no invoice data in the prompt]
            |  decides which tools to call, with what arguments
            v
[MCP server (server.py): list_invoices / get_invoice / get_purchase_order]
            |  returns live data over stdio
            v
[Claude reasons over the results and answers]

Continuity: Week 2 extracted an invoice from a document. Week 6 decided what to do with an invoice exception, given data the bot already had in hand. This week, the data itself lives behind an MCP server — an agent fetches its own facts instead of having them handed to it. Combine this with Week 6's policy-guarded decision service and you get Portfolio Project #4 on the roadmap: an agent that both looks things up and hands the judgement call to an auditable rule layer.

What's here

File	Role
src/server.py	The MCP server — exposes list_invoices, get_invoice, get_purchase_order
src/client.py	Spawns the server and drives it from Claude — no server process to start separately
tests/test_server_tools.py	Unit tests for the tool functions — no API key needed

1. Run it

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
# copy .env.example to .env and paste your key

python src/client.py

client.py spawns server.py itself over stdio (that's how MCP typically works for local tools — no HTTP port to manage, unlike Week 6). Watch the [MCP tool call: ...] lines print as Claude decides what it needs to look up.

Run the unit tests for the tool logic (no API key needed):

pytest

2. The key design idea: tools + data over a standard protocol

Before MCP, "give the model a tool" meant hand-rolling a JSON schema and a dispatch if/elif for every project. MCP standardizes that: server.py declares tools once with @mcp.tool(), and any MCP-speaking client — this repo's client.py, Claude Desktop, another team's agent — can discover and call them the same way. That's the "connecting agents to real tools" pitch: the tool-provider and the agent don't need to be written by the same person.

3. What I learned / production-ready vs. not

• MCP separates who owns the data from who reasons about it — the server doesn't know or care which LLM is calling it.
• Model choice matters here too: this is orchestration (deciding which tool to call), not hard judgement, so a cheap/fast model (claude-haiku-4-5) is the right call — save Opus-tier reasoning for the kind of decision Week 6 makes.
• Not production-ready: the "ERP" is an in-memory dict, the server has no auth, and there's no real MCP resource (only tools) — a production version would likely expose invoice records as MCP resources too. (Weeks 8+.)

Stack

Python · MCP (official Python SDK) · Claude (claude-haiku-4-5 for tool-driving) · Anthropic SDK · pytest