Building three MCP servers

My first MCP project was Office Assistant, a Python server that lets an agent work with a Microsoft 365 calendar. Recent coding harnesses and first-party integrations can now do much of that out of the box. I would not build the same general-purpose assistant again and pretend the tool list was a product.

The work was still worth doing, because it made the useful lesson obvious. Registering a function as an MCP tool takes minutes. Making it safe to use against somebody's real calendar, a live multiplayer game or a private collection of commercial signals took most of the effort, and that effort went into the domain model and the trust boundary around it, not the protocol.

MCP is an open protocol for connecting language-model applications to context and capabilities. Its server-side primitives are tools, resources and prompts. That common vocabulary is valuable, but it does not decide what the model should see, what it may change, which identity it is acting for, or how a partial failure should be recovered. Those decisions remain application engineering.

This progression changed how I think about MCP. Office Assistant is mostly an adapter around an established service. Delta-V exposes a new machine-facing version of a product that was originally designed for humans. Antenna treats trustworthy context itself as the product. The same protocol sits at the edge of all three, but the important architecture is behind it.

Office Assistant exposes ten tools for profiles, calendars, events, availability and rooms. It uses the official Python MCP SDK and FastMCP, with an asynchronous Microsoft Graph client held for the server lifespan. The public repository has 179 collected tests, strict type checking, linting and a coverage gate. The interesting part is not the decorators, it is everything that has to happen before and after a Graph request.

The authentication point is easy to underestimate. A command-line application can stop and ask the user to visit a URL. An MCP server normally speaks JSON-RPC over its output stream. Mixing a human prompt into that stream corrupts the transport. Office Assistant therefore reports a typed authentication-required condition and lets the host bring the person back into the loop.

The Graph client also distinguishes a permission error from a token that can be refreshed. Retrying every 403 is wrong, and so is treating every 403 as permanent. The surrounding code records the Graph error code, a safe message, request identifiers and retry guidance without handing raw upstream responses to the model. This is the sort of unglamorous boundary code that makes a tool usable.

I would not try to sell Office Assistant today. Calendar operations are becoming a standard harness capability, and Microsoft is the natural provider of the broad integration. I would only return to it for a narrow workflow with specific business rules that the generic tools do not understand. The project remains useful public evidence that I can integrate delegated OAuth, a complicated API and an agent transport without treating any of them as a toy.

Delta-V was a different problem. It is a simultaneous-turn strategy game with fog of war. Human players use a browser and WebSockets. AI players need a compact observation, legal candidate actions, a way to wait efficiently, protection against stale turns, and an identity that does not expose the credentials used by the browser game.

The public MCP design document describes three transports: local stdio, local HTTP for development and hosted Streamable HTTP on Cloudflare. The hosted endpoint is stateless between requests. A Durable Object owns each live game and session, so reconnecting to the MCP transport does not invent a second source of truth.

Keeping the agent identity separate from its match capability is the part I would defend hardest. Authentication answers who is calling. The match token answers which seat in which game that identity may operate. Binding the second to the first prevents a leaked match token being useful to a different caller, while still keeping low-level player credentials out of model context.

The observation builder is more important than the transport. Sending the entire game object would have been the easy option, but it would reveal hidden state and force every agent to reverse-engineer internal structures. Delta-V instead produces a purpose-built observation filtered for one player. Candidate actions are generated by the game rules, not hallucinated by the model, and may include a recommended index without taking choice away from the agent. The implementation is public in the shared observation builder.

Simultaneous turns also mean an apparently valid action can become stale while an agent is thinking. The action tool fills in the current phase and turn guards, attaches an idempotency key, and can wait for both the action result and the next observation. A rejected move is a normal game outcome, not an MCP transport failure. That distinction gives the model a sensible recovery path.

I built a separate unrated sandbox so agent experiments do not pollute human matchmaking or public ratings. The repository includes a sandbox smoke test and a six-agent harness. This taught me that a collection of valid tool schemas is not an evaluation. The real test is whether several agents can join, observe, act, recover and finish a game under the same timing and visibility rules as the live system.

Antenna started from a problem I kept encountering while using agents: the model could search for facts, but it did not have a small, maintained set of the signals I actually use to make decisions. A fresh exchange rate, a product-usage trend and a manually curated commercial constraint do not all have the same source, freshness or sharing rights. Flattening them into a prompt loses the information that makes them trustworthy.

Antenna is a personal signal layer, and the source is public. The browser is for curation and inspection. The MCP server gives an agent collections, individual signals, histories, templates and a morning-brief prompt. Read tools are deliberately unsurprising. Write tools are where the design becomes more careful.

An agent may propose a new signal, but proposal and confirmation are separate operations. Confirmation fills in approved configuration; the Worker then resolves connector authority and source policy again on the server. The browser or model cannot simply assert that a private source is public, or turn an unapproved URL into an authorised connector. Removing and reordering signals are owner-scoped, and reordering must name every current signal exactly once.

The last point came from operating the thing, not reading a quick-start. A long-lived idle stream is a poor fit for this deployment path, and a Worker making a network request back to itself can turn into an opaque platform timeout. The hosted route instead uses Streamable HTTP requests with JSON responses and dispatches shared logic internally. Local stdio and hosted HTTP construct the same server and register the same capabilities.

