Model Context Protocol tools are becoming the new browser extensions of AI development. There are thousands of them, they all promise to make an agent smarter, and installing too many of them can leave the agent slower and more confused than when it started.

The five projects examined here aren’t random MCP servers produced by anonymous developers. They include official tools from GitHub, Microsoft, Upstash, Oraios, and the MCP steering group itself:

• GitHub MCP Server
• Playwright MCP
• Context7
• Serena
• Model Context Protocol reference servers

They solve very different problems. GitHub MCP connects an agent to GitHub. Playwright MCP lets it operate a browser. Context7 retrieves current software documentation. Serena gives it IDE-like knowledge of a local codebase. The MCP reference repository provides examples for building or running more general tools.

Would they help with the actual projects we’ve worked on like a cross-distribution installation pipeline, a stock market model, an evolutionary reproduction model, or a warfare modeling project?

Popularity

GitHub stars don’t count as product reviews. They measure attention, name recognition, bookmarking, and community interest as much as actual use. Still, they provide a rough indication of which projects have gained traction.

As of July 22, 2026:

Project	GitHub stars	Forks	General position
Model Context Protocol servers	88,800	11,300	The ecosystem reference repository
Context7	59,600	2,900	Most popular specialized tool in this group
Playwright MCP	35,400	2,900	Widely adopted browser automation tool
GitHub MCP Server	31,600	4,600	Official GitHub integration
Serena	26,700	1,800	Smaller but strongly focused coding toolkit

The MCP reference repository leads by a large margin, but that’s partly because it represents an entire ecosystem rather than one tool. It includes reference implementations for filesystem access, Git, memory, web fetching, time conversion, and sequential thinking. The project itself warns that these are educational examples, not production-ready services.

Context7 has the largest following among the single-purpose tools. Playwright MCP and GitHub MCP are close enough that their star counts don’t tell us much about which is more useful. Serena has the smallest audience of the five, but it may have been one of the most useful for our larger codebases.

GitHub MCP Server

GitHub MCP Server connects an AI agent directly to GitHub. It can browse repositories, inspect files and commits, work with issues and pull requests, examine GitHub Actions results, review security findings, and automate repository workflows. GitHub offers both a hosted remote service and a local server.

The official implementation also allows individual tools or groups of tools to be enabled. For example, an agent can be given access to repositories, issues, pull requests, Actions, or security information without receiving every available GitHub capability. Read-only mode can override write tools, which is important when the agent only needs to inspect a project.

What people like

The strongest argument for GitHub MCP is that it brings repository management into the same working session as the coding agent. The agent can inspect a failing workflow, read the associated pull request, compare changes, examine an issue, and then explain what probably broke.

Some users report that GitHub and database integrations are among the few MCP servers that provide clear practical value. That makes sense. GitHub contains useful state that isn’t always present in the checked-out repository: issue discussions, review comments, Actions logs, release history, branch status, and pull-request metadata.

It also comes from GitHub itself. That’s preferable to installing a third-party server that requires a personal access token with access to private repositories.

What people dislike

The main complaint is context bloat. GitHub exposes a large tool catalog, and those tool definitions consume part of the agent’s context before any work begins.

One user reported that the GitHub MCP server consumed about 23 percent of the available context even after trying to limit its toolsets. Another comparison reported 32 percent initial context use with GitHub MCP enabled and 8 percent without it. These are individual observations rather than controlled benchmarks, but they identify a real design problem: an agent can spend a surprising amount of its attention learning how to operate GitHub instead of examining the code. There’s also considerable overlap with the existing git and gh command-line tools. A capable coding agent can already run:

git log
git diff
gh issue view
gh pr view
gh run view

For local repository work, the MCP server can become an expensive wrapper around commands the agent already knows. Host compatibility hasn’t always been smooth either. There have been reports of the tools failing to appear correctly in OpenCode and of features behaving differently outside GitHub Copilot.

Where it would’ve helped us

GitHub MCP would’ve been useful in the multi-OS project deployment project, especially after the work split into two repositories.

Pipeline A modifies multi_os, rebuilds the release artifact, and passes it to Pipeline B. Pipeline B works in os_master, installs the artifact on clean virtual machines, runs certification, and returns defects to Pipeline A.

We’ve been moving information between those two pipelines manually through long status reports. GitHub MCP could’ve allowed an agent to:

• Read the latest Pipeline B certification issue.
• Find the corresponding artifact version or commit.
• Check whether Pipeline A already had a repair branch.
• Create structured issues for each installer defect.
• Follow the repair through its pull request.
• Check the Actions or certification results before closing the issue.

