Monitoring a competitor who publishes no feed is the case every RSS guide skips. Twenty-one platforms sorted by which of three jobs they do, and the finished setup is business process automation you own outright, with no seat licence to renew.
Blaming the content is the reflex when a post underperforms, and it is usually the wrong diagnosis. A second reader decides distribution before any human sees the post, and most of what it checks is mechanical enough to automate business processes around, on five platforms at once.
Gloves on, tape measure in hand — nobody types a query. Three voice surfaces for ai automation tools (terminal, Telegram, Discord), 10 TTS and 6 STT providers compared on cost and latency, plus a setup that costs nothing.
Already running MCP servers? This is the operator's manual: which server to reach for in each workflow, the pitfalls that bite in production, permissions, context bloat, leaked keys, surprise invoices, and the audit prompts that keep it lean and secure.
Nothing in a small company degrades faster than a system nobody owns. Whoever set it up moved on, it kept working, and so it never acquired a review date or a name written against it. The mechanism is specific and it is not neglect. Adding to a stack takes thirty seconds and any one person can do it, while taking something out requires knowing what depends on it, which by then nobody does. Stacks only ever accrete. Deciding in advance who is permitted to remove things is the least interesting and most load-bearing choice you will make about an ai assistant for business.
You already ran the setup. Brave Search answers questions, Firecrawl pulls pages, GitHub reads your repos. MCP (Model Context Protocol) is in your toolchain — and now the real questions start.
Which server do you reach for when a task could fit three of them? Why did Claude Code slow down after the sixth install? Why did a teammate's key end up in a public dotfiles repo? When does "free tier" quietly become a paid invoice?
This is the operator's manual. It assumes MCP is already running and focuses on what comes next: which server to pick for each workflow, the pitfalls that hit production, and the audit prompts that keep a setup lean, secure, and fast. If you instead need the from-zero walkthrough — what MCP is, the USB-C analogy, the Host/Server/Connection model, and copy-paste install prompts for eight scenarios — read the Model Context Protocol Guide 2026 first. This article builds on that foundation.
Three operating rules separate MCP setups that compound from setups that drift into chaos. None of them are about installation.
Every server you install injects tool descriptions into the AI's context window at session start. Three to five active servers is the sweet spot. Past seven, tool selection accuracy degrades visibly — the AI takes longer to pick, sometimes picks wrong, and reasoning quality drops because attention is spread across too many tool signatures.
I learned this the hard way. After an enthusiastic weekend of installing twelve servers, Claude Code sessions slowed noticeably, the wrong tool got picked on a regular basis, and trimming back to five fixed both instantly. Keep the rest configured but disabled; activate them only when a specific task demands it.
If two servers can both "search the web," the AI burns tokens deciding which to call. Pick Brave Search OR Tavily, not both. Pick Firecrawl OR Playwright's scraping primitive, not both. Overlap is worse than redundancy — it actively degrades selection quality. The AI doesn't know which one you prefer, so it guesses, and guesses wrong a non-trivial percentage of the time.
MCP servers accumulate. You install one for a project, finish the project, forget to remove the server. Three months later your context window is full of unused tool descriptions and you wonder why sessions feel sluggish. Run the audit prompts in section six once a month. They take two minutes and pay for themselves the first time they catch a stale server.
When a task could fit multiple servers, this matrix breaks the tie. It assumes you already have the eight scenarios from the complete guide installed and are deciding which one to call.
| Workflow | Primary server | Why not the alternatives |
|---|---|---|
| "What's the current state of X?" | Brave Search | Firecrawl is slower and burns quota on a single answer; Context7 only covers libraries |
| "Read this specific URL" | Firecrawl | Brave returns a snippet, not the full page; Playwright is overkill for static content |
| "Read this React app's rendered output" | Firecrawl with waitFor, or Playwright | Brave and Context7 can't render JS |
| "What's the latest API for library X?" | Context7 | Brave returns blog posts that may be outdated; the AI's training data is stale |
| "Open this URL, click login, fill the form" | Playwright | Firecrawl is read-only; Brave has no browser control |
| "List open issues in my repo" | GitHub | Brave returns search results, not structured repo data |
| "Read the design tokens from this Figma file" | Figma | Screenshots lose exact spacing and color values |
| "Why did production break?" | Sentry + Vercel (paired) | GitHub shows code, not runtime; Brave shows nothing internal |
| "I need Jira + Slack + Notion in one session" | Composio | Installing three separate servers blows the five-server budget |
The pattern: read-only lookups go to the cheapest server that returns structured data. Anything that requires session state or interactivity needs a real tool. When two servers overlap, the tiebreaker is "which one returns structured data the AI can reason over" — unstructured HTML always loses.
If the task is "find" → Brave. If it's "read a URL" → Firecrawl. If it's "read a library's API" → Context7. If it's "click and fill" → Playwright. If it's "my own repo" → GitHub. If it's "why is production broken" → Sentry plus Vercel. If it's "design data" → Figma. If it's "multiple SaaS platforms" → Composio.
Some servers are more valuable together than apart. When you plan your five-server budget, think in pairs.
Search + Scrape (Brave + Firecrawl). Brave finds the URL; Firecrawl reads the full page. This is the default research pair. Install both first; together they cover 80% of "AI needs external information" tasks. The workflow is always: search to discover, scrape to understand.
Code + Docs (GitHub + Context7). GitHub reads what's in your repo; Context7 reads what the library's current documentation says. Together they answer "given my code and the current API, what should I change?" — which is most refactoring work. Without Context7, the AI suggests patterns from its training data; without GitHub, it can't see what you've already written.
Runtime + Errors (Vercel + Sentry). Vercel tells you when a deploy broke; Sentry tells you why. Without both, you're reading half the diagnostic. Vercel says "deploy failed at 14:32"; Sentry says "TypeError in line 47 triggered by null user object." Pair them or skip both.
Browser + Design (Playwright + Figma). Use Figma to read the intended design, implement it, then use Playwright to verify the rendered output matches. This is the design-to-code QA loop. Without Playwright, you ship designs that drift; without Figma, you eyeball spacing from screenshots.
Pairs that don't compound: installing both Brave Search AND Tavily. They do the same job. Installing both Filesystem AND GitHub when your code is already on GitHub — Filesystem becomes redundant for code work. Installing both Playwright AND Firecrawl when your scraping is read-only — Firecrawl is faster and cheaper for static content.
This is the section I wish someone had handed me six months ago. Each pitfall is real, observed in production, and fixable with a prompt.
Symptom: The AI takes longer to respond, picks the wrong tool, or forgets instructions mid-task.
Cause: Every installed server injects tool descriptions into the context window at session start. A server with 8 tools can add 2,000–4,000 tokens of overhead before you've typed anything. Stack seven servers and you've burned 15,000+ tokens on tool descriptions alone — tokens that aren't available for actual reasoning.
Fix: Run the audit prompt in section six and disable servers you haven't used in the past week. The threshold I use: if a server didn't get called in the last 5 sessions, disable it. The reclaimed tokens show up immediately as faster, more accurate responses.
Symptom: A GitHub MCP server that can read every repo your account can read, including private client work.
Cause: When installing GitHub MCP, the easiest path is a classic personal access token with full scope. The server then operates with your full account permissions. If the AI is told to "find the issue," it searches across every repo you can see. If a session log leaks, every repo name in your account leaks with it.
Fix: Use fine-grained PATs scoped to specific repositories. The complete-guide installation prompts already include this requirement, but it's the most commonly skipped step. If you skipped it, run the cleanup prompt in section six. The minute of reconfiguration is worth not having to explain to a client why their codebase name showed up in a log.
Symptom: A key ends up in a public Git repo. Happens more than anyone admits — I caught one in a teammate's dotfiles repo that had been public for three weeks.
Cause: MCP config files live in ~/.config/ or ~/. Dotfiles repos sync those directories. If a key is hardcoded in an MCP config, the next git push ships it to GitHub. From there it's a matter of time before a scraper finds it.
Fix: Store keys in environment variables sourced from a file that's gitignored. The setup prompts in the complete guide already enforce this — but if you inherited a config from a teammate, run the security audit prompt. Rotate any key that was even potentially exposed; treat exposure as compromise, not near-miss.
Symptom: Searches start failing mid-session, or the AI reports "rate limited" errors in the middle of a workflow.
Cause: Brave Search's free tier caps at 2,000 queries/month. Firecrawl's free tier is tighter than people expect. A long agent session running search in a loop can burn through a monthly quota in an afternoon. The AI doesn't know the quota is low; it just keeps calling until the API returns an error.
Fix: Monitor usage in the first week after installation. If you're hitting limits, either upgrade to a paid tier or throttle the AI's search behavior with a system prompt like "search at most three times per task; prefer cached results and reasoning over fresh searches." For Brave specifically, the Anthropic reference implementation respects rate limit headers cleanly — a well-behaved setup slows down rather than failing hard.
Symptom: A setup that works on your laptop fails on your desktop, or vice versa. The same prompt produces different behavior.
Cause: MCP servers are npm packages or binaries. They update independently on each machine. A server pinned to v2.1 on one machine and v2.4 on another can behave differently — tool signatures change, default flags change, occasionally authentication flows change. The differences are subtle until they aren't.
Fix: Pin versions in your MCP config. Treat the config like application code: version it, review changes, sync across machines. If you sync dotfiles via Git (recommended), the MCP config goes in the repo and server versions stay consistent. When a server releases a breaking-change major version, upgrade deliberately, not accidentally.
Symptom: MCP config gets overwritten when two machines sync simultaneously, or a server disappears after a sync.
Cause: Syncthing, iCloud Drive, and similar tools can race on the same config file. MCP configs are not designed for concurrent writes — they're read at startup and assumed stable. A sync race can leave the file half-written or revert a deliberate change.
Fix: Designate one machine as the source of truth for MCP config. Others pull but don't push. Or use Git with manual commits — slower, but unambiguous. Never put the MCP config in a folder that two active machines might write to at the same time.
Symptom: Playwright opens a page, but it's not logged in — the AI can't reach the data you wanted and reports "element not found" on what should be a dashboard.
Cause: Playwright launches a fresh browser context by default. It doesn't share cookies with your daily browser. Any authenticated page fails. The AI tries to interact with a login form that isn't there.
Fix: Configure Playwright to use a persistent context. For testing production flows, point it at a dedicated browser profile that's pre-authenticated. For scraping public pages, the default ephemeral context is fine. The split is: anything behind a login wall needs a persistent profile; anything public doesn't.
Symptom: Ten servers installed in the first week, half never used, context window permanently bloated, and the user can't remember what half of them do.
Cause: MCP directories like awesome-mcp-servers list 400+ servers. The temptation to install "interesting" servers upfront is real. Most of them turn out to be unused — they looked essential in the directory and became invisible once installed.
Fix: Install the three essentials (Brave, Firecrawl, GitHub). Use them for two weeks. Only add a fourth server when you hit a specific task the first three can't handle. The "install on demand" rule beats "install everything upfront" every time. Curiosity is fine; install it for a day, evaluate, remove if it doesn't earn a permanent slot.
Run these prompts on a schedule. They take two minutes each and catch problems before they compound. Treat them like git status — quick checks that prevent expensive mistakes.
Copy-paste to your AI assistant:
Review my MCP server usage for the past week. List each installed server, how many times it was called, and the most recent call. Flag any server with zero calls — I want to disable unused ones to reclaim context budget. Also tell me which server consumed the most tokens through its tool descriptions.
Copy-paste to your AI assistant:
Audit all my MCP server configurations for security. Check: (1) are any API keys hardcoded in config files instead of environment variables; (2) does the GitHub token have broader scope than the repos I actually use; (3) are any servers running versions older than six months; (4) are any filesystem MCP servers pointed at my home directory instead of specific project folders. Report findings ranked by severity and propose a fix for each.
Copy-paste to your AI assistant:
List every MCP server I have installed. For each, tell me its purpose, when I last used it, and whether it overlaps with another server's capability. Recommend which to keep, which to disable, and which to remove entirely. Also identify any gaps — common tasks I do that no installed server covers well.
These are the prompts that turn MCP from "installed" into "compounding." Each one pairs servers deliberately.
The research prompt — pairs Brave + Firecrawl:
Copy-paste to your AI assistant:
Search the web for current information about [topic], then scrape the three most authoritative sources you find. Return a summary with citations. Do not use training data — every claim must come from a fresh search or scrape. Cap total searches at 5 to stay within quota.
The library migration prompt — pairs Context7 + GitHub:
Copy-paste to your AI assistant:
I'm migrating from [old version] to [new version] of [library]. Use Context7 to pull the current migration guide and changelog. Then read my code in [repo path] and identify every file that needs changes. Output a change list grouped by file, with the specific API differences for each change.
The production debugging prompt — pairs Sentry + Vercel + GitHub:
Copy-paste to your AI assistant:
Pull the most recent Sentry error from my production environment. Pull the Vercel deployment that was live when the error first appeared. Read the relevant code from GitHub at the commit that was deployed. Correlate the error to a specific code path and propose a fix. Do not suggest fixes based on training data — anchor every claim to the actual error and deployed code.
The design-to-code QA prompt — pairs Figma + Playwright:
Copy-paste to your AI assistant:
Read the design file at [Figma URL]. Compare it against the rendered page at [localhost URL] using Playwright. Report any visual differences in spacing, typography, colors, or layout. Use the Figma tokens as the source of truth — pixel differences under 2px are acceptable, anything larger is a bug.
The audit-before-commit prompt — pairs GitHub + filesystem:
Copy-paste to your AI assistant:
Before I commit, review every file I've changed in [repo]. Check for: hardcoded secrets, debug logs left in, commented-out code, and TODOs that should become issues. For each finding, propose a fix. Block the commit if you find a hardcoded secret.
Most users never need to. The five-server setup (Brave, Firecrawl, GitHub, Context7, plus one task-specific server) covers 95% of real workflows. But there are legitimate reasons to expand, and they're worth naming so you don't second-guess a setup that actually fits your work.
The test: can you name, in one sentence, what each server is for and when you last used it? If yes, the setup is right-sized. If you hesitate on any server, disable it for two weeks. If you don't miss it, remove it. If you do miss it, you've validated its place in the stack — re-enable with confidence.
Run this checklist on any MCP setup that touches production systems. It's the same set of rules from the complete guide, reframed as a checklist you can tick through.
When something breaks mid-session, these prompts diagnose faster than guessing. They're targeted at the symptoms operators actually see.
"The AI is slow and picking weird tools"
Copy-paste to your AI assistant:
Audit my active MCP servers. Count the tool descriptions each one injects into the context window and estimate the total context overhead in tokens. If I'm over 5 active servers, recommend which to disable to get back to the sweet spot. Prioritize disabling servers with overlapping capabilities.
"A server keeps failing to connect"
Copy-paste to your AI assistant:
Diagnose the connection failure for [server name]. Check: is the binary installed at the configured path; is the API key environment variable set in the shell that launches my AI tool (not just my interactive shell); is the server's npm package on a compatible version; did the auth token expire. Propose the minimal fix — don't reinstall from scratch unless the binary is missing.
"The AI keeps calling the wrong server for web tasks"
Copy-paste to your AI assistant:
Review my installed servers that touch the web (Brave, Firecrawl, Playwright, Context7, etc.). Identify any overlap in their capabilities. Recommend a single primary for each web task type: search, scrape static, scrape dynamic, interact, read library docs. Disable the rest.
"My free tier ran out and searches fail"
Copy-paste to your AI assistant:
Check the API usage and quota for each MCP server that uses a paid or freemium API. Tell me which are close to limits and recommend: upgrade, throttle the calling behavior, or switch to a free alternative. For servers I should throttle, give me a system-prompt rule that limits call frequency.
"Sessions behave differently on my laptop vs desktop"
Copy-paste to your AI assistant:
Compare the MCP server configurations between this machine and my other machine. Identify version drift, missing servers, and any difference in API key rotation state. Produce a diff and a sync plan to bring them back in line. Flag which machine should be the source of truth.
What this does: Resolves server overlap via the decision matrix, audits the four production pitfalls (permission over-grant, context bloat, key leaks, free-tier creep), applies the security-hardening checklist, and enforces the five-server gate — keeping an MCP setup lean, secure, and fast.
Based on: MCP Best Practices: Decision Checklist, Pitfalls, and Production Rules — https://aiworkflowpro.com/mcp-best-practices/
Time to run: ~5 minutes
Copy this prompt into Claude Code, ChatGPT, or any AI assistant:
ROLE: You are an MCP Operator Auditor. Your job: keep an already-running MCP setup lean, secure, and fast — resolving overlap, catching the four production pitfalls, and hardening every server.
CONTEXT — MCP OPERATOR DISCIPLINE METHOD:
MCP is in your toolchain — the real questions come next: which server when a task fits three, why Claude Code slowed after the sixth install, why a teammate's key leaked into a public dotfiles repo, when "free tier" becomes a paid invoice. Four production pitfalls hit every growing setup: (1) permission over-grant — a server gets more scope than it needs; (2) context bloat — too many servers inject tools and slow the agent (the post-sixth-install slowdown); (3) key leaks — secrets land in public dotfiles or repos; (4) free-tier creep — usage silently crosses into paid invoices. The operator's discipline is a decision matrix (best-fit, least-permission, non-overlapping), a pitfall audit, a security-hardening checklist, and a five-server gate — beyond five, every new server must earn its spot against context bloat.
INPUTS (fill in before running):
- STACK: [The MCP servers currently installed]
- TASK: [A workflow where multiple servers could fit]
- EXPOSURE: [Do any servers touch secrets/keys or paid APIs?]
- SYMPTOMS: [Any slowdown, key-leak worry, or surprise invoice?]
METHOD — 4 STEPS:
Step 1 — Resolve Overlap With the Decision Matrix
For TASK, when multiple servers in STACK could fit, pick one on three criteria: best functional fit, least permission scope, no overlap with a server already covering it. Note any pairing that compounds. Reject running three where one suffices.
Step 2 — Run the Production-Pitfall Audit
Score STACK against the four pitfalls: permission over-grant, context bloat (past ~5 servers the agent slows), key leaks (any secret in dotfiles/repos?), free-tier creep (drifting toward paid invoices?). Flag each active pitfall and the EXPOSURE/SYMPTOMS that confirm it.
Step 3 — Apply the Security-Hardening Checklist
For every server: least-privilege scopes, secrets via a secrets manager (never dotfiles), read-before-write where possible, per-server token revocation. Cut any server holding more scope than its job needs.
Step 4 — Five-Server Gate + Audit Cadence
If STACK exceeds five servers, justify each beyond-five addition against context bloat or cut it. Set the audit routine cadence (e.g. monthly): re-run the decision matrix and pitfall audit to keep the setup lean, secure, and fast.
RULES:
- Never grant a server more permission scope than its task needs — least privilege is the default.
- Never let the stack grow past five servers without each new one earning its spot against context bloat.
- Never store server keys in dotfiles or repos — use a secrets manager, or expect a leak.
OUTPUT FORMAT:
Output a markdown report with:
1. Decision-Matrix Pick — the chosen server for TASK + why (vs the alternatives)
2. Pitfall Audit — markdown table, columns: Pitfall | Active? | Evidence
3. Security Hardening — markdown table, columns: Server | Scope Cut | Secret Handling
4. Five-Server Gate + Cadence — over-budget servers to justify/cut + the audit schedule
Save as @templates/mcp-best-practices.md and run monthly, or whenever MCP slows, leaks, or surprises you on the invoice.
The complete guide teaches MCP from zero: what it is, the USB-C analogy, the Host/Server/Connection model, and step-by-step installation prompts for eight common scenarios. This article assumes MCP is already installed and working. It covers the operator questions the installation guide doesn't: which server to reach for when multiple fit, the pitfalls that hit production setups, audit routines, and best-practice prompts for daily work. Read the complete guide first if you're new; bookmark this one once MCP is in your toolchain.
Three to five. Past seven, tool selection accuracy degrades visibly. Every server injects tool descriptions into the AI's context window — a server with 8 tools can add 2,000–4,000 tokens of overhead. Stack seven servers and you've burned 15,000+ tokens on tool descriptions before the session even starts. Start with Brave Search, Firecrawl, and GitHub. Add Context7 and one task-specific server as needed.
Yes. Overlap is worse than redundancy — it actively degrades tool selection. When two servers can both "search the web," the AI burns tokens deciding which to call and sometimes picks the wrong one. Pick one primary for each task type (search, scrape static, scrape dynamic, interact, read docs) and disable the others. The reclaimed context budget shows up as faster, more accurate responses.
Weekly for usage (which servers are getting called), monthly for security (keys, scopes, versions), quarterly for cleanup (remove what's no longer needed). The audit prompts in section six take two minutes each and catch problems before they compound. Treat them like git status — quick checks that prevent expensive mistakes.
Either upgrade to a paid tier or throttle the AI's calling behavior with a system prompt like "search at most three times per task; prefer cached results and reasoning over fresh searches." For Brave Search specifically, the Anthropic reference implementation respects rate limit headers cleanly — a well-behaved setup slows down rather than failing hard. Monitor usage in the first week after installing any freemium server so quota exhaustion never surprises you.
Be careful. MCP configs aren't designed for concurrent writes, and sync races can corrupt or overwrite the config. Designate one machine as the source of truth; others pull but don't push. Or use Git with manual commits — slower, but unambiguous. Always pin server versions; otherwise independent updates cause version drift between machines, and the same prompt will produce different behavior on each.
When you can name, in one sentence, what each server is for and when you last used it. Common legitimate cases: multi-platform automation (use Composio to consolidate 250+ platforms into one server), production observability (Vercel + Sentry + a metrics server), or design system work (Figma + tokens + component docs). If you hesitate on any server's purpose, disable it for two weeks and see if you miss it.
— Leo
Gloves on, tape measure in hand — nobody types a query. Three voice surfaces for ai automation tools (terminal, Telegram, Discord), 10 TTS and 6 STT providers compared on cost and latency, plus a setup that costs nothing.
A Skill is an operating manual, not a plugin. The five-layer architecture behind workflow automation that survives context compression, session crashes, and handoffs: SKILL.md as the single entry point, deterministic scripts, run state for crash recovery, and a resource layer.
Two of the three fixes can be undone the same afternoon. The third cannot, and it is the one people reach for first. LoRA cut costs tenfold, which made the expensive option tempting rather than correct. In business process automation, the order you try things in is the whole decision.
Fine tuning turns a generalist into a specialist - skip the baseline and you can never prove it worked. Five steps on Google Cloud: baseline, data prep, instruction design, hyperparameters, evaluation. Plus the finding that surprises business process automation buyers: 100 good samples beat 1,000.
When I rebuild one with AI agents, you get the write-up — including the parts that didn't work. No weekly roundup, no "5 tools you need."