The MCP servers I built so my agents could do real work

An assistant that writes code is useful. It is also, on its own, a very expensive autocomplete.

The reason is simple: writing the code is rarely the part that takes the day. The day goes on understanding the existing schema, working out how a new feature fits what is already there, writing the ticket, updating the ticket, moving the ticket, and describing what changed to the people who need to know. An assistant that cannot see any of that can only ever help with the smallest slice of the work.

So I built the missing pieces as MCP servers, and the difference was not incremental.

Two servers, two very different jobs

A Jira server. At the end of a working session the agent analyses what actually changed, creates the task describing it, assigns it to me, and moves the statuses to match reality. Not a summary pasted into a chat window — the tracker itself, updated, in the state it should have been in if I had done it by hand and not been mid-thought on something else.

This sounds like administrative convenience. It is really about accuracy. Ticket hygiene decays because updating a ticket is boring and always competing with real work. An agent that reads the diff and writes the ticket from it produces a more honest record than a tired human writing it from memory two days later.

A SQL server. This one is the important one. It lets the agent read the code and the database together.

Almost every integration bug I have ever seen comes from a mismatch between what the code believes the schema is and what the schema actually is. A developer reads an entity class and assumes the table matches. An assistant reading only the code inherits the same blind spot — and states it with more confidence than a human would.

Giving it the actual schema removes an entire category of wrong answer. It stops guessing what a column is called or whether a relationship exists, because it can look.

The line I do not cross

The SQL server points at the test database. Never production.

Not because the agent would do something reckless. Because production access is not a thing you grant on the assumption that nothing will go wrong — it is a thing you decline to grant so that the question never arises.

This works in practice for one specific reason: test and production are always in sync. The schema the agent reads is the schema that is live. It gets a correct answer about structure without ever touching a real customer record.

That is worth stating plainly, because it is the whole design. The safety here does not come from prompting the model to be careful. It comes from the model being connected to a system where the worst possible outcome is bounded — a wrong query against test data. Architecture, not instruction.

The pipeline these plug into

The servers exist to support a workflow rather than the other way around. When work arrives — even a brand new project — it moves through four roles:

1. A .NET architect analyses it with me. Not instead of me. This is the step where the shape of the thing gets decided, and it is the step where being wrong is most expensive, so it stays a conversation.
2. A project analyst turns that into business requirements and tasks a developer can act on without re-deriving the intent.
3. A senior developer implements against the architect's decisions rather than improvising its own structure.
4. A senior tester writes the test cases once the implementation exists.

Each role is narrow on purpose. A single agent asked to architect, implement and test will happily do all three and quietly optimise for finishing, because nothing in the loop disagrees with it. Separating them means the tester is evaluating work it did not write, which is the only arrangement where the evaluation means anything.

MCP is what makes this more than four prompts in a row. The architect can see the real schema. The analyst can write the real ticket. The chain has access to the same context I do, which is why the output is something I can review rather than something I have to rewrite.

What actually changed

The honest summary: I stopped doing the parts of my job that were never the interesting parts.

Not the architecture — that is still a conversation, and it should be. What went away was reconstructing schema from memory, writing tickets after the fact, keeping statuses honest, and re-explaining the same context at the start of every session.

There is a version of this story where AI replaces the engineer. This is not that story. It is much more ordinary and much more useful: the tools finally reach the systems where the work actually lives, and the engineer spends more of the day on the decisions that need one.

If you are building your own

Expose capabilities, not tables. A tool called getCustomerById is a database call in a hat. A tool that answers a question your domain actually asks can enforce its own rules. The narrower the tool, the less there is to get wrong.

Decide what the agent acts as before you decide what it can do. Identity is the security model. Everything else is decoration.

Keep production out of reach and keep test truthful. An agent with an accurate test schema is more useful than one with risky production access, and it costs you nothing to defend.

Split the roles. One agent doing everything agrees with itself. Four agents with separate jobs produce work that has been looked at.