The best MCP servers for software engineering, and the tools to hold back

I keep a short list of servers connected to the agents I use for Statio itself, and it has changed a lot this year. What has not changed is the first thing I do with a new one: read its tools/list and decide which tools the agent never gets. The popular servers are good. Several of them also ship a tool that can merge to main, read decrypted secrets or run arbitrary code, sitting next to the read tools you wanted.

So for each pick below there is a tool count, the version it was checked against, and the tool to hold back. Where we have a full guide with every tool listed, it is linked.

The short list

You do not need all of these at once. Every connected server puts its tool descriptions into the model's context, and an agent with 200 tools picks the wrong one more often. Too many tools has the numbers. I run three or four per agent, chosen for the job.

For code: GitHub

GitHub's official server is the one everyone starts with, and it deserves it. Version 2.0.2 exposes 46 tools in its default toolsets and 91 with all of them on. 27 of the default tools only read.

The other 19 write, and they include merge_pull_request, push_files and delete_file. A coding agent needs to branch, push and open a pull request. It does not need to merge, approve its own review or create repositories. A triage bot needs add_issue_comment and nothing else. The server's --read-only flag and --toolsets help, but they apply to everyone connected to that instance. How to give an agent read-only GitHub access goes through the token, the flags and per-tool grants.

For issues: Linear or Jira

Linear's hosted server has 68 tools, 30 of which change something. It now reaches into code review, so a coding agent connected to it can call merge_diff and submit_diff_review. Hold both back. A triage agent should not get deletes, status changes or share_issue.

For Jira, the package most teams run is the community mcp-atlassian, which brings 16 Jira tools and 24 Confluence tools together. Only seven of the 40 write, and none delete, so it is one of the safer servers here. If an agent only needs Jira, leave the Confluence tools off, since they do nothing for it and fill its context.

For errors: Sentry

Sentry's server lists 15 tools, and one of them, execute_sentry_tool, can call about 60 more, including ones that delete alert rules and change DSNs. Granting it grants the lot. An agent that investigates errors needs the search and issue tools. I also keep analyze_issue_with_seer away from unattended agents, because it runs Sentry's paid AI analysis on every call.

For docs: Context7

Context7 fetches current documentation for a library, so the model stops writing code against an API from two years ago. It has two tools, resolve-library-id and query-docs, and both only read. This is the one server on the list I connect everywhere without a second thought. The hosted endpoint works without a key; a key raises the rate limit.

For the browser: Playwright

Playwright MCP lets an agent open pages, click and fill forms through the page's accessibility tree, which makes it the usual pick for testing a UI change end to end. It runs on your machine; there is no hosted version.

Read its README before you connect it. browser_run_code_unsafe is in the default set, and the README itself calls it equivalent to remote code execution. It also says --allowed-origins and --blocked-origins are not a security boundary. If the agent only needs to look at pages, deny browser_run_code_unsafe and browser_evaluate, and think twice about browser_file_upload.

For the database: Supabase, or Postgres in read-only mode

Supabase's server has 29 tools. The one that matters is execute_sql, which takes any statement at all, so the only real control is starting the server with read_only=true. Also hold back apply_migration on production, deploy_edge_function and merge_branch.

For plain Postgres, the reference server in the MCP repository is archived and its npm package is deprecated. Postgres MCP Pro is the common replacement, and it has a restricted mode that only reads. Its install examples use the unrestricted mode, so change that before an agent touches a database you care about. Neon and Prisma Postgres also run hosted servers.

For operations: Grafana or Datadog

mcp-grafana covers dashboards, datasources, alert rules, incidents and OnCall. Its writes include alerting_rules_write, which creates and deletes alert rules, and update_alert_group, which acknowledges and resolves pages. --disable-write turns them all off. If you run it over HTTP, set --server-auth-token. Without it the server accepts any caller, which is how Pillar Security forged sessions on it this summer.

Four MCP security incidents goes through that one and the control that would have stopped it.

Datadog's server is hosted only and still described by Datadog as under significant development. It picks tools by toolset, and an organization setting, MCP Write Access, hides every write tool. Turn that off for agents that only investigate. Otherwise they can delete dashboards and notebooks or change feature flag environments.

Two I would be careful with

Vercel's server can deploy to production, and get_project_env returns environment variables decrypted. That is a lot of reach for an agent you wanted to read build logs. If you connect it, deny the env tools and production deploys.

The reference Filesystem and Git servers are fine for a local agent working in one checkout. Give Filesystem only the directories it needs, and remember Git includes git_reset.

Questions