It also could’ve helped manage the evolutionary reproduction and warfare modeling paper repositories, especially when figures, generated PDFs, source code, and experiment reports drifted apart. I wouldn’t give it broad write access by default. For our projects, I’d enable only repositories, issues, pull requests, and Actions, then start in read-only mode. The local agent can still use git for normal code work.

Verdict: Useful as a project coordination layer, but unnecessary for most local editing.

Playwright MCP

Playwright MCP gives an AI agent control of a real browser. Instead of relying primarily on screenshots, it reads structured accessibility snapshots containing buttons, fields, links, headings, and other page elements. The agent can navigate pages, click controls, enter text, and inspect the result. This is different from asking an AI model to look at a screenshot and guess where to click. Accessibility snapshots give the agent named elements and references it can operate more deterministically.

What people like

For basic user-interface checks, Playwright MCP works well. Users report success with sanity checks such as opening an application, navigating through a workflow, clicking controls, and confirming that the expected elements appear. It can also test Chromium, Firefox, and WebKit through Playwright’s underlying browser support. That matters because a browser simulation that works in one environment can still fail elsewhere. Microsoft describes the accessibility approach as faster and more deterministic than screenshot-based interaction. A small accessibility snapshot can also be much cheaper than sending a full screenshot to a vision model.

What people dislike

The same accessibility snapshots that make Playwright MCP useful can become enormous on complicated pages. There are reports of snapshots consuming the entire remaining context on large sites. Other users have measured individual snapshots in the tens of thousands of tokens. Microsoft now says coding agents may be better served by the Playwright command line combined with agent skills. The CLI avoids loading large MCP schemas and repeated accessibility trees into the context. Microsoft still considers MCP useful for exploratory work, persistent browser sessions, and long-running interactive automation.

It effectively means:

• Use Playwright MCP when the agent needs to explore and interact.
• Use Playwright tests or the CLI when the workflow is known and needs to be repeated.

Accessibility snapshots can also miss information that isn’t well represented in a page’s accessibility tree. There have been reports of hidden or off-screen elements confusing agents, while other pages omit useful DOM attributes from the snapshot.

There’s also a security problem. Text placed in an element’s accessibility label can reach the model as part of the snapshot. A malicious page can place instructions there and attempt to manipulate the agent. A reported proof of concept passed prompt-injection text through an aria-label into the agent’s context.

Where it would’ve helped us

Playwright MCP would’ve been immediately useful during our browser simulation work. We repeatedly encountered problems where:

• Buttons didn’t do anything.
• The animation didn’t animate.
• Timeline lines were static.
• A vertical line swept across the graph incorrectly.
• Labels were unreadable.
• The version uploaded to the server didn’t match the local version.
• A required JavaScript function was missing from the deployed files.

A Playwright agent could’ve opened the simulation, pressed Start, Pause, Reset, and other controls, then observed whether the simulation state and displayed metrics changed. It could’ve exercised the timeline repeatedly and checked that new points appeared as the timestep advanced.

It would’ve been particularly valuable after deployment. We could’ve run the same browser workflow against the local files and the copy on our server then compared console errors, loaded resources, button behavior, and graph output. The same applies to the warfare simulation and the reporting app web interface. Playwright could test login, report creation, report rendering, navigation, and error handling. For repeatable regression testing, however, we should convert the final workflow into normal Playwright tests. Leaving the whole job to an autonomous browser agent would cost more tokens and produce less consistent evidence.

Verdict: The most immediately useful tool in the group for our browser projects. Use the MCP server for diagnosis and exploration, then preserve the result as ordinary Playwright tests.

Context7

Context7 retrieves current, version-specific library documentation and puts the relevant sections into the agent’s context. It supports both MCP and a command-line workflow. Its two central operations identify the requested library and retrieve documentation relevant to a specific question. The problem it addresses is real. AI models frequently provide examples for old versions of libraries, combine incompatible versions, or invent methods that don’t exist.

What people like

Context7 has received considerable attention because its purpose is easy to understand. When an agent needs to configure a current version of Next.js, Supabase, MongoDB, Playwright, or another changing library, Context7 can retrieve current examples instead of relying on whatever was present in the model’s training data. Thoughtworks placed Context7 in its Technology Radar and described it as a way to reduce inaccurate code caused by old or generic library knowledge. Community discussions also frequently identify Context7 as one of the more useful MCP tools. Its 59,600 stars support the conclusion that this isn’t a niche experiment, although the star count has also been helped by considerable social-media promotion.