Antenna also clarified the difference between an MCP server and an agent skill. MCP exposes capabilities and data. The skill tells an agent how to use them: read before writing, inspect source and freshness, propose a change, ask for approval, then confirm. The protocol cannot carry the whole operating policy by itself, and a prompt is not an access-control system. The server still validates every write.

The easiest way to make an MCP server is to convert every API endpoint into a tool. It is also usually the wrong interface. An API is organised around the implementation. An agent needs a small set of operations organised around outcomes, with enough context to choose safely and enough structure to recover when the outcome is not available.

Office Assistant combines the Graph calls needed to find a meeting time rather than asking the model to reproduce Graph's query language. Delta-V returns legal candidates with the observation rather than exposing an arbitrary write to the game state. Antenna gives collections and histories rather than making the agent stitch together rows from storage. Both Cloudflare's MCP guidance and Anthropic's advice on writing tools for agents now say the same thing: focused, goal-shaped tools generally perform better than a mechanical copy of a complete API.

It is also why the generic calendar surface was commoditised while the other two systems were not: a provider can supply a standard adapter broadly, but Delta-V's hidden-state observation model and Antenna's source and approval policy belong to their products. A protocol makes those capabilities portable; it does not make the domain work generic.

An error message for an agent should answer three questions: what happened, is retrying sensible, and what can be changed before the next attempt? Raw exceptions rarely do that.

This taxonomy belongs in tool results and tests. It keeps an agent from turning a recoverable domain event into a failed session, and it keeps a permanent denial from becoming an expensive retry storm.

Local stdio makes it tempting to keep everything in the server process. That is fine for a single-user adapter whose durable state lives in Microsoft Graph. It breaks down for a remote endpoint where requests may land on different isolates or a client reconnects.

Delta-V keeps game and session state in Durable Objects, including bounded event buffers for each seat. Antenna keeps collections, grants and source configuration in its application storage. In both cases the MCP endpoint can be restarted without losing the truth. Transport sessions are useful for negotiation and delivery, but they should not quietly become the only database.

I now start remote MCP design by writing down four identities separately: the person or agent, the OAuth client, the transport session and the domain capability being exercised. If those collapse into one token or one in-memory object, reconnects, revocation and auditing become much harder than they need to be.

A language model can read JSON, but that does not mean every JSON object is a good observation. The right view is smaller than the database, more explicit than the UI state and shaped around the next decision.

For Antenna that means attaching the source, update time, status and history that qualify a value. For Office Assistant it means stable event identifiers and normalised times rather than the incidental layout of an upstream response. For Delta-V, an abbreviated compact observation looks like this:

{
  "version": 1,
  "gameCode": "QK7M",
  "playerId": 0,
  "state": { "turnNumber": 6, "phase": "astrogation", "activePlayer": 0 },
  "candidates": [
    { "type": "astrogation",
      "orders": [{ "shipId": "p0s0", "burn": 2, "overload": null }] },
    { "type": "astrogation",
      "orders": [{ "shipId": "p0s0", "burn": 0, "overload": null }] }
  ],
  "recommendedIndex": 0,
  "summary": "Turn 6, Phase: astrogation\nActive player: YOU\nYOUR SHIPS: ...\nENEMY SHIPS: ... (undetected)\nCANDIDATES: ..."
}

This is partly about token cost, but mostly about correctness. A compact observation narrows the space in which the model can misunderstand the system. The same contract can then drive tests, evaluation harnesses and other agent transports.

Across all three I would add behavioural evaluations earlier. Unit tests prove that handlers validate inputs and map outputs. They do not prove that an agent selects the right tool, recognises a stale observation, stops at an approval boundary, or completes the whole task without unnecessary calls.

The source is public at tre-systems/antenna-public under the MIT licence, released for self-hosting and experimentation. I did not publish it because code alone creates a business, but because it is the strongest single demonstration of the lessons in this article.

It combines a Preact application, a Cloudflare Worker, D1 and R2 persistence, OAuth 2.1, local and hosted MCP transports, connector policy, source rights, scheduled refreshes and human-approved writes. Publishing the implementation lets an employer or contributor inspect claims that a screenshot cannot prove. It also makes the hosted service easier to trust: the code is open while convenience, managed connectors and operation remain services.

The public repository is not the private one with its visibility flipped. It carries a licence, a security policy, contribution guidance, a code of conduct, example environment files and a documented local first-run path, with personal deployment assumptions removed. The tests and architecture documents are part of the release.

There is still a commercial caveat. Source availability is not a moat, but neither is keeping an unknown application private. The defensible parts are trusted connectors, a well-maintained source registry, operational reliability and the judgement encoded in how signals are curated. Open source can support employment, consulting and adoption. It does not remove the need to find people who have the problem.

The common thread is not that I know how to add an MCP dependency. It is that I can take an agent integration through the parts that appear after the tutorial:

Those are ordinary distributed-systems, security and product-design concerns in a new interface. That is why the work interests me. Models and harnesses will keep improving, and many generic tools will become built in. The harder problem remains: giving an agent exactly enough authority and context to do useful work in a real system, then being able to explain what happens when it goes wrong.