Find MCP servers, setup guides, and configuration examples in one place

Git MCP is the version-control boundary between an agent and repository history, and its most valuable output is not the current file tree — it is causality. A working tree tells you what exists; Git tells you why it exists, which commit changed it, which branch introduced it, and whether the apparent fix is actually a regression from an earlier revert. The server exposes repository-aware operations such as log, diff, status, branch inspection, commit lookup, and content search without requiring the agent to execute arbitrary shell commands. That narrower surface matters: a coding agent can investigate a bug and construct a patch context while remaining unable to run curl, install packages, or read unrelated host files. The hidden edge case is repository state ambiguity. A detached HEAD, shallow clone, sparse checkout, submodule, or uncommitted worktree can make a perfectly valid Git response look like project truth while silently omitting the context the agent needs. Production workflows should report repository root, current ref, HEAD SHA, shallow/sparse status, and dirty files before reasoning about history. Git MCP is a history engine, not a sandbox; filesystem and write permissions still determine the blast radius.

The dirty secret of browser automation for AI agents: every screenshot-based approach is a slot machine. Vision-driven agents click pixel coordinates that shift with every viewport resize, every font load, every A/B test — and they burn thousands of tokens per action just to see the page. Playwright MCP, built by Microsoft, rejects the entire paradigm: it exposes the accessibility tree, a structured semantic snapshot of the page where every button, input, and link carries a stable reference the agent can act on deterministically. One snapshot call replaces the screenshot-and-guess loop, cutting token cost per action by an order of magnitude while making clicks reproducible instead of probabilistic. This is why Playwright MCP became the most-deployed server in the ecosystem in 2026: it is not a scraper, it is a full interaction layer — navigation, form filling, file uploads, dialog handling, tab management, and arbitrary JavaScript evaluation through browser_evaluate. The architectural trade-off nobody documents: the server is stateful by design, holding a real browser session across tool calls, which makes it uniquely powerful for authenticated multi-step workflows and uniquely dangerous if you point it at a browser profile containing your logged-in sessions.

Notion is not a wiki — it is a block graph wearing a wiki's clothes, and every integration that treats it as flat documents eventually face-plants into that distinction. The official Notion MCP server is built around the truth of the data model: pages are trees of typed blocks, databases are queryable views over page collections, and an agent that can traverse, filter, and mutate that graph gains something no export-and-summarize pipeline can touch — the ability to operate on living knowledge. Connected via the hosted OAuth endpoint (mcp.notion.com), the agent can search your workspace semantically, assemble meeting notes from scattered blocks, update database rows with proper relation and rollup semantics, and turn a brain-dump voice note into a structured project database in one session. The production reality that burns every new user: Notion's permission model is per-page explicit sharing, and the API returns empty results — never permission errors — for anything not shared. Your first deployment will look broken and it will be lying to you. Share the parent page; children inherit. That one habit separates a working integration from a week of confused debugging.

Google was built for humans who scan ten blue links; Exa was built for machines that read. That single design decision inverts everything you know about search tooling: instead of keyword matching against an ad-optimized index, Exa runs embedding-based neural retrieval over the web, returning results ranked by semantic similarity to your intent — with the actual page content (highlights and full text) delivered inline, so the agent never burns a second tool call fetching what it just found. The capability mainstream blogs skip: Exa's find_similar endpoint is a link-graph weapon — give it one high-quality URL and it returns its semantic neighborhood, which turns competitive research and literature discovery from keyword guessing into vector traversal. For agents, the economic argument is decisive: every search-and-fetch round trip through a browser server costs seconds and tokens; Exa collapses the loop into one call that returns rankable, quotable content. The trade-off to respect: neural recall surfaces conceptually-relevant results that keyword purists would call wrong — which is exactly what you want for research, and exactly what you do not want for looking up an exact error string.

Google Drive MCP is not a file browser; it is an access-controlled document graph whose usefulness depends on preserving file identity, permissions, and provenance. An agent can search Drive, read Docs, Sheets, and PDFs, assemble project context, and connect a specification to the code or ticket that implements it. The architectural trap is that Drive search is not a single operation: file discovery, shortcut resolution, shared-drive membership, export permissions, and content retrieval are separate gates. A file can appear in a search result while its body is inaccessible, a shortcut can point to a document outside the agent's corpus, and duplicate names can cause the agent to edit the wrong file while every API call remains valid. Production workflows should resolve immutable file IDs, report the drive and owner, preserve modified time and revision metadata, and use read-only OAuth scopes until a human confirms any write. Treat retrieved documents as untrusted input too — an instruction hidden inside a Drive file is data, not authority, and must not override the agent's system policy.

The average production incident burns 40+ minutes before a human even opens the correct stack trace — Sentry MCP collapses that window to seconds by inverting the debugging flow: instead of you pulling context out of the observability pipeline, the agent pulls distributed trace context, breadcrumbs, and suspect commits directly into its reasoning loop. The architectural insight most teams miss: a stack trace is a lossy projection of distributed causality, and Sentry is the only layer in the chain that reassembles it — release metadata, demangled source maps, async payload parsing across service boundaries — into something an LLM can actually reason about. Connected to Claude or Cursor, the server exposes tools like find_issues, find_events, and get_issue_details over an OAuth-secured remote transport, turning contextual AI debugging into a first-class workflow: paste an issue URL and the agent correlates the error fingerprint with the exact release and commit that introduced it. Self-hosted and EU data-residency instances are supported via host overrides, which matters far more than most setup guides admit.