What people dislike

Context7 is only as good as the documentation it indexed. Users have reported incomplete libraries, incorrect package matches, missing documentation, and poor output when the source documentation doesn’t fit the short explanation plus code-example structure the system handles best. Other users question whether fetching documentation and inserting it into the prompt requires a dedicated always-running MCP service. A coding agent can often search official documentation directly, especially when the agent already has web access.

The repository’s issue tracker shows the ongoing maintenance burden. Recent issues include incorrect Ollama JavaScript documentation and requests to refresh stale or missing libraries. Context7 can therefore reduce one kind of hallucination while introducing another failure mode: confidently returning the wrong indexed documentation.

Where it would’ve helped us

Context7 would’ve been useful when we hit library and platform-version problems rather than errors in our own logic.

Examples include:

• Werkzeug and Flask path behavior.
• Current Playwright configuration.
• GitHub Actions syntax.
• Docker networking behavior.
• Ansible modules across different distributions.
• Current Python packaging and lock-file behavior.
• Differences between package versions on Debian, Ubuntu, Fedora, and Rocky Linux.
• Ollama API and network configuration.

It might have prevented some cases where an agent proposed an option from an older software release or assumed that a package behaved the same way across versions. It wouldn’t have solved the difficult parts of the evolutionary reproduction or warfare modeling projects. Context7 can’t tell us whether a biological assumption is valid, whether hindsight information leaked into a warfare classifier, or whether a historical case was misclassified. Those were research and model-design problems, not documentation problems.

Context7 is best invoked when needed. I wouldn’t keep it permanently active and let the agent call it for every routine question.

Verdict: Useful for version-sensitive implementation work, but it should be treated as a documentation lookup service rather than an authority.

Serena

Serena calls itself an IDE for coding agents. It uses language servers and other code-analysis backends to work with symbols, references, functions, classes, and relationships across files. Instead of searching for text and editing by line number, the agent can locate a symbol, find its references, and change it at a structural level. This is the tool in the group most directly aimed at improving the agent’s ability to understand a large local codebase.

What people like

Positive reports focus on code navigation and refactoring. Users say Serena works well on complex repositories because the agent can find definitions and references without repeatedly reading entire files. One user reported that it performed well on a large Python project after correcting an initial language-detection error. Other reports describe strong results when Serena is paired with Codex for symbolic search and targeted editing.

A published engineering benchmark from ManoMano also concluded that Serena’s semantic search and cache helped agents find code in cases where less structured methods failed. The project’s own evaluation reports substantial benefits for cross-file renaming, symbol lookup, moving code, and monorepo navigation. That evaluation comes from Serena’s maintainers and should be treated accordingly, but the claimed advantages match the independent community reports.

What people dislike

Serena requires setup, indexing, and a working language-server environment. That adds another layer of software that can fail before the agent begins solving the original problem. Some users report that Serena slows Claude Code rather than improving it. Others have experienced incorrect language detection, tools failing to appear in the MCP client, or the server failing to start.

There has also been a serious report of Serena consuming approximately 30 GB of memory and freezing the coding session. One issue doesn’t establish that this is normal behavior, but it shows that the indexing and language-server components need monitoring on large repositories. The maintainers warn users not to install Serena through MCP marketplaces because those marketplaces may contain obsolete installation instructions. That’s sensible advice, but it also shows how quickly the MCP installation ecosystem becomes stale.

Where it would’ve helped us

Serena might have had the largest cumulative impact across our code projects. The stock market model accumulated research code, runtime code, policy artifacts, evidence generators, classification functions, and tests. We repeatedly had to determine whether research and runtime paths were using the same canonical function. Serena’s reference search could’ve located every session call, identified duplicate implementations, and shown which code paths bypassed the canonical input builder.

The same applies to the reporting app. We had installation scripts, platform abstractions, package mappings, service handlers, database initialization, release builders, and two separate repositories. Symbol-aware navigation would’ve helped track how installer configuration flowed from source through the release artifact.

In the biology model, Serena could’ve found:

• Every place sink thresholds were used.
• Every figure generator referencing a particular experiment output.
• Duplicate plotting functions.
• Placeholder branches that silently produced blank figures.
• Browser code that still used obsolete simulation behavior.

