Development MCP servers

Repos, CI, editors and the rest of the toolchain.

Development MCP servers give an assistant the same tools you have open in another window: the repository, the container runtime, the browser it renders in, the error tracker that tells you what broke in production. They are the category most people install first, because they close the loop between an agent that can describe a fix and an agent that can make one.

The distinction that matters here is between servers that read and servers that act. A server that inspects a Docker daemon or reads a Sentry issue is safe to hand an agent early — the worst outcome is a wasted call. A server that restarts a container or commits code changes the state of something you care about, so it belongs behind a token you have deliberately scoped.

Most of these run locally over stdio, which means no network hop, no hosted middleman and no third party holding your credentials. The server process starts when your client starts and exits with it.

Development MCP servers in this directory

What people build with development MCP servers

Debugging from the error, not the description

Point the agent at an error tracker and it reads the actual stack trace, the release it first appeared in and how many users hit it — instead of working from your paraphrase of the bug.

Reproducing an issue in a real browser

Browser-automation servers let the agent load the page, click through the flow and read the console. A layout bug it can see is a layout bug it can fix.

Working inside the container, not around it

A Docker server lets an agent list containers, read logs and check what is actually running, so 'works on my machine' becomes a question it can answer itself.

Turning a code review into a patch

Combined with a version-control server, the agent reads the diff, runs the check, and opens the follow-up pull request in the same session.

Choosing a development MCP server

  • Start with the one that removes the most copy-and-paste from your day. If you spend it pasting logs into a chat window, install the log source first; the rest can wait.
  • Prefer servers marked Official for anything that writes. They track their own product's API changes, which community wrappers frequently do not.
  • Check what the server needs before you install it. A server that wants a personal access token with full repository scope is a different proposition to one that reads a local socket.
  • Watch the tool count. A server exposing sixty tools spends a large part of the model's context describing itself before it has done anything; a focused server usually gets better results.

Before you connect one

Development servers sit closest to the things that break: production deploys, container runtimes, source history. Give each one its own credential rather than reusing your personal token, and start read-only until you trust the pattern.

Frequently asked questions

Which development MCP server should I install first?

A version-control server, in almost every case. Reading repository contents and diffs makes every other tool the agent has more useful, because it can finally see the code it is being asked about.

Do development MCP servers run my code?

Some do and some do not, and the difference is worth checking. A repository server reads and writes files through an API. A container or shell server executes commands on your machine. Read the tool list on the server's page before you connect one.

Can I use these with my company's private repositories?

Yes — these servers authenticate as you, using a token you supply, so they see exactly what that token sees. Scope it to the repositories you want the agent working in rather than issuing an organisation-wide token.

Install any of these

Every server on this page carries a one-line install command on its own listing. Paste it into your client config and restart — the development tools appear in your next session.

Or keep browsing: all MCP server categories · the full MCP server list · Agent Skills.