3 MCPs That Turned Claude Into My Operations Hub

Every "must-have MCPs for Claude Code" list I have read shares a flaw: it is a list of things the author installed, not things the author kept. Those are different lists. Installation costs one command; keeping a server means it earned its context window and its permissions for months. So here is the honest version. My production Laravel repo has exactly one MCP server in its .mcp.json, and my Claude Code setup runs exactly two more through plugins. Three total, each surviving because it does something Claude cannot do at all without it.

That is my selection bar, and I would argue it should be yours: an MCP server must add a capability, not a convenience. Claude Code already reads files, runs shell commands, and searches the web. A server that wraps what the agent already does is paying context rent for nothing.

Why "fewer servers" is a feature

Before the list, the mechanism that makes restraint pay: every connected MCP server loads its tool definitions into your context window, whether or not you use them that session. Stack five chatty servers and you have spent a meaningful slice of your context before typing your first prompt, and you have widened your permission surface for tools you rarely invoke. When I audit someone's sluggish Claude Code setup, unused MCP servers are the first thing I remove and the removal is always felt.

With that lens, here are the three that survive in my daily stack.

1. Laravel Boost: the framework brain

This is the one server checked into my repo's .mcp.json, and the config is two lines:

{
    "mcpServers": {
        "laravel-boost": {
            "command": "php",
            "args": ["artisan", "boost:mcp"]
        }
    }
}

Laravel Boost runs inside your application, which is precisely what makes it irreplaceable. It is not "docs search." It is your app answering questions about itself:

• search-docs returns Laravel, Livewire, and Filament documentation matched to the versions in your composer.lock. This kills the single most common failure mode of AI-assisted Laravel work: confidently generated code for the wrong major version. My repo's instructions file literally codifies "use search-docs before searching elsewhere" because the version-accurate answer beats the web's most popular answer.
• tinker executes real PHP in the app context. The agent can test an Eloquent query against real relationships instead of hallucinating one.
• database-schema and database-query let the agent read the actual schema before writing a migration or debugging a relationship, instead of inferring it from model names.
• last-error and read-log-entries mean "why did that just fail" is answered from the actual log, not from guesswork.
• list-routes settles every "what is this route actually named" question instantly, which matters when your conventions demand named routes.

What it replaced for me: the tab-cycle of docs site, Telescope, TablePlus, and terminal tinker that used to orbit every non-trivial backend task. If you write Laravel with Claude Code and install only one server ever, it is this one. (Boost is Laravel-specific, but the pattern generalizes: the highest-value MCP for any stack is the one that lets the agent interrogate your running application.)

2. Chrome DevTools MCP: eyes on the rendered page

The second server, installed as a Claude Code plugin, gives the agent a real Chrome instance: navigation, screenshots, console messages, network requests, performance traces, and Lighthouse audits.

The daily use case is humble and constant: verification. My working rule, written into my project instructions, is that frontend changes get verified at desktop, tablet, and mobile widths before they count as done. With DevTools MCP, the agent does that itself: resize, screenshot, inspect, fix, repeat. During my blog's token-driven redesign this loop ran dozens of times a day, and it caught real breakage I would have shipped, including a site-wide tablet header overflow that only appeared at exactly the md-to-lg breakpoint range.

The less humble use cases earn their keep too:

• Console-first debugging. "Load the page and read the console" resolves most JavaScript mysteries in one round trip instead of a guessing dialogue.
• Network inspection. Watching the actual requests catches the class of bug where the markup is right and the fetch is wrong: broken asset URLs, unexpected redirects, cache headers not doing what you think. On a site with edge caching in front of it, header verification is not optional.
• Performance traces and Lighthouse. Core Web Vitals regressions get caught while the change is still one diff, not after Search Console notices.

What it replaced: me, alt-tabbing to a browser to check the agent's homework, which at some point I realized was the least automated step in an otherwise automated loop.

3. Playwright MCP: hands on the page

DevTools MCP is eyes; Playwright MCP is hands. Also installed as a plugin, it drives a browser through structured actions: click, fill, submit, wait, assert, across whole user flows.

The moment it became permanent in my stack: a lead form on one of my production pages had been silently broken by two interacting bugs (a captcha field that was never set, and a caching middleware stripping the session cookies the form needed). The fix touched middleware, config, and the form itself. No unit test honestly covers "a real guest, with a real session, on the cached page, submits successfully." A Playwright-driven end-to-end run does exactly that, and the fix shipped only after the agent had performed the full submission flow like a human visitor and confirmed the record landed.

Since then the pattern repeats weekly: any change touching forms, auth flows, Livewire interactions, or anything else stateful gets a scripted browser pass before merge. This is the same capability I explored from the CLI side in Playwright browser automation with Claude Code; the MCP version simply makes it native to the agent loop.

Why keep both browser servers when they overlap? Because they answer different questions. DevTools answers "what is the page doing?" (console, network, rendering, performance). Playwright answers "does the flow work?" (multi-step interaction and assertion). I have kept both for months precisely because neither made the other redundant.

What did not survive

The list of servers I have removed is longer than the list I kept, and the reasons repeat:

• Filesystem and git wrappers: duplicated built-in abilities with an extra failure layer. The most common redundant install I see.
• Database GUI servers (generic SQL-over-MCP): redundant once Boost exists, and a wider write-permission surface than I want an agent holding by default.
• Big connector suites: impressive tool counts, but each one loads schemas for dozens of services I touch monthly at best. The context tax ran ahead of the usage. For occasional needs, connecting the specific service for that session beats a permanent stack fixture.

None of these are bad software. They failed my particular test: daily use, unique capability, worth their context. Your production stack should generate your list; if you are on Rails or Django, your "Boost" is whatever gives the agent your framework's introspection, and my picks are wrong for you in the details while being right in the shape.

If you are starting from zero, the general setup mechanics are in my MCP setup guide for Mac, and the wider set of habits this stack plugs into is in 50 Claude Code tips.

The rule, restated

Add an MCP server when it gives the agent a sense it lacks: your framework's introspection, a browser's eyes, a browser's hands. Skip it when it wraps something the agent already does. Audit quarterly, and let removal be the default verdict for anything you cannot remember using last week.

Sitting behind this three-server stack is a library of prompts I have refined across hundreds of real sessions — SEO audits, deploy checks, migration reviews. They live in my prompt library, and they show what having those three extra senses is actually for.