Agents that ship.
MCP servers that hold up in production.
Start with the page you are reading. It was produced by an agent pipeline I built and run every working day: the posting goes in, an agent parses it, generates this site, writes the outreach, deploys to Cloudflare, then logs the whole application to Airtable through an MCP server. That is the difference between having read the MCP spec and running tool calling in production where a bad schema costs you real work.
Three failure modes that show up at scale.
Your responsibilities list names memory, context management, and tool calling specifically, which tells me you have already hit at least one of these. Here is how I read them.
Demos well, fails in production
A tool calling loop that works on three test prompts breaks on the fourth when a schema is ambiguous or a tool returns an error shape nobody handled. The gap between demo and production is error handling and schema discipline, not model choice.
Context filled with noise
Every tool result dumped straight into the window burns budget and degrades reasoning long before any hard limit is reached. Without a deliberate memory and retrieval strategy, agents get slower and less accurate as the session grows.
Integrations only one person understands
Custom plugins get built fast and then the tool schemas live in one engineer's head. Six weeks later nobody can safely add a tool because nobody knows what the model is actually being shown.
Schema first. Evals before opinions.
I build MCP servers in Python or TypeScript depending on what your stack already runs, and I treat the tool schema as the primary interface rather than an afterthought, because tool selection accuracy is a writing problem before it is a code problem. Every tool gets typed inputs, an explicit error shape the agent can reason about, and idempotency on anything that writes, so a retry never doubles a record. Context is managed deliberately: results get summarized or referenced rather than dumped, large tool catalogs load on demand instead of consuming the window before work begins, and what stays resident is a decision rather than an accident. Third party systems (CRM, databases, Slack, Google Workspace) connect through the MCP layer with scoped credentials rather than admin keys, and where a workflow is genuinely deterministic I will put it in n8n or Make instead of an agent, because not everything should be an agent. Every behavior change gets measured against an eval set built from real failure cases, so we know whether a prompt or schema edit actually helped instead of arguing about it. And every tool ships documented, with its schema, failure modes, and extension path written down, so the next engineer is never reverse engineering what the model can see.
The first month. Phase by phase.
You mentioned this could become ongoing, so this is scoped as a ramp rather than a one off project. Each phase produces something running that you can inspect.
- Inventory of current agents, tools, and MCP servers with what each one actually does in production
- Map of every third party system in scope plus the auth model and rate limits for each
- Tool schema review identifying which descriptions are causing wrong tool selection, and why
- Backlog ranked by production impact rather than by build difficulty
- MCP servers built in Python or TypeScript to match the stack you already run
- Tool schemas written description first, since selection accuracy is a writing problem
- Typed inputs, explicit error shapes, and idempotency on every write operation
- Local and remote transports so the same server runs in development and production
- Tool calling loops with retry, fallback, and graceful degradation when a tool is unavailable
- Context strategy defining what stays resident, what gets summarized, what is retrieved on demand
- Deferred tool loading so a large catalog does not consume the window before work starts
- Eval set built from real failure cases so behavior changes are measured rather than assumed
- CRM, database, Slack, and Google Workspace connections wired through the MCP layer
- REST, GraphQL, and webhook integrations with rate limit handling and backoff built in
- Scoped credentials so agents hold least privilege instead of admin keys
- n8n or Make used where a deterministic workflow beats an agent, because not everything should be one
- Tracing on every agent run so failures are diagnosable instead of mysterious
- Written docs per tool covering the schema, the failure modes, and how to extend it safely
- Regression evals wired in so a prompt or schema change cannot silently degrade behavior
- Ongoing cadence agreed: weekly priorities, async updates, and live working sessions when they help
Four weeks. Audit to ongoing.
Each week ships something running rather than a status update. Click any week to see exactly what lands.
Deliverables this week
- Inventory of every agent, tool, and MCP server with its real production behavior documented
- Map of third party systems in scope with auth model and rate limits per system
- Tool schema review naming which descriptions cause wrong selection and the rewrite for each
- Backlog ranked by production impact with the first build target agreed
Deliverables this week
- MCP servers built in Python or TypeScript matching your existing stack
- Tool schemas written description first and tested for selection accuracy
- Typed inputs, explicit error shapes, and idempotency on every write path
- Local and remote transports both working so one server covers dev and production
Deliverables this week
- Tool calling loops with retry, fallback, and graceful degradation when a tool is down
- Context strategy live: what stays resident, what summarizes, what retrieves on demand
- Deferred tool loading so large catalogs stop eating the window before work begins
- Eval set running against real failure cases so every change is measurable
Deliverables this week
- CRM, database, Slack, and Google Workspace connected through the MCP layer
- REST, GraphQL, and webhook integrations with rate limit handling and scoped credentials
- Tracing on every agent run plus regression evals guarding against silent degradation
- Documentation per tool delivered and the ongoing working cadence agreed
Let's open the code together.
A 30 minute call where I share my screen and show you the agent pipeline that produced this page: the MCP server it writes through, the tool schemas, how tool calling and error handling are wired, and where the context strategy sits. Then we talk about your agents and what is currently breaking. You mentioned this could become ongoing, and that is the shape I am looking for too.