MCP Server List: Servers Worth Running for Coding

A practical MCP server list for a coding agent is short, not sprawling: filesystem, git or GitHub, your database, a fetch or browser server, and a screen-context server cover most real work. The right approach is to run a curated set where each server has a narrow, well-named job, because every extra tool is one more thing the model can call by mistake.

Most roundups optimize for length and hand you fifty servers you will never wire up. This one optimizes for what actually earns a slot in your config.

What belongs on an MCP server list?

A server earns its place when it removes friction your agent hits often. If you find yourself pasting the same data in by hand every session, that is a server. If you added something months ago and never see the model use it, that is dead weight.

Three tests decide it. Does the server do one clear job the model can name? Does it return structured results the agent can act on without re-parsing prose? And is it something you reach for weekly, not once?

If you are still fuzzy on the underlying idea, the plain-language explainer on what an MCP server is and the deeper Model Context Protocol writeup cover the mechanics. This piece assumes you know the shape and want the list.

Which MCP servers should be on every coding agent's list?

Start with the servers that touch your code and your history. These are the ones nearly every developer benefits from, regardless of stack.

• Filesystem — scoped read and write to a directory, so the agent works on real files instead of pasted snippets.
• Git / GitHub — read history, open and read issues and PRs, and push changes with review.
• Database — Postgres, SQLite, or your engine, so the agent can read a schema and run safe queries.
• Fetch / web — pull a URL or docs page into context without you copying it in.
• Browser (Playwright / Puppeteer) — drive a real browser for end-to-end checks and scraping.
• Screen context — resolve what is actually on your screen into a named element the agent can act on.

Here is the shortlist as a table, with the job each does and where it runs.

That set covers the majority of day-to-day agent work. If you want a version tuned to one client, the best MCP servers for Claude Code narrows it further with setup notes.

Two of these do more work than the rest. The filesystem server is the one that turns an assistant into an agent, because it lets the model edit real files instead of dictating snippets you paste. The git server is next, since history and diffs are the context that keeps an agent from repeating a change or clobbering yours. Keep those two solid before you add anything clever, and you cover most of the value in two servers.

Which MCP servers help beyond code?

Once the core list is solid, a few team-facing servers pay off, especially if your work spills into tickets and comms. Add these only when you feel the friction, not preemptively.

• Linear / Jira — read and file issues without leaving the agent.
• Slack — post a summary or pull a thread into context.
• Sentry — read a live error and its stack trace.
• Notion / Google Drive — pull a spec or doc the agent needs.
• Memory — a small persistent store so facts survive between sessions.

The pattern holds across all of them. Structured results beat prose every time. A server that returns a typed issue object is more useful than one that returns a wall of text the model has to interpret.

What about a local MCP server list on a Mac?

Local servers are where the interesting capability lives, because a process on 127.0.0.1 can reach things a remote tool never could. Chief among them is the actual state of your screen.

PinVari is a native macOS server of this kind. You hold ⌥⌘A, circle or point at a UI element, and speak; it screenshots, transcribes on-device, and resolves the exact accessibility element you circled, its role, label, and frame, with a confidence score, then exposes it to your agent.

The agent-facing tool, pinvari_next_instruction, returns the resolved element path, the spoken instruction, the region you circled, and a cropped screenshot; pinvari_mark_done closes it. The agent gets a named element it can act on, not a screenshot it has to decode. The longer case is in how a local MCP server gives an agent screen context.

It is honest about the hard cases. On Electron surfaces that build their accessibility tree lazily, it sets AXManualAccessibility and retries until a labeled node appears; on a canvas with no AX tree, it falls back to on-device Vision OCR; below a confidence bar, it asks rather than guessing. All of it runs on-device with no API keys and nothing uploaded by default.

The reason a local server belongs on the list is reach, not privacy alone. A hosted tool can read your GitHub or your database, but it cannot see the window you are looking at right now; a process on your own machine can. That makes screen context a category only a local server can fill, which is why it earns a permanent slot on a Mac developer's list rather than being an optional extra.

For getting any of these running on macOS, the step-by-step is in how to install an MCP server on a Mac.

Common mistakes when building your MCP server list

The failures are predictable, and they are almost never in the servers themselves. They are in how you assemble the list.

The first mistake is hoarding. Twenty servers feel powerful and make the agent worse, because the model now chooses wrong more often. Cut anything you have not seen the agent use in a month.

The second is the config, not the code. A server that will not appear usually points at the wrong executable or has a path typo. Run it standalone first; if it prints its capabilities, the problem is your config.

The third is treating servers as raw pipes. A good server resolves meaning on your side and hands the agent something structured. That is the difference between a screen server that ships pixels and one that ships a named element.

If a screen-context server is the missing piece on your Mac, PinVari is a one-time purchase rather than a subscription, and the details are on the pricing page.

FAQ

What is the best MCP server list for a coding agent?

The best list is short and specific to your work: filesystem, git or GitHub, your database, a fetch or browser server, and a screen-context server. Add team tools like Linear or Sentry only when you hit real friction with them.

How many MCP servers should I run at once?

Fewer than you think. Every server's tools are discoverable by the model, so a bloated list means more wrong tool picks. Most developers do well with five to eight tightly scoped servers.

Is there an official MCP server list?

There are community and vendor directories that catalog available servers, plus reference servers maintained alongside the protocol. Treat any directory as a menu of what exists, not a recommendation of what belongs in your config.

What is an LM Studio MCP server list?

It refers to the set of MCP servers configured for a local model running in LM Studio. The servers themselves are the same standard servers; only the client changes, so a filesystem or git server works whether the model is hosted or local.

Can I run an MCP server list entirely locally?

Yes. Filesystem, git, database, browser, and screen-context servers all run as local processes over stdio on your own machine. On a Mac, a local server can also gather transcription, OCR, and accessibility context on-device with no upload.

How do I add a server from my MCP server list to Claude?

Register it with claude mcp add <name> or the equivalent config entry, point it at the server's executable, and restart the client. Confirm the server and its tools appear in the MCP status view before relying on it.