In the warfare modeling project, it could’ve followed observed DSS, predictive DSS, mechanism classification, preset definitions, simulation termination conditions, and paper table generation across the repository. This wouldn’t have replaced tests. It would’ve reduced the amount of blind text searching needed before deciding what to test. Serena is less valuable for a small script or a simple HTML page. Its advantage grows with repository size, language complexity, and the number of cross-file relationships.

Verdict: Probably the best coding aid in the group for our large Python projects, provided its indexing behavior is controlled and its memory use is monitored.

Model Context Protocol Reference Servers

The modelcontextprotocol/servers repository isn’t one product. It’s a set of examples maintained by the MCP steering group. The current reference servers include:

• Fetch
• Filesystem
• Git
• Memory
• Sequential Thinking
• Time
• An all-purpose test server

Several older examples, including GitHub, GitLab, Google Drive, PostgreSQL, Puppeteer, Redis, Sentry, Slack, and SQLite, have been moved into an archive as official or community-maintained alternatives emerged.

What people like

This is one of the best places to learn how MCP servers are constructed. Developers can examine how filesystem access is restricted, how tools are described, how a memory graph is stored, and how the protocol exposes resources and prompts. The repository is valuable as working documentation. The implementations are small enough to study and modify, and they cover multiple common patterns.

What people dislike

The most important criticism comes from the maintainers themselves: these aren’t production-ready services. They are demonstrations, and users are expected to evaluate and add security controls appropriate to their own environment. The repository’s security information has included concerns such as Git operations being allowed in arbitrary filesystem locations.

The movement of many servers into an archive also means old tutorials can point to implementations that are no longer the recommended option. Installing this repository and enabling several servers at once would also add considerable tool clutter. Research published in 2026 found that tool-selection accuracy can begin to decline as agents are given larger catalogs of tools.

Where it would’ve helped us

The repository would’ve been most useful as a starting point for building our own tools.One example is the worklog system we’ve discussed. A custom MCP server could accept output from ChatGPT, OpenCode sessions on multiple servers, Git commits, test results, and project tags, then write structured entries into an Obsidian daily notes. Another possibility is certification. An MCP server could expose narrowly defined operations such as:

list_certification_targets
read_latest_artifact_manifest
get_vm_certification_status
read_failed_gate_evidence
compare_artifact_hashes
create_pipeline_a_repair_ticket

That would be more useful than giving the agent unrestricted shell and filesystem access. It would encode our actual process, including the distinction between Pipeline A source repairs and Pipeline B deployment certification. The memory server could also preserve project decisions, such as the prohibition against certifying an artifact that was patched directly inside a test VM. However, a plain memory graph wouldn’t enforce the rule. A custom certification tool could.

Verdict: Valuable as a toolbox for building a project-specific MCP server, not as a package to connect wholesale to our agents.

Which Ones Should We Use?

For our projects, I’d rank them this way.

1. Playwright MCP and Playwright CLI

This would’ve produced the fastest visible improvement. It directly addresses the browser simulation failures we’ve spent considerable time diagnosing.Use MCP for interactive debugging. Once the workflow works, convert it into repeatable Playwright tests or a Playwright CLI skill.

2. Serena

This has the broadest potential across all our projects. Symbol-aware search and refactoring could reduce duplicate implementations, stale code paths, and accidental divergence between research, runtime, simulation, and reporting code.

It should be trialed on one repository before becoming part of every agent session.

3. GitHub MCP Server

This would help coordinate issues, pull requests, Actions, and releases, especially across the two reporting project pipelines. It should be configured with a narrow toolset and read-only access whenever possible.

For ordinary local Git operations, the existing CLI is probably enough.

4. Context7

This is worth having available when we’re dealing with a current library or an unfamiliar version. It would’ve helped with several Flask, Docker, Playwright, Ansible, and packaging questions.

It shouldn’t be treated as infallible, and it doesn’t need to occupy every session.

5. MCP Reference Servers

These are worth studying, especially if we build a certification server or an AI-to-Obsidian worklog service.

I wouldn’t deploy them unchanged and call the resulting system production-ready. Their maintainers explicitly say not to do that.

Conclusion

These tools aren’t five versions of the same idea.

Playwright gives an agent eyes and hands in a browser. Serena gives it something closer to an IDE. GitHub MCP connects local work to repository management. Context7 supplies current technical references. The MCP server repository shows us how to build our own connections.

The best combination for our work would probably be:

• Serena for navigating large local repositories.
• Playwright for browser diagnosis and regression tests.
• GitHub MCP for issues, pull requests, Actions, and release coordination.
• Context7 only when version-specific documentation is needed.
• A custom MCP server for Bridge certification and worklog collection.