Building Your MCP: How We Go About It

Start With What Exists

An existing repository contains more than code. It contains decisions. Routes show what the application presents to people. Services and database queries reveal where information comes from. Authentication and ownership checks tell us who may see or change it. Tests describe behaviour the team already expects. If we skip that context and start by inventing MCP tools, we create a second version of the business beside the first one.

We begin by mapping user outcomes to the smallest existing operation that already handles them. A customer may want to find a service, check an order, request a quote, or retrieve a report. The MCP tool should reuse the same domain logic the application trusts rather than copy it into a new handler. That keeps validation, permissions, and business rules in one place.

We also look for things that should stay private. Internal administration routes, arbitrary database access, raw command execution, secret stores, and generic functions that accept almost anything are not useful agent capabilities. They are shortcuts around the application's boundaries. The fact that code exists does not mean an agent should be allowed to call it.

This approach normally improves the repository along the way. We find logic trapped inside page components, inconsistent result shapes, missing ownership checks, and operations that are difficult to test without a browser. Extracting a narrow service for MCP can make the original website cleaner too, as long as we resist turning the project into an unrelated refactor.

Analyse Before Generating

We have captured this workflow in the open-source mcp-generate-skill repository. Its installable `mcpify` skill takes an existing application through analysis, generation, audit, testing, packaging, deployment, connection, publication, and ongoing operation. Those modes are deliberately separate. Analysing a repository is not permission to deploy it, and generating code is not permission to publish a server.

The first useful output is an `mcp-manifest.yaml`, not a pile of wrappers. The manifest records proposed capabilities, their source operations, risk, side effects, and review state. Analysis can propose an entry. Generation is limited to entries that have been approved. Anything destructive, difficult to authorise, or poorly understood stays excluded or disabled until a person resolves the missing evidence.

This is slower than converting every route automatically, but only at the beginning. Bulk generation creates dozens of tools that overlap, leak implementation language, and make the agent guess which one is safe. A reviewed capability map gives us fewer tools with clearer names, narrower arguments, and a reason for each one to exist.

The skill is also useful when a repository already has an MCP implementation. Audit mode can compare the current surface with the real application boundaries. Test mode can exercise it without production credentials or destructive calls. We like that separation because it makes the work reviewable by a technical founder without asking them to read every line of protocol code.

The MCP Boundary

We design the MCP layer to be as deterministic as the underlying business operation allows. If a tool receives the same valid inputs against the same state, it should follow the same rules and return the same shape. A price calculation should calculate. A search should return matching records with their identifiers and source fields. A booking attempt should return a confirmed result or a specific reason it could not proceed.

Deterministic does not mean frozen. Inventory changes, accounts change, and external services fail. It means the server does not improvise around those facts. It reports the current result, uses defined error codes, and leaves uncertainty visible. We do not want an MCP tool composing a persuasive answer when it cannot find the record. That is the agent's job, and the agent needs an honest failure to do it properly.

This separation makes the whole system easier to reason about. The MCP server handles identity, validation, permissions, business rules, side effects, and structured results. The agent decides when a tool is relevant, supplies the arguments, interprets what came back, and explains it to the user. The agent may still misunderstand the result, so high-impact actions need confirmation and the server must enforce its own limits.

Thin wrappers are important here. We do not bury a second decision engine inside the protocol layer. We call the narrowest trusted application service, translate the response into a stable MCP result, and record enough context for testing and operations. That keeps automation close to existing rules and leaves human ownership where the business expects it.

Remote Transport

For a remote MCP server, we generally work with Streamable HTTP. The current MCP specification defines a single endpoint that accepts HTTP POST and GET. Requests arrive through POST. A server can return ordinary JSON for a straightforward response or use Server-Sent Events when it needs streaming and server-to-client messages. A GET request can open an event stream when the server supports that behaviour.

The practical benefit is familiar infrastructure. The MCP endpoint can live beside an existing web application, use the platform's deployment and monitoring, and serve more than one client connection. We can keep a simple server stateless where that fits or issue session identifiers when related interactions genuinely need session state.

HTTP familiarity should not make the endpoint casual. The specification requires Origin validation and recommends proper authentication. We also define rate limits, request sizes, timeouts, logging, and the exact production origins or clients we expect. A public URL is not the same thing as public permission.

We test the transport separately from the business tool. A correct search function can still sit behind a broken initialization sequence, unsupported headers, an invalid content type, or session handling the client cannot follow. Protocol behaviour deserves its own evidence before we connect a real agent.

Inspect Before Connecting

The MCP Inspector gives us a client designed for this stage. The current package can be launched with `npx @modelcontextprotocol/inspector` for its web interface. It also provides CLI and terminal modes, but the web view is a useful first pass because we can connect to the server, inspect what it advertises, and call each capability without involving a general-purpose assistant.

We check discovery first. Are the expected tools, resources, and prompts present? Are internal operations absent? Do names and descriptions tell a client when each capability should be used? Then we test arguments, valid responses, empty results, invalid inputs, permission failures, unavailable dependencies, and timeouts. For any action with a side effect, we verify that the server enforces the approval and authority boundary itself.

The Inspector does not certify that an MCP server is safe. It lets us see and exercise the contract directly. We still need application tests, security review, logs, recovery behaviour, and a final test through the intended host. What it removes is a common source of confusion: wondering whether a bad answer came from the server or from the agent's interpretation.