Putting MCP to Work Inside the Company

Lately I’ve been wiring MCP into our internal work, one piece at a time. Nothing as grand as standing up a platform — just enough to wrap a few internal services in MCP so the things I already do (handling issues, building and deploying, keeping docs in order) can be finished from inside Claude Code. After living with it for a while it stuck better than I expected, so here’s a light writeup of how it went.

Starting With Issue Handling

The first thing I wired up was issue management. I put our internal issue tracker’s API up as MCP tools — give it an issue number and it pulls the detail and the comment thread. Then I went a step further. Instead of just calling the tool, I baked the whole flow into a skill: fetch an issue, analyze it, and carry it through to a fix. It reads the issue, narrows down what needs changing, and follows through to touching the code, all in one pass.

Build, Test, Deploy

Once it’s fixed, it has to ship. I build it, put it on the dev server, run a user test, and then deploy — and that deploy prep goes through a file server (webhard) MCP, a tool that uploads the artifact to the file server.

What I cared about here was permissions. MCP means, in the end, that the AI is holding the tools and moving them itself. So I couldn’t let it touch the whole existing deploy system. I split permissions by path. The real release path got read-only — the AI can look, but it can’t write. Write access is open only on the QA-handoff path used for testing. That one path is the only place the AI can upload a file.

This file server MCP got reused in a way I hadn’t planned for. Later, when I was standing up a test service built on a different server library, I pulled in the same MCP as-is. A tool you build once gets used elsewhere — which is exactly the payoff of keeping it as a module.

Auto-Commenting the Issues After Deploy

Once a deploy finishes, the issues I fixed this round need the handling notes and the deploy path written back to them. Do it by hand and you’ll always miss one or two. So at the moment the deploy completes, each fixed issue gets its handling items and deploy path posted as a comment automatically.

What I liked here is that I don’t have to author the comment’s raw material separately. As I work, I split the process into fine-grained git commits, so what changed and how is already spelled out in the commit log in detail. There’s no need to summarize the work by hand — the MCP just pulls it from the commit log and rephrases it in terms that fit the issue.

And this turned into an unplanned payoff. The same MCP that pulls work history out of commits, I later reused as-is for writing sprint reports and weekly reports. What I did over a week is already recorded in the commits, so the report grows from the same source. One connection, built once, ended up taking a bite out of reporting work too.

Docs Go to the Wiki

A fix doesn’t end at the code. It has to live on as a dev note so the next person finds it. So I built a wiki MCP too, and had it push the dev note for each change straight to the internal wiki.

Any developer knows this stall: the code keeps changing, and the docs can’t keep pace. Every time you touch a feature, updating the manual, leaving a dev note, writing the release note — all of it gets pushed to later. That gap, where code and docs drift apart, is a pain developers carry for a long time.

After wiring in the wiki MCP, that pain mostly went away. What I just fixed is already in the commits and the handling record, so the cost of shaping it into a manual, a dev note, or a release note and posting it to the wiki collapsed to nearly zero. It stopped being a matter of writing docs from scratch and became one of exporting work I’d already done, once more. Development and documentation no longer run on separate tracks — they line up into one.

One Module, Three Services Run Separately

To sum up: the internal MCP server is bundled as a single module. Inside it, three services — issue management, file server, wiki — each run separately, switchable on and off. I turn on only what I need at the moment.

And once I set this up at the user scope, it’s available across every project, not just one. No reconfiguring per project. Install it once and it’s there everywhere, so the more I use it the more useful it gets.

Next Up: Test Automation

Having come this far, the how-to and the setup of MCP are reasonably in hand now. Which stirs up the next appetite. Beyond unit tests for our internal solution, I think I can take a run at automating the user-test side too. That’s a story for a separate post.