The AI Agent Tools Catalog

Source: Anthropic platform tool, types web_search_20250305 (basic), web_search_20260209 (dynamic filtering) and web_search_20260318 (adds response inclusion control)

Intent

Search the live web from inside a Claude turn, returning ranked results with snippets and source attributions.

Motivating Problem

The model’s training has a cutoff; anything that happened after it, or anything that changes by the day (prices, leadership, software versions, news), can’t be answered from weights alone. web_search closes the gap by giving Claude live access to a search index from inside the tool-use loop.

How It Works

The tool is declared in the API call by type rather than by schema; Anthropic’s runtime supplies the underlying search backend. When activated, Claude can issue queries during its turn; results come back as structured snippets with URLs and titles. Citations are always enabled: text blocks in the response carry web_search_result_location citations with the URL, title and up to 150 characters of cited text. From web_search_20260209 on, Claude can also filter results with code before they enter its context (dynamic filtering).

Two design choices matter operationally. First, the tool is iterative: Claude can issue multiple queries in a single turn, refining as it reads results. Second, the runtime tracks tokens spent across queries; budget-conscious deployments can cap the number of searches per turn.

When to Use It

Any task that depends on present-day facts: who currently holds a position, what something costs now, the current version of a library, breaking news, recent regulatory changes. Pair with web_fetch when the snippet isn’t enough and you need the full page content.

Alternatives --- Tavily, Exa, Perplexity, Brave Search MCPs (Section B). Use those when the deployment is non-Anthropic, when you need a specific backend’s characteristics, or when you want explicit control over query volume and cost.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/web-search-tool

Example

Researching a competitor: the agent issues web_search queries for “competitor company funding”, “competitor product launches 2026”, and “competitor pricing tiers”, then synthesizes the results with inline citations to source URLs.

Example artifacts

Tool schema.

// Declared by type, not by JSON schema, in the messages call:

tools: [

{ "type": "web_search_20260318", "name": "web_search" }

// web_search_20250305 is the basic version, still accepted.

]

Invocation.

# Typical agent turn:

# 1. user: "Who is the current CEO of Acme Corp?"

# 2. Claude emits tool_use { name: web_search, input: { query:
"Acme Corp CEO 2026" } }

# 3. runtime returns tool_result with top results

# 4. Claude reads the top result, may issue follow-up query

# 5. Claude responds with cited answer

Source: Anthropic platform tool

Intent

Fetch the full contents of a specific URL, returning the page’s text content to the model.

Motivating Problem

web_search returns snippets, which are deliberately short. For tasks that require reading the source --- long articles, documentation, GitHub READMEs, blog posts --- snippets aren’t enough. web_fetch is the obvious follow-on: search to find the URL, fetch to read it.

How It Works

Pass a URL; receive the page’s text content. The runtime extracts the page’s text content and truncates it to max_content_tokens; other parameters are max_uses, allowed_domains, blocked_domains and citations, plus use_cache in later versions. For PDFs, web_fetch returns the document as base64 data, processed like an attached PDF. For pages that require auth, web_fetch fails predictably rather than silently --- the runtime doesn’t carry session cookies or credentials.

Operationally, the tool can only fetch URLs that the model has “seen”: URLs the user typed, URLs returned from a prior web_search, or URLs returned from another tool. The model can’t fabricate a URL and fetch it; this is a deliberate safety constraint.

When to Use It

After a web_search when snippets are insufficient. When the user provides a specific URL to read. When following links from one page to another during deep research. Skip web_fetch for sites that obviously require login --- the request will fail.

Alternatives --- Firecrawl MCP for industrial-strength scraping with markdown conversion at scale; the official Anthropic Fetch reference MCP server when running outside the Anthropic platform.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/web-fetch-tool

Example

User asks for a summary of a specific blog post. web_search isn’t needed because the URL is already provided. web_fetch returns the full post; Claude summarizes from the actual content rather than from training-time knowledge of the blog.

Example artifacts

Tool schema.

tools: [

{ "type": "web_fetch_20260318", "name": "web_fetch" }

// Versions: 20250910 (original), 20260209 (dynamic filtering),
// 20260309 (use_cache), 20260318 (current).

]

Invocation.

# Claude emits:

{

"name": "web_fetch",

"input": { "url": "https://www.anthropic.com/news/..." }

}

# Returns the page's text content.

Source: Anthropic platform tool, types code_execution_20250825, code_execution_20260120 and code_execution_20260521

Intent

Run Bash commands and Python in a sandboxed container with file operations and pre-installed libraries. The container has no internet access.

Motivating Problem

Many tasks the user asks an agent to do are computational: parse this CSV, plot this dataset, solve this equation, run this regex against this corpus. The model can write the code but can’t run it; without a runtime, the user has to copy-paste. code_execution closes the gap by giving Claude its own container to run code in.

How It Works

The runtime provides a container with Python 3 and scientific libraries (pandas, numpy, scipy, matplotlib, scikit-learn, and many others pre-installed); packages cannot be installed at runtime. Claude runs Bash commands and file operations, and Python through them; the runtime returns stdout, stderr and any files produced. Each request runs in a new container unless you reuse an earlier container ID; idle containers are checkpointed after about five minutes and expire 30 days after creation. code_execution_20260120 adds persistent REPL state and programmatic tool calling.

The code_execution tool composes with the Files API: the user uploads a file with the Files API and references it with a container_upload content block; Claude processes it in the container, and output files are downloaded through the Files API. (The /mnt/user-data paths and present_files tool seen in Claude.ai belong to the consumer app, not the API tool.)

Critically, the sandbox has no internet access and no access to the user’s real filesystem. Permission tier 2 by construction: a wrong call costs a discarded session, not user data.

When to Use It

Any computational task: data analysis, plotting, file format conversion, small ML experiments. Generating downloadable files (CSVs, images, Excel) for the user. Validating code before suggesting it to the user.

Alternatives --- E2B (Section C) for the same functionality outside the Anthropic platform, with finer-grained control over the sandbox lifecycle. Modal sandboxes for compute-heavy workloads (GPUs, large memory).

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool

Example

User uploads a CSV and asks “what’s the average revenue by region?” Claude calls code_execution with pandas to load the file, group by region, and compute the mean. The result is a small markdown table; if the user asked for a chart, matplotlib produces an inline PNG.

Example artifacts

Tool schema.

tools: [

{ "type": "code_execution_20250825", "name": "code_execution"
}

]

# No beta header needed. code_execution_20260120 adds persistent
# REPL state and programmatic tool calling.

Invocation.

# Claude emits:

{

"name": "code_execution",

"input": {

"code": "import pandas as pd\ndf =
pd.read_csv('sales.csv')
\nprint(df.groupby('region')['revenue'].mean())"

}

}

Source: Anthropic platform tool, type bash_20250124

Intent

Execute shell commands in a Linux environment. Used heavily by Claude Code and by Anthropic-hosted agent containers.

Motivating Problem

Many development tasks need the shell, not just Python: running tests, building artifacts, running CLI tools, managing packages with pip or npm. Giving an agent bash access turns it from a code-suggester into a code-runner. The classic risk is well-known --- a misfired rm -rf or a wrong git push has bigger blast radius than a Python typo.

How It Works

The bash tool is a client tool with a command parameter: Claude only requests commands. Your application keeps one bash process alive across calls (so the working directory and environment persist), runs each command Claude requests, and returns the output as a tool_result in whatever shape it chooses.

Two operational properties depend on the deployment. In Anthropic’s hosted sandboxes (Claude Code on the cloud, the code-execution containers), bash runs in an isolated environment with no access to user systems; mistakes are Tier 2. When Claude Code runs locally, bash runs against the developer’s actual filesystem; mistakes are Tier 3—4, which is why Claude Code introduces approval prompts for destructive commands and why skills like Matt Pocock’s git-guardrails-claude-code exist to add hooks.

When to Use It

Coding tasks that need the build, test, or run loop. Anywhere the natural tool is a CLI rather than a Python library. Pair with text_editor tools for an end-to-end coding agent: view the file with text_editor, modify with str_replace, run tests with bash.

Alternatives --- code_execution when the task is Python-shaped and a shell escape isn’t needed. MCP-based shell servers when running outside the Anthropic platform.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/bash-tool

Example

Running the test suite for a Python project: bash tool executes pytest, observes the failures, the agent reads the test output, modifies the failing code with str_replace, re-runs pytest, iterates until green.

Example artifacts

Tool schema.

tools: [

{ "type": "bash_20250124", "name": "bash" }

]

Invocation.

{
  "name": "bash",
  "input": {
    "command": "pytest tests/ -x"
  }
}

# Returns: { stdout, stderr, return_code, ... }

Source: Anthropic platform tools, type text_editor_20250728

Intent

Read, modify, and create files via a focused editing API that maps naturally to how the model reasons about code changes.

Motivating Problem

An agent editing files needs three primitives: see the current state, make a small change, or create a new file. A blunt write-the-whole-file API is wasteful (the model regenerates content that didn’t change) and unsafe (silently overwrites). text_editor splits the operation into view, str_replace (single string find-and-replace within a file), create (new file with content), and insert (add text after a given line number), each focused and auditable.

How It Works

The tool is a client tool: Claude requests commands and your application executes them against its files. view returns the file’s contents with line numbers prepended. The line numbers are display-only; they don’t need to be included when calling str_replace.

str_replace takes old_str and new_str. The handler locates old_str in the file (must be uniquely matching) and replaces it with new_str. Match failures (because the string isn’t present or appears multiple times) return an error rather than guessing. This is what makes the tool reliable: the model can’t accidentally do a partial overwrite.

create writes a new file with the given content; the tool is client-implemented, so whether create may overwrite an existing file is decided by your handler. insert adds text after a given line. text_editor_20250728 also accepts max_characters to truncate large views. The commands compose naturally: view, identify exact lines, str_replace; or create for new files.

When to Use It

Any coding agent. Any task that edits text files. The pattern view-then-edit is the dominant agent shape in Claude Code, Cursor (which uses similar primitives under different names), and the Anthropic-hosted document agents.

Alternatives --- a write-whole-file tool when the file is small and the model knows the full content. Filesystem MCP (Section D) when running outside the Anthropic platform.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/text-editor-tool

Example

Fixing a typo in a config file: view the file, find the line containing the typo, str_replace the old version with the corrected version. The change is precise; the rest of the file is untouched.

Example artifacts

Tool schema.

tools: [

{ "type": "text_editor_20250728",

"name": "str_replace_based_edit_tool" }

]

Invocation.

# view

{ "name": "str_replace_based_edit_tool",

"input": { "command": "view", "path": "/repo/config.yaml" }
}

# str_replace

{ "name": "str_replace_based_edit_tool",

"input": {

"command": "str_replace",

"path": "/repo/config.yaml",

"old_str": "port: 8080",

"new_str": "port: 9090"

} }

Source: Anthropic client toolset, type computer_toolset_20260801 (earlier beta versions computer_20251124 and computer_20250124 for older models)

Intent

Control a computer’s screen, keyboard, and mouse as a human would --- move the cursor, click, type, take screenshots, scroll.

Motivating Problem

Many systems an agent might need to use don’t have APIs: legacy enterprise software, web apps without exposed automation, desktop applications, browsers without a Playwright integration. Computer use is the universal fallback: give the model a screen, a mouse, and a keyboard, and let it operate the thing as a human would.

How It Works

One computer_toolset_20260801 entry in tools gives Claude 17 member tools, among them screenshot, left_click, type, key, scroll and zoom. Claude’s calls are tool_use blocks named after the member and marked with toolset_name computer, often several in one turn. The model sees the screen via screenshots (returned as image inputs in tool_result blocks); your application executes each action against the target system (typically a virtual desktop) and returns a fresh screenshot. Claude 5.5 and later models on the Claude API accept only the toolset and reject computer_20251124 and computer_20250124; those older versions apply to earlier models with a beta header.

The loop is screenshot → reason → act → screenshot. It is slow (each turn is a screenshot interpretation), expensive (image tokens add up), and fragile (small UI changes invalidate the model’s plan). But it works for any visible system. Where Playwright reads the DOM and acts on element handles, computer use reads screenshots and acts on pixel coordinates, which makes it both more general and less reliable.

Anthropic does not host the desktop: you supply a sandboxed environment (a VM or container). The computer-use-demo quickstart ships a Docker-based Ubuntu reference environment; production deployments use E2B Desktop or their own VMs, so the desktop being controlled is a sandbox rather than the user’s real machine.

When to Use It

Last-resort automation: legacy software with no API, web apps that resist scripting, desktop applications. Demo and prototype work where building a real integration is overkill. NOT for production workflows that have a real API or MCP server available --- Computer Use is the slowest and most expensive option for any task that has an alternative.

Alternatives --- Anthropic’s browser use tool (browser_toolset_20260801) for tasks that stay inside web pages, which Anthropic’s docs name as the closer fit; Playwright MCP for web automation that does have programmatic access; browser-use as a focused alternative built specifically for browser tasks; direct API calls when the target has one. Section E compares these browser and desktop options. For isolating the controlled desktop, see Volume 12, Browser automation sandboxes; for computer use as a product next to OpenAI Operator, see Volume 14, Anthropic Computer Use, OpenAI Operator, and Browserbase.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool

• github.com/anthropics/claude-quickstarts (computer-use-demo)

• platform.claude.com/docs/en/agents-and-tools/tool-use/browser-use-tool

Example

An internal sales tool that’s a 15-year-old Windows desktop app with no API. Computer use opens it in a virtual desktop, navigates to the customer record screen, reads the data on screen, and produces a structured summary for the agent’s next step.

Example artifacts

Tool schema.

tools: [

{ "type": "computer_toolset_20260801" }

]

// No beta header. The toolset rejects name, display_width_px and
// the other fields of computer_20250124.

Invocation.

# Take a screenshot:

{ "name": "screenshot", "toolset_name": "computer",

"input": {} }

# Click somewhere:

{ "name": "left_click", "toolset_name": "computer",

"input": { "coordinate": [512, 384] } }

# Type a string:

{ "name": "type", "toolset_name": "computer",

"input": { "text": "hello world" } }

Source: Anthropic platform tool, type memory_20250818

Intent

Give an agent durable cross-conversation memory --- write notes, recall them in future sessions, and apply context editing to keep long-running conversations manageable.

Motivating Problem

Each model call has a fixed context window; an agent that learns nothing across calls relearns the user’s preferences every session. Stuffing previous conversations back into context works for short histories but doesn’t scale. The memory tool gives Claude a directory of memory files it can write to and read from across sessions, plus context-editing strategies that prune long conversations.

How It Works

The memory tool is client-side: Claude issues file commands (view, create, str_replace, insert, delete, rename) against a /memories directory, and your application runs them against storage it controls (files on disk, a database, cloud storage). Anthropic keeps no memory store of its own; the SDKs ship helper classes, including a local-filesystem implementation, under their beta namespaces, though the tool itself needs no beta header. The model writes free-form notes; the descriptions in the schema train it to write durable facts (“user prefers tea over coffee”) rather than ephemeral state (“user is currently asking about coffee”).

Context editing is the partner mechanism, still in beta under the context-management-2025-06-27 header. Two strategies are configurable: clear_tool_uses_20250919 prunes old tool_use blocks when context grows large; clear_thinking_20251015 prunes extended thinking blocks similarly. Both are configurable by trigger thresholds and retention policies; both keep long conversations within the context window without the agent losing track of recent steps.

When to Use It

Long-running agents that need to learn user preferences across sessions. Customer support agents that build up product knowledge over time. Research assistants that accumulate findings across multiple sessions. Avoid for tasks that don’t cross session boundaries; the overhead isn’t justified. The design is deliberately plain: no automatic categorization, no vector search, no memory hierarchy. It trusts the model to decide what to write and recall, so it fits personal-assistant-shaped agents where that judgment is the main axis of quality.

Alternatives --- Mem0 and Letta (Volume 6, Section C) for richer memory architectures with vector retrieval, knowledge graphs, and explicit memory categories; reach for them when retrieval must span thousands of memories or the memory must be portable across LLM providers. Anthropic’s memory tool is simpler but tightly integrated with the model.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool

• Anthropic cookbook: tool_use/memory_cookbook.ipynb

Example

Session 1: user mentions they’re vegan and a tire-fitter by trade. Claude writes both facts to memory. Session 2 (weeks later, new conversation): user asks for restaurant recommendations near their work. Claude reads memory, sees “vegan,” filters recommendations accordingly without asking again.

Example artifacts

Tool schema.

tools: [

{ "type": "memory_20250818", "name": "memory" }

]

# The memory tool needs no beta header. Context editing
# (clear_tool_uses_20250919, clear_thinking_20251015) still needs:
# anthropic-beta: context-management-2025-06-27

Invocation.

# Write to memory:

{ "name": "memory", "input": {

"command": "create",

"path": "/memories/preferences/diet.md",

"file_text": "vegan since 2018"

} }

# Read from memory:

{ "name": "memory", "input": {

"command": "view",

"path": "/memories/preferences/diet.md"

} }

Source: Anthropic platform tool, types tool_search_tool_regex_20251119 and tool_search_tool_bm25_20251119

Intent

Let Claude work with hundreds or thousands of tools by dynamically discovering and loading them on demand, instead of loading every tool definition into context upfront.

Motivating Problem

Two scaling problems compound quickly as tool libraries grow. First, context bloat: a typical multi-server stack (GitHub, Slack, Sentry, Grafana, Splunk) can consume around 55,000 tokens in tool definitions before the model does any actual work --- burning budget on tools that 19 turns out of 20 are never called. Second, selection accuracy: Claude’s ability to correctly pick the right tool degrades meaningfully once you exceed 30—50 available tools, and falls off sharply past 100.

Tool search addresses both: definitions stay in a catalog and the model searches for them when it needs them. Anthropic reports the mechanism typically reduces tool-definition context usage by over 85% while keeping selection accuracy high across catalogs of thousands of tools.

How It Works

Two variants are available: the regex variant (tool_search_tool_regex_20251119) where Claude constructs Python re.search() patterns to search tool names, descriptions, argument names, and argument descriptions; and the BM25 variant (tool_search_tool_bm25_20251119) where Claude uses natural-language queries against a BM25 index over the same fields. Regex patterns may be up to 200 characters and BM25 queries up to 500. Each search returns up to 5 tool references by default; an optional limit parameter changes that.

Tool definitions are marked deferred via the defer_loading: true flag on the tool definition. Tools without that flag stay loaded into context immediately; deferred tools live in the catalog and load only when the model discovers them through search. The tool search tool itself must never be deferred.

Operationally: Claude searches; the runtime returns tool_reference blocks pointing at matching tool names; the runtime then expands each reference into the full tool definition before passing it back to the model. References persist across conversation turns, so discovered tools can be reused without re-searching. Prompt caching is preserved because deferred tools are not part of the system-prompt prefix.

Limits: up to 10,000 tools in a catalog; model support on Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 and later models (Opus 4.1 and earlier are not supported). ZDR-eligible.

When to Use It

Any agent with more than ~10 tools, especially when tool definitions consume more than 10K tokens. MCP-powered systems with multiple servers (200+ tools). Tool libraries expected to grow over time. Tool sets where selection accuracy issues have been observed.

Operational tips: keep the 3—5 most-frequently-used tools as non-deferred for low-latency baseline operation. Use consistent namespacing (e.g. github_, slack_) so that search queries naturally surface the right group. Add a system-prompt section describing available tool categories so the model knows when to search.

When traditional tool calling is fine: fewer than 10 tools total; every tool used in nearly every request; very small definitions.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

• anthropic.com/engineering/advanced-tool-use

• anthropic.com/engineering/effective-context-engineering-for-ai-agents

Example

An ops agent connected to GitHub, Slack, Sentry, Grafana, Splunk, Linear, and PagerDuty MCP servers --- around 250 tools total. The full definitions would consume 60K+ tokens. Tool search loads only the search tool and a small starter set up front; when the user asks “which incidents were paged last night?”, Claude searches for “incident”, gets up to five relevant references from the PagerDuty MCP, and proceeds. The other 240+ tool definitions never enter context.

Example artifacts

Tool schema.

tools = [

{ "type": "tool_search_tool_regex_20251119",

"name": "tool_search_tool_regex" },

{ "name": "get_weather",

"description": "Get the weather at a specific location",

"input_schema": { ... },

"defer_loading": True },

{ "name": "search_files",

"description": "Search through files in the workspace",

"input_schema": { ... },

"defer_loading": True },

// ... up to 10,000 deferred tools

]

Invocation.

# Claude internally:

# 1. user asks about weather

# 2. emits server_tool_use { name: tool_search_tool_regex, input: {
pattern: "weather" } }

# 3. runtime returns tool_references: [ { tool_name:
"get_weather" } ]

# 4. runtime expands the reference into the full get_weather
definition

# 5. Claude calls get_weather normally

Source: Anthropic platform tool, type advisor_20260301 (beta header advisor-tool-2026-03-01)

Intent

Let a faster, lower-cost executor model consult a higher-intelligence advisor model mid-generation for strategic guidance, without breaking out of the single request boundary.

Motivating Problem

Long-horizon agentic workloads --- coding agents, computer-use agents, multi-step research pipelines --- have a recurring shape: most turns are mechanical (running a command, reading a result, applying a small edit), but a few moments require the kind of high-quality planning that only a top-tier model produces. Running the entire task on the top-tier model wastes money on the mechanical turns; running it all on a smaller model produces brittle plans. The advisor pattern --- a strong reviewer that the smaller executor consults at critical junctures --- captures most of the strong-model quality at most of the small-model cost.

How It Works

The advisor tool runs inside a single /v1/messages request. The executor model (the top-level model field) decides when to call the advisor; the advisor model (the model field inside the tool definition) is a separate sub-inference that runs server-side with the full transcript. The advisor sees system prompt, all prior turns, all tool results, all prior advice. It produces a 400—700-token plan or course-correction (1,400—1,800 tokens including its thinking) and returns it to the executor as an advisor_tool_result block. With an Opus 4.x advisor the content is a plaintext advisor_result; with a 5.x-family advisor it is an advisor_redacted_result carrying encrypted_content, which the caller cannot read and the server decrypts on the next turn.

Model pairing must be compatible: the advisor must be Claude Sonnet 4.6 or more capable, and at least as capable as the executor. Executors range from Haiku 4.5 up through the 5.x family; the docs’ model compatibility table lists the valid pairs.

The executor decides timing; the server supplies the context. The server_tool_use block the executor emits has an empty input --- nothing the executor writes is forwarded; the server reconstructs the advisor’s view from the transcript automatically.

Two independent caching layers: executor-side caching of the advisor_tool_result like any other content block; and advisor-side caching of the advisor’s own transcript across calls within the same conversation (enabled via caching: { type: “ephemeral”, ttl: “5m” }, or ttl “1h”). Advisor-side caching breaks even at roughly three advisor calls per conversation and improves from there.

When to Use It

Coding agents and computer-use agents where the executor model is Sonnet or Haiku and you want occasional access to Opus-level planning. Multi-step research and analysis pipelines with both mechanical and strategic phases. Anywhere the bulk of tokens are generated by the executor doing routine work and a few critical decisions justify the stronger model.

Best-practice timing for coding tasks: call the advisor early (after orientation reads but before substantive writing) and at the end (after file writes and test outputs are in the transcript). Two to three calls per task tends to produce the best quality-cost trade-off; aggressive limiting via max_uses caps cost.

Weaker fit: single-turn Q&A, pass-through model pickers where the user already chose model and cost trade-off explicitly, workloads where every turn genuinely needs the advisor model’s full capability.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool

Example

A coding agent running on Sonnet 4.6 building a concurrent worker pool in Go. Early in the task, after a few exploratory reads, the executor calls the advisor. Opus 4.7 produces a concise plan: channel-based coordination, close the input channel first then wait on a WaitGroup, watch for writer starvation. The executor writes code following the plan, runs tests, and calls the advisor a second time after a failure. Total cost: roughly Sonnet-class with one or two Opus sub-inferences; quality: closer to Opus-solo than to Sonnet-solo.

Example artifacts

Tool schema.

tools: [

{

"type": "advisor_20260301",

"name": "advisor",

"model": "claude-opus-4-7",

"max_uses": 5,

"caching": { "type": "ephemeral", "ttl": "5m" }

}

]

# Beta header:

# anthropic-beta: advisor-tool-2026-03-01

Invocation.

# Executor emits with empty input:

{ "type": "server_tool_use",

"id": "srvtoolu_abc123",

"name": "advisor",

"input": {} }

# Server runs advisor sub-inference, then returns:

{ "type": "advisor_tool_result",

"tool_use_id": "srvtoolu_abc123",

"content": {

"type": "advisor_result",

"text": "Use a channel-based coordination pattern. The tricky part
is draining in-flight work during shutdown: close the input channel
first, then wait on a WaitGroup..."

}

}

Source: MCP servers: tavily-mcp, exa-mcp-server, @perplexity-ai/mcp-server, @brave/brave-search-mcp-server

Intent

Live web search via four distinctively different backends, each surfacing different parts of the web with different trade-offs.

Motivating Problem

Different agent workloads need different search behavior. Tavily (now part of Nebius) is built for AI agents and returns clean, ranked, deduped results suitable for direct ingestion. Exa indexes by embedding similarity rather than keyword, so it surfaces semantically-related pages that a keyword index misses. Perplexity returns AI-summarized answers with citations rather than raw search results. Brave maintains an independent index that doesn’t share Google’s biases; its API ended the free plan for new users in February 2026 and gives each account a small monthly credit (about $5) on pay-as-you-go pricing instead.

How It Works

All four have official MCP servers, and Tavily (mcp.tavily.com/mcp) and Exa (mcp.exa.ai/mcp) also host remote ones. Setup is similar: install the package, set the API key as an environment variable, register the server with the agent. The tools they expose vary: search is universal; Tavily adds tavily-extract, tavily-map and tavily-crawl next to tavily-search; Exa adds web_fetch_exa and web_search_advanced_exa to web_search_exa (for find-similar, call the Exa API directly); Perplexity exposes perplexity_search, perplexity_ask, perplexity_research and perplexity_reason; Brave’s own server (brave/brave-search-mcp-server, which replaced the archived Anthropic reference server) adds news, image, video, local-place and summarizer tools on top of brave_web_search.

A useful pattern is to expose more than one of these and let the model select. Perplexity for “summarize the recent literature on X”, Exa for semantic matches that keyword search misses, Tavily for “give me the top sources on Y for direct reading”. The model picks based on its description-level understanding of each tool.

When to Use It

Agents running outside the Anthropic platform that need a search tool. Agents inside the Anthropic platform that need a specific backend’s characteristics (embedding-based search from Exa; AI-summarized answers from Perplexity). Cost-sensitive deployments that want fine-grained control over query volume.

Pitfall: don’t install three search MCPs simultaneously “just in case.” The model is more likely to be confused by overlapping descriptions than to pick the best one. Install one, with documented justification.

Sources

• tavily.com, exa.ai, perplexity.ai, brave.com/search/api

• github.com/tavily-ai/tavily-mcp, github.com/exa-labs/exa-mcp-server, github.com/perplexityai/modelcontextprotocol, github.com/brave/brave-search-mcp-server

• registry.modelcontextprotocol.io

Example

Building a research assistant for academic literature. Perplexity-reason as the primary tool (returns synthesized answers with citations); Exa as the secondary for finding related papers; web_fetch to read the actual papers once URLs are known.

Example artifacts

Invocation.

// Tavily search call:

{ "name": "tavily-search",

"input": { "query": "GraphQL vs REST 2026", "max_results": 5
} }

// Exa semantic search:

{ "name": "web_search_exa",

"input": { "query": "essays on evolutionary architecture" } }

// Perplexity reasoning:

{ "name": "perplexity_reason",

"input": { "messages": [{ "role": "user",

"content": "What changed in EU AI Act compliance between 2024 and
2026?" }] } }

Setup.

// Example Claude Desktop / Cursor config for Tavily:

{

"mcpServers": {

"tavily": {

"command": "npx",

"args": ["-y", "tavily-mcp@latest"],

"env": { "TAVILY_API_KEY": "tvly-..." }

}

}

}

Source: MCP server: firecrawl-mcp (Firecrawl)

Intent

Industrial-strength web scraping --- search, scrape, crawl, and extract structured data from JavaScript-heavy sites, returning clean markdown.

Motivating Problem

web_fetch handles simple page fetches. It does not handle JavaScript-rendered single-page apps, sites with anti-bot defenses, multi-page crawls, or structured-data extraction across a site. Firecrawl exists for those cases: a headless-browser-backed scraping engine with markdown conversion baked in.

How It Works

Firecrawl runs a headless Chromium pool with anti-bot evasion, JavaScript rendering, and proxy rotation. The MCP server’s core tools are firecrawl_search (search, optionally fetching result pages in the same call), firecrawl_scrape (single URL, as markdown or as JSON matching a schema), firecrawl_map (list a site’s URLs), firecrawl_crawl (multi-page following links with configurable depth), and firecrawl_agent (multi-page research when the URLs are not known); newer tools cover parsing, interactive sessions and page monitoring.

Structured extraction is particularly useful: with firecrawl_scrape in the json format, rather than the agent reading raw markdown and parsing fields, Firecrawl applies its own LLM pass with a user-supplied schema and returns typed JSON. For product-catalog scraping or contact-info extraction across many pages, this dramatically reduces the agent’s token usage.

When to Use It

Scraping at scale, especially with JavaScript-rendered content. Extracting structured data from many similar pages. When web_fetch fails because the site blocks simple HTTP requests.

Alternatives --- ScrapingBee MCP, Apify MCP for similar capabilities with different pricing models. Direct Playwright MCP control (Section E) when you need fine-grained interaction with the page beyond “fetch the rendered HTML”.

Sources

• firecrawl.dev

• github.com/firecrawl/firecrawl-mcp-server

Example

An agent tasked with monitoring competitors’ pricing pages. firecrawl_map lists each competitor’s pricing pages; firecrawl_scrape with a JSON schema pulls tier names, prices, and feature lists from each one. Output ready for direct comparison without parsing.

Example artifacts

Invocation.

// Structured extraction:

{ "name": "firecrawl_scrape",

"input": {

"url": "https://competitor.com/pricing",

"formats": ["json"],

"jsonOptions": {

"prompt": "Extract each pricing tier.",

"schema": {

"type": "object",

"properties": {

"tiers": { "type": "array", "items": {

"type": "object",

"properties": {

"name": { "type": "string" },

"price": { "type": "number" },

"features": { "type": "array", "items": { "type":
"string" } }

}

}}

}

}

}

}

}

Setup.

{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": [
        "-y",
        "firecrawl-mcp"
      ],
      "env": {
        "FIRECRAWL_API_KEY": "fc-..."
      }
    }
  }
}

Source: MCP server: @upstash/context7-mcp

Intent

Pull current, version-pinned documentation for 9,000+ libraries directly into the agent’s context, so the model writes code against real APIs rather than from training-cutoff memory.

Motivating Problem

An agent writing code against a library it learned about during training is one of the most common hallucination paths: the API has changed; the method name is wrong; the imports are stale. Context7 fixes this by maintaining a daily-refreshed documentation index across thousands of popular libraries and exposing it through MCP, so the model can fetch the current docs for whichever library it’s about to write code against.

How It Works

Two tools: resolve-library-id (takes a libraryName such as “docx” plus the query, and returns a Context7 ID), and query-docs (takes that libraryId and a query, plus an optional language, and returns the matching doc sections). The agent typically pairs them: resolve first, then ask for the specific topics it needs rather than the full docs. Context7 also runs a hosted server at mcp.context7.com/mcp.

The model is trained (or prompted via skill) to call Context7 before writing code that imports a library. The token cost per call is small; the savings from avoiding hallucinated APIs are large. Context7 is one of the three tools in the widely-cited “starter pack” recommendation (GitHub MCP + Context7 + Playwright MCP).

When to Use It

Any coding agent that produces code against external libraries. Particularly valuable for libraries that have evolved since the model’s training cutoff. Skip for standard-library code in mainstream languages.

Alternatives --- web_search + web_fetch to read docs ad-hoc, but Context7 is faster and more structured. Docfork is a competing service with similar positioning.

Sources

• context7.com

• github.com/upstash/context7

Example

Agent asked to generate a Word document with the docx library. Before writing code, agent calls Context7 for “docx”, then specifically for the numbering and table sections. Code that follows uses the actual current API rather than what the model remembers from training data.

Example artifacts

Invocation.

// 1. Resolve

{ "name": "resolve-library-id",

"input": { "libraryName": "docx", "query": "tables" } }

// Returns: { libraryId: "/dolanmiu/docx" }

// 2. Query docs for a specific topic

{ "name": "query-docs",

"input": {

"libraryId": "/dolanmiu/docx",

"query": "tables"

}

}

Setup.

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": [
        "-y",
        "@upstash/context7-mcp"
      ]
    }
  }
}

Source: PyPI: e2b, e2b-code-interpreter. npm: e2b, @e2b/code-interpreter

Intent

Open-source secure sandboxes for AI-generated code, running on Firecracker microVMs with sub-second boot times.

Motivating Problem

An agent that writes code needs a place to run it. Running it on the host system is dangerous; running it in a generic Docker container is slower than the agent’s decision-making and lacks the file-system + network primitives that make a sandbox useful for real work. E2B builds a sandbox layer specifically for AI agents: microVM-isolated, fast-booting, with Python and JavaScript SDKs that expose the loop the agent naturally needs.

How It Works

The core abstraction is a Sandbox object created via Sandbox.create(). Once created, the sandbox supports two main operations: commands.run for shell commands and (with the code-interpreter SDK) run_code for stateful Python or JavaScript execution. State persists across calls within a sandbox; sandboxes are reused as long as they’re kept alive. Boot is around 200 milliseconds when sandbox and client are co-located.

The code-interpreter SDK adds a Jupyter-kernel layer: variables persist between run_code calls so the model can build up state across multiple steps. Standard libraries (pandas, numpy, matplotlib) are pre-installed; pip install works inside the sandbox.

Two flavors run alongside the core: E2B Desktop provides a graphical Linux desktop reachable from Anthropic’s computer-use tool or OpenAI’s computer-use agent (Surf); Fragments is the open-source template for building Claude-Artifacts-style or v0-style code-generation apps. Open-source core (Apache 2.0); BYOC deployments on AWS and GCP for enterprise.

When to Use It

Any non-Anthropic agent stack that needs a code sandbox. Anthropic-stack agents that need control over the sandbox lifecycle, network access, or packages installed at runtime, none of which Anthropic’s code_execution container allows. Building a computer-use agent on a virtual desktop (E2B Desktop).

Alternatives --- Modal for compute-heavy workloads with GPU access; Blaxel for sub-25ms resume on a perpetually-warm sandbox; Daytona for long-lived workspaces that survive across sessions.

Sources

• e2b.dev

• github.com/e2b-dev/E2B

• github.com/e2b-dev/code-interpreter

Example

Data-analysis agent: user uploads a CSV; agent creates an E2B sandbox; loads the CSV with pandas; runs several exploratory queries, each in a new run_code call (with state preserved); generates a matplotlib chart; downloads the chart as a PNG and shows the user.

Example artifacts

Setup.

pip install e2b-code-interpreter

# or

npm install \@e2b/code-interpreter

export E2B_API_KEY=e2b_...

Code.

# Python

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:

sandbox.run_code("import pandas as pd; df =
pd.read_csv('/tmp/data.csv')")

result =
sandbox.run_code("df.groupby('region')['revenue'].sum()")

print(result.text)

# TypeScript / JavaScript

import { Sandbox } from '@e2b/code-interpreter'

const sandbox = await Sandbox.create()

await sandbox.runCode("x = 1")

const execution = await sandbox.runCode("x += 1; x")

console.log(execution.text) // outputs 2

Source: modal.com (Python SDK: modal)

Intent

General-purpose serverless compute that scales to AI sandbox workloads: GPUs, large memory, custom Docker images.

Motivating Problem

Some AI sandbox workloads outgrow lightweight microVMs: training a small model, running a CUDA kernel, processing a multi-GB dataset, deploying a fine-tuned model. Modal’s value proposition for AI agents is its full serverless surface --- GPUs, custom images, scheduled functions, persistent volumes --- with a Python-first SDK that makes it usable from inside an agent loop.

How It Works

The Modal SDK lets the agent define functions that run in cloud sandboxes with configurable resources: CPU, memory, GPU class (T4 through H100), Python version, custom Docker image, persistent volumes. The agent calls these functions like local Python functions; Modal handles the container lifecycle.

For AI-agent use, Modal added explicit sandbox primitives in late 2025: ephemeral sandboxes with file-system snapshots, configurable network policies, and the same sub-second boot times as E2B (for cold starts on the smallest tier). A sandbox runs for up to 24 hours (5 minutes by default); state that must outlive it goes to filesystem snapshots or Volumes. Sandboxes run on one of two runtimes: gVisor, or a virtual machine with its own Linux kernel.

When to Use It

Compute-heavy workloads that need GPUs or large memory. Agents running pipelines that mix scratch computation with production deployment. Teams already using Modal for non-AI workloads who want to share infrastructure. Volume 5 points here for Modal; Volume 12 covers its isolation model.

Alternatives --- E2B for lighter-weight stateful sandboxes without GPU need. Direct cloud-provider sandboxes (AWS Lambda, GCP Cloud Run) when the workload is more script-like than agent-like.

Sources

• modal.com

• modal.com/docs/guide/sandboxes

Example

An agent fine-tuning a small classifier on user-provided data. Modal sandbox with a single A10G GPU, mount the dataset, run the training loop, save the model to a Modal Volume, return the inference endpoint URL to the user.

Example artifacts

Setup.

pip install modal

modal token new

Code.

import modal

app = modal.App("agent-sandbox")

image = modal.Image.debian_slim().pip_install("pandas",
"scikit-learn")

with app.run():

sb = modal.Sandbox.create(image=image, gpu="T4")

p = sb.exec("python", "-c", "import sklearn;
print(sklearn.__version__)")

print(p.stdout.read())

sb.terminate()

Source: daytona.io, blaxel.ai

Intent

Sandbox products built for long-lived state and fast resume rather than for ephemeral microVMs.

Motivating Problem

Some agent workloads aren’t ephemeral: an agent reviewing a PR needs the full repo cloned and dependencies installed; an agent migrating a codebase needs a long-running workspace where build state survives across many tool calls; an agent doing iterative dev needs to re-enter the same workspace tomorrow without re-bootstrapping. Daytona and Blaxel optimize for these long-lived shapes rather than for the fire-and-forget microVM.

How It Works

Daytona started as a dev-environment manager and now sells sandboxes for AI agents: Linux container and VM sandboxes with filesystem, network, ports and persistent storage, driven through SDKs and a CLI. Its open-source repo was archived in June 2026 and core development moved to a private codebase. By default a sandbox auto-stops after 15 idle minutes, and a stopped sandbox archives after 7 days (configurable up to 30). Daytona’s MCP server exposes tools for creating sandboxes, attaching to existing ones, running commands, and reading files.

Blaxel takes the opposite extreme on lifecycle: sandboxes can stay in standby indefinitely at zero compute cost, with resume times under 25ms (filesystem and memory state intact). It pairs sandboxes with co-located agent hosting so the agent’s tool calls don’t cross network boundaries.

Both compete with E2B and Modal at the edges of the sandbox-for-AI category. Choose Daytona when the workload needs a full repo and build state that survive across sessions (PR reviews, multi-day refactors); choose Blaxel when fast resume matters (perpetually-warm agents, latency-sensitive workflows).

When to Use It

Long-running agent workloads where state persistence is the bottleneck, not boot speed. Production agents with strict resume-latency requirements (Blaxel).

Alternatives --- E2B for shorter-lived stateful sandboxes; Modal for compute-heavy work; GitHub Codespaces for the human-in-the-loop case. Volume 12, Code execution sandboxes, covers the isolation and threat model for these products.

Sources

• daytona.io/docs/en/sandboxes

• blaxel.ai

Example

A code-review agent that runs across hundreds of PRs per week. Daytona provisions a sandbox per PR, clones the repo at the PR’s commit, installs dependencies, runs tests, generates a review comment, and archives the sandbox.

Example artifacts

Setup.

# Daytona
daytona create my-sandbox
daytona exec my-sandbox -- pytest

# Blaxel
blaxel sandbox create --image python:3.11
blaxel sandbox exec sandbox-id -- python script.py

Source: modelcontextprotocol/servers (filesystem)

Intent

Secure file operations --- read, write, list, search --- against a configurable directory tree, with access controls.

Motivating Problem

Agents that don’t have native filesystem access (most non-Claude-Code agents) still need to operate on files: read a CSV, write a generated report, search across a directory tree for relevant content. The filesystem MCP server exposes the standard file operations with configurable access controls so the agent can’t escape outside the allowed root.

How It Works

The server takes a list of allowed directories as a startup argument; all operations are confined to those directories. Tools include read_text_file, read_media_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, directory_tree, move_file, search_files (recursive glob), get_file_info and list_allowed_directories. Each has minimal input schemas --- a path and the operation-specific arguments.

Access controls are deliberately simple: the agent can read or write anything within the allowed directories; it cannot read outside them. There’s no per-file ACL; the model is trusted to operate on the right files.

One of the seven still-active Anthropic reference servers, retained because it remains useful in non-Claude-Code stacks (Cursor, Codex, Claude Desktop).

When to Use It

Non-Claude-Code agents that need file access. Sandbox-style deployments where the allowed directory is the only legitimate scope. Skip in Claude Code, which already exposes equivalent native tools.

Alternatives --- Anthropic native text_editor (within Claude Code or the Claude API). Bash MCP tools that wrap shell commands; less safe but more flexible.

Sources

• github.com/modelcontextprotocol/servers/tree/main/src/filesystem

Example

A research assistant agent given a directory of research notes. filesystem MCP exposes the notes directory; the agent uses search_files to find notes containing a topic, read_text_file to load matching ones, and writes a synthesis as a new file in the same directory.

Example artifacts

Invocation.

{
  "name": "read_text_file",
  "input": {
    "path": "/Users/me/Projects/notes.md"
  }
}

{
  "name": "search_files",
  "input": {
    "path": "/Users/me/Documents",
    "pattern": "*.pdf"
  }
}

Setup.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/Documents",
        "/Users/me/Projects"
      ]
    }
  }
}

Source: modelcontextprotocol/servers (git)

Intent

Read, search, and manipulate local Git repositories: status, diff, log, branch, commit.

Motivating Problem

Coding agents need to understand and manipulate Git state: what changed since main, what does this commit do, which files have I touched in this session, when should I commit. Calling git via bash works but leaves the agent composing command lines; the Git MCP server exposes the same operations as typed tools.

How It Works

Tools cover the standard Git operations: git_status, git_diff_unstaged, git_diff_staged, git_diff, git_log, git_show, git_branch, git_create_branch, git_checkout, git_add, git_reset, git_commit. Every tool takes a repo_path; each returns the command’s output as text, with typed inputs. The server is one of the seven still-active Anthropic reference servers.

Notably, the Git MCP server has no push tool at all: push is a Tier 4 operation, so it stays with the human (who pushes after reviewing the agent’s commits) or with another tool behind explicit approval.

When to Use It

Any coding agent that operates on Git repositories. Pair with the filesystem MCP and a GitHub MCP for a full Git workflow. Skip if Claude Code’s native bash tool is already in use and typed inputs aren’t needed.

Alternatives --- bash MCP wrapping the git CLI directly. The mattpocock git-guardrails-claude-code skill (from the Skills Catalog) for layering safety hooks on top of bash-based Git operations.

Sources

• github.com/modelcontextprotocol/servers/tree/main/src/git

Example

An agent finishing a feature branch: git_status to confirm the changes, git_diff to review them, git_add for selected files, git_commit with a generated message. push is left to the human.

Example artifacts

Invocation.

{
  "name": "git_status",
  "input": {
    "repo_path": "/path/to/repo"
  }
}

{
  "name": "git_diff",
  "input": {
    "repo_path": "/path/to/repo",
    "target": "HEAD~1"
  }
}

{
  "name": "git_commit",
  "input": {
    "repo_path": "/path/to/repo",
    "message": "Add user-profile endpoint\n\nAdds GET /api/users/:id returning profile fields."
  }
}

Setup.

{
  "mcpServers": {
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/path/to/repo"
      ]
    }
  }
}

Source: github/github-mcp-server

Intent

Access the GitHub API as tools --- search repos and code, read PRs and issues, create issues and PRs, comment on threads, get commit info.

Motivating Problem

Many agent workflows aren’t local-Git: triage open issues on a repo, summarize a PR, search across an org’s code for a pattern, file a bug report. These need the GitHub API. The vendor-maintained GitHub MCP server (one of the canonical “starter pack” recommendations) wraps the API surface as tools.

How It Works

The server exposes dozens of tools across read and write operations: search_repositories, search_code, search_issues, pull_request_read (with a method such as get or get_diff), issue_read, issue_write (create or update an issue, including its labels), create_pull_request, add_issue_comment, get_file_contents (read a file at a ref without cloning). GitHub hosts a remote server at api.githubcopilot.com/mcp/ with OAuth; the local Docker image authenticates with a Personal Access Token or GitHub App credentials.

Mixed permission tiers: search and read operations are Tier 1; commenting and creating issues are Tier 4 (real-world side-effects, observable to other humans). Production deployments typically scope the token to read-only or require explicit approval for write operations.

Operationally, the GitHub MCP is one of the three tools in the widely-recommended “starter pack” (GitHub + Context7 + Playwright). Across the agent ecosystem, it’s the single most-installed MCP server outside the Anthropic reference set.

When to Use It

Any agent that does work on GitHub-hosted code at the platform level (not just locally): triage, PR review, code search across an organization, repository-management automation, issue summarization and routing. Pair with Git MCP for the local Git half.

Alternatives --- GitLab’s official MCP server, or the community zereight/gitlab-mcp, for GitLab-hosted code. Direct REST API calls via a generic HTTP MCP when only one or two operations are needed.

Sources

• github.com/github/github-mcp-server

• docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/

Example

An open-source-maintenance agent run weekly: search_issues for issues opened in the last 7 days; for each, fetch the linked PR if any; classify into bug/feature/question with the model; set the label via issue_write; post a triage comment via add_issue_comment. Runs end-to-end in a few minutes against repositories where this used to take a human a half-day.

Example artifacts

Invocation.

{
  "name": "search_issues",
  "input": {
    "query": "repo:my-org/my-repo is:open is:issue created:>=2026-05-01"
  }
}

{
  "name": "pull_request_read",
  "input": {
    "method": "get",
    "owner": "my-org",
    "repo": "my-repo",
    "pullNumber": 1234
  }
}

{
  "name": "add_issue_comment",
  "input": {
    "owner": "my-org",
    "repo": "my-repo",
    "issueNumber": 1234,
    "body": "Triaged as a duplicate of #1199."
  }
}

Setup.

// Remote server hosted by GitHub (OAuth):
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/"
}
}
}

// Local Docker image:
{
"mcpServers": {
"github": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
}
}
}

Source: microsoft/playwright-mcp

Intent

Drive a browser through structured DOM operations --- navigate, click elements, fill forms, take accessibility snapshots --- rather than via screen coordinates.

Motivating Problem

Computer Use’s screenshot-and-click loop is slow and fragile for web pages because the web already has a structured DOM that’s machine-readable. Playwright MCP exposes the structured-DOM interface to the agent: accessibility snapshots (semantic tree of the page) and element operations (click an element by its reference from the snapshot, not by coordinates).

How It Works

The server runs a Playwright-managed browser (Chromium by default; Firefox and WebKit available). Tools include browser_navigate, browser_snapshot (accessibility tree), browser_click (by element ref from the snapshot, or a selector), browser_type (fill an input), browser_wait_for (waits for text to appear or disappear, or a fixed time), and browser_take_screenshot (visual debugging). Interaction tools take a target (the snapshot ref, such as e12) plus an optional human-readable element description.

The accessibility snapshot is the key innovation. Instead of the model reading a screenshot and computing coordinates, it reads a structured tree in which each element (a button named “Sign in”, say) carries a ref, and acts on elements by ref. Faster, cheaper (no image tokens), and more robust to visual changes that don’t affect the DOM.

Like the other tools in this section, the security model depends on the deployment: against a real production site with real credentials, every browser_click is Tier 4. Against a sandboxed test environment, it’s Tier 2.

When to Use It

Any browser automation: web scraping with login, end-to-end testing, QA verification of agent-built UI changes. Pair with the webapp-testing skill (Skills Catalog Section A) for AI-driven test runs. For coding agents, Microsoft’s README recommends Playwright CLI with skills (github.com/microsoft/playwright-cli) as more token-efficient; the MCP server suits general MCP clients and exploratory automation (see CLI + skills instead of an MCP server, Section J).

Alternatives --- Computer Use when the target isn’t a browser. Chrome DevTools MCP when the job is debugging a live Chrome (performance, network, console) rather than scripting it. browser-use when you want a more agent-loop-shaped API. Firecrawl when the task is content extraction rather than interactive automation.

Sources

• github.com/microsoft/playwright-mcp

• playwright.dev

Example

An end-to-end test for a new sign-up flow. Playwright MCP navigates to the sign-up page, fills the form (browser_type), submits (browser_click), waits for the post-signup landing (browser_wait_for), and asserts the expected text via the accessibility snapshot. The same agent loop replicates across browsers (Chromium, Firefox, WebKit) by changing one parameter.

Example artifacts

Invocation.

{
  "name": "browser_navigate",
  "input": {
    "url": "https://example.com/signup"
  }
}

{
  "name": "browser_snapshot",
  "input": {}
}

// returns an accessibility tree in which each element has a ref:
// textbox "Email" [ref=e12]
// button "Sign up" [ref=e14] ...

{
  "name": "browser_type",
  "input": {
    "element": "Email textbox",
    "target": "e12",
    "text": "test@example.com"
  }
}

{
  "name": "browser_click",
  "input": {
    "element": "Sign up button",
    "target": "e14"
  }
}

Setup.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@latest"
      ]
    }
  }
}

Source: ChromeDevTools/chrome-devtools-mcp (npm: chrome-devtools-mcp)

Intent

Let a coding agent control and inspect a live Chrome browser through Chrome DevTools: record performance traces, read network requests and console messages, and automate the page.

Motivating Problem

Playwright MCP answers “make the browser do this”. A coding agent fixing a slow page or a broken request needs a different question answered: what did the browser actually do? That means a performance trace, the network log, console errors with stack traces, and the computed CSS. Those live in Chrome DevTools, which a scripting tool does not expose. Google’s Chrome DevTools team ships an MCP server that gives the agent that view.

How It Works

The server starts (or connects to) a Chrome instance and drives it with Puppeteer, waiting for action results automatically. Tools are grouped by job: input automation (click, fill, fill_form, type_text, press_key, upload_file), navigation (new_page, navigate_page, list_pages, wait_for), emulation, performance (performance_start_trace, performance_stop_trace, performance_analyze_insight), network (list_network_requests, get_network_request), debugging (list_console_messages, evaluate_script, take_snapshot, take_screenshot, lighthouse_audit), plus heap-snapshot analysis, extensions and PWAs. Element actions use uids from the page snapshot, and most tools take a pageId.

Configuration flags cover the common cases: —headless, —isolated for a throwaway profile, —slim for a reduced tool set when only basic browsing is needed, and connecting to an already-running Chrome instead of launching one. The project also ships a CLI and skills for agents that prefer them to MCP.

Two defaults matter for privacy. Google collects usage statistics unless the server runs with —no-usage-statistics, and performance tools may send trace URLs to the Chrome UX Report API unless it runs with —no-performance-crux. The server also exposes everything in the browser instance to the MCP client, so keep personal sessions out of it.

When to Use It

Frontend debugging and performance work: Core Web Vitals (LCP, INP, CLS) regressions, failing network calls, console errors, layout problems, memory leaks. Verifying a UI change the agent just made in a real Chrome. Officially supports Google Chrome and Chrome for Testing only.

Alternatives: Playwright MCP for cross-browser scripted automation and end-to-end tests. browser-use for goal-level browsing tasks. Computer use when the target is not a browser.

Sources

• github.com/ChromeDevTools/chrome-devtools-mcp

• github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md

Example

A coding agent asked why the product page got slower. It opens the page, calls performance_start_trace with reload set, stops the trace, and runs performance_analyze_insight on the LCP insight. The trace points at a render-blocking script; the agent checks list_network_requests to confirm, edits the script tag to load deferred, and re-runs the trace to compare.

Example artifacts

Setup.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--no-usage-statistics"
      ]
    }
  }
}

Invocation.

{
  "name": "navigate_page",
  "input": {
    "pageId": 1,
    "type": "url",
    "url": "https://example.com/product"
  }
}

{
  "name": "performance_start_trace",
  "input": {
    "pageId": 1,
    "reload": true,
    "autoStop": true
  }
}

{
  "name": "list_network_requests",
  "input": {
    "pageId": 1
  }
}

Source: browser-use.com (Python)

Intent

Browser automation built specifically for AI agents, with an agent-loop API rather than a low-level browser-control API.

Motivating Problem

Playwright MCP gives the agent low-level browser primitives; the agent itself decides the action sequence. For many web tasks (“book me a flight”, “fill out this form”, “find and download this report”), the agent-loop structure repeats: read the page, decide what to click or fill, observe the result, repeat. browser-use packages that loop as the API: pass a high-level goal and a starting URL, get back a result.

How It Works

The library drives Chrome directly over the Chrome DevTools Protocol (it dropped Playwright) with a model-driven agent loop. The agent reads the page (structured DOM extraction with vision fallback), reasons about the next action, executes it, and observes. The user-facing API is high-level: agent.run(task) where task is a natural-language description. The internal loop is configurable --- you can swap the model, adjust the planning step, or intercept actions for approval.

Compared to Playwright MCP, browser-use trades off granularity for ergonomics: it’s the right choice when you want to delegate the whole task to the agent rather than orchestrating individual browser primitives. Compared to Computer Use, it’s browser-only but much faster and more reliable for browser-shaped tasks.

When to Use It

Browser tasks that can be expressed as a high-level goal. Web research agents that need to navigate complex sites. Form-filling and data-entry workflows where the form structure varies per site.

Alternatives --- Playwright MCP for fine-grained control. Computer Use for non-browser tasks. Direct API integration when one exists.

Sources

• browser-use.com

• github.com/browser-use/browser-use

Example

An agent that monitors government-procurement portals for relevant tenders. browser-use receives the task “find tenders matching {keywords} posted in the last 24 hours on portal {url}”; the library navigates the portal’s search UI, filters results, paginates through, and returns structured matches.

Example artifacts

Setup.

uv add browser-use    # Python 3.11 or later

Code.

from browser_use import Agent, ChatAnthropic

llm = ChatAnthropic(model="claude-sonnet-4-6")
agent = Agent(
task="Find new tenders on procurement.example.gov related to
'cybersecurity'.",
llm=llm,
)
history = await agent.run()
print(history.final_result())

Source: Google Workspace Gmail MCP server (official, developer preview)

Intent

Read and search Gmail messages and threads, draft replies, and manage labels.

Motivating Problem

Email is the most-asynchronous-but-still-replied-to channel for many people. Agents that can triage email inboxes, draft replies, and surface follow-up reminders save the dominant cost of most knowledge-worker days: inbox processing.

How It Works

Google’s remote server (gmailmcp.googleapis.com/mcp/v1, part of the Workspace MCP servers, in public developer preview since May 2026) exposes search_threads, get_thread, get_message, create_draft, list_drafts, list_labels, create_label, label_message, label_thread, unlabel_message and unlabel_thread. Authentication is Google OAuth 2.0.

The discipline for write operations is to draft, not send, and Google’s server builds it in: it has no send tool. create_draft is Tier 3 (reversible; the draft sits in the user’s drafts folder), and the user reviews it and sends it from Gmail. Third-party Gmail servers that do expose send make that call Tier 4.

When to Use It

Inbox triage and summarization. Drafting replies that the user then reviews. Searching for context across email history (“what did we agree about the launch date?”). Calendar-meeting follow-ups (combined with the Calendar tool).

Alternatives --- Microsoft Outlook MCP for Outlook-using organizations. The other Google Workspace MCP servers (Calendar, Drive and more) and Google’s Workspace CLI (gws) for organizations using the broader Workspace surface together.

Sources

• developers.google.com/workspace/gmail/api/guides/configure-mcp-server

• developers.google.com/workspace/guides/configure-mcp-servers

• registry.modelcontextprotocol.io

Example

End-of-day inbox triage: search_threads for unread messages, classify each by topic and urgency, create_draft for the routine acknowledgments, surface the genuinely-important threads to the user with a one-line summary each.

Example artifacts

Invocation.

{
  "name": "search_threads",
  "input": {
    "query": "is:unread newer_than:1d"
  }
}

{
  "name": "create_draft",
  "input": {
    "to": [
      "alice@example.com"
    ],
    "subject": "Re: Q3 numbers",
    "body": "Acknowledging --- will respond by EOD tomorrow.\n\nBest, ..."
  }
}

Setup.

# 1. Enable gmailmcp.googleapis.com in a Google Cloud project.
# 2. Create an OAuth client marked "Use this client for an
AI-powered
# agent".
# 3. Add the remote server to the MCP client:
{
"mcpServers": {
"gmail": {
"serverUrl": "https://gmailmcp.googleapis.com/mcp/v1",
"oauth": { "clientId": "...", "clientSecret": "..." }
}
}
}

Source: Linear MCP (official, hosted), Atlassian Rovo MCP Server (official)

Intent

Manage issues, projects, sprints, and comments in Linear or Jira via natural-language agent interactions.

Motivating Problem

An agent that can read and update the issue tracker becomes a working teammate on engineering and product work. The tasks are the same shape everywhere: triage incoming issues, query “what’s open in this sprint,” update issue status, comment on threads, link issues to PRs. Both Linear and Jira ship official MCP servers; tools differ by platform but the shapes are similar.

How It Works

Linear MCP exposes tools like linear_search_issues, linear_get_issue, linear_create_issue, linear_update_issue, linear_create_comment, linear_list_projects, linear_list_teams. The Atlassian Rovo MCP Server covers Jira, Confluence and more, with camelCase tools such as searchJiraIssuesUsingJql, getJiraIssue, createJiraIssue, addOrEditJiraIssueComment and getConfluencePage; its v2 endpoint (mcp.atlassian.com/v2/mcp) exposes a small primary set and finds the rest through discovery. The jira_search style names belong to the community sooperset/mcp-atlassian server.

Authentication: Linear via OAuth 2.1 (with dynamic client registration) to its hosted server at mcp.linear.app/mcp, with a read-only variant at /mcp/readonly, or an API key as a bearer token; Jira/Confluence via OAuth or API token. Both servers provide structured output (JSON with fields like assignee, status, labels) rather than the raw API responses.

When to Use It

Standup automation (“summarize what each person has open this sprint”). Issue triage from incoming bug reports. Cross-system automation that connects code (GitHub) to product (Linear/Jira). PR-review agents that close the loop by updating issue status when the PR merges.

Alternatives --- GitHub Issues for repositories that use GitHub Issues as the primary tracker (GitHub MCP from Section D handles it).

Sources

• linear.app/docs/mcp

• support.atlassian.com/atlassian-rovo-mcp-server/docs/supported-tools/

Example

An agent generating the weekly engineering report: linear_search_issues filtered by team and timeframe, group by status and project, render as a structured summary, and post it to the team’s Slack channel. Runs in under a minute and replaces a Friday-afternoon hand-roll.

Example artifacts

Invocation.

{
  "name": "linear_search_issues",
  "input": {
    "team": "ENG",
    "state": "InProgress",
    "limit": 50
  }
}

{
  "name": "linear_create_comment",
  "input": {
    "issueId": "ENG-1234",
    "body": "Reproduced on staging. Root cause is in the queue consumer."
  }
}

Setup.

{
  "mcpServers": {
    "linear": {
      "type": "http",
      "url": "https://mcp.linear.app/mcp"
    }
  }
}

Source: Google Workspace Calendar MCP server (official, developer preview)

Intent

Read, search, create, and modify calendar events; suggest meeting times; respond to invitations.

Motivating Problem

Scheduling is one of the few knowledge-work tasks that’s genuinely hard to delegate --- it requires reading multiple calendars, applying preferences, and negotiating timezones. An agent that can do all three replaces a meaningful percentage of administrative time. Calendar tools handle the read/write half; the human still mostly handles the negotiation.

How It Works

Google’s remote server (calendarmcp.googleapis.com/mcp/v1) covers the standard calendar operations: list_calendars, list_events (with time range filters), search_events, get_event, create_event, update_event, delete_event, respond_to_event, and the higher-level suggest_time (which finds free windows across one or more calendars matching constraints).

Notably, suggest_time is where the real value is. The agent gathers constraints (“30 minutes with alice and bob next week”), queries the calendars for free/busy data, and returns ranked time options. The model handles timezone arithmetic and meeting-length math better than humans typically do.

When to Use It

Anywhere an agent needs to participate in scheduling. Daily digest agents (“what’s on the calendar today”). Auto-responding to invites with policy (decline lunch hour, accept dev syncs). Pair with Gmail for full meeting-coordination flows.

Alternatives --- Microsoft Calendar (Outlook) MCP for organizations on the Microsoft stack. Calendly-style purpose-built scheduling tools when negotiation with external parties is the dominant case.

Sources

• developers.google.com/workspace/calendar/api/guides/configure-mcp-server

• registry.modelcontextprotocol.io

Example

An agent helping schedule a four-person meeting next week. suggest_time across the four calendars finds three windows; the agent picks the one with the longest buffer on each side; create_event with the right attendees and a generated agenda based on the meeting topic.

Example artifacts

Invocation.

{
  "name": "suggest_time",
  "input": {
    "calendars": [
      "alice@x.com",
      "bob@x.com"
    ],
    "duration_minutes": 30,
    "earliest": "2026-05-20T09:00:00Z",
    "latest": "2026-05-24T17:00:00Z",
    "working_hours_only": true
  }
}

{
  "name": "create_event",
  "input": {
    "calendar": "primary",
    "summary": "Architecture review",
    "start": "2026-05-21T15:00:00Z",
    "end": "2026-05-21T15:30:00Z",
    "attendees": [
      "alice@x.com",
      "bob@x.com"
    ]
  }
}

Setup.

{
  "mcpServers": {
    "calendar": {
      "serverUrl": "https://calendarmcp.googleapis.com/mcp/v1",
      "oauth": {
        "clientId": "...",
        "clientSecret": "..."
      }
    }
  }
}

Source: Cloudflare API MCP Server (mcp.cloudflare.com/mcp, github.com/cloudflare/mcp); domain-specific servers in github.com/cloudflare/mcp-server-cloudflare

Intent

Operate Cloudflare resources --- Workers, KV, R2, D1, DNS, Pages, Analytics --- from inside an agent.

Motivating Problem

Cloudflare is one of the most-used edge platforms. Agents that can deploy Workers, query KV namespaces, manage DNS records, or pull analytics from inside a session collapse a number of operational tasks (“why is this domain slow”, “deploy this Worker”, “what’s the cache hit rate”) into single-prompt workflows.

How It Works

The recommended Cloudflare API MCP Server exposes the whole Cloudflare API (about 2,500 endpoints) through Code Mode instead of one tool per endpoint. It has a handful of tools: search (the agent writes JavaScript that queries the OpenAPI spec to find endpoints), execute (the agent writes JavaScript that calls cloudflare.request() against the endpoints it found), docs (search Cloudflare’s developer documentation) and whoami. The tool definitions cost about 1,100 tokens, against roughly 244,000 for minimal per-endpoint tools. Authentication is OAuth by default, where the user picks permissions during authorization; an API token, scoped to specific resources to limit blast radius, is the option for CI and automation.

The product breadth is the point: most cloud MCPs cover a narrow slice; Cloudflare’s API server covers the entire API as one server with consistent auth. The older mcp-server-cloudflare repository now holds domain-specific remote servers (documentation, containers, browser rendering and others). Code Mode itself is described in Section J.

When to Use It

Cloudflare-hosted infrastructure: deploying or debugging Workers, managing edge data (KV, R2), reading analytics. Pair with Git MCP and GitHub MCP for code-to-deploy workflows.

Alternatives --- Cloudflare’s wrangler CLI invoked via bash for ad-hoc operations; direct REST API calls for one-off uses. The MCP wins when an agent is doing repeated Cloudflare operations as part of a larger workflow.

Sources

• developers.cloudflare.com

• github.com/cloudflare/mcp

• github.com/cloudflare/mcp-server-cloudflare

Example

An agent debugging a slow site. It calls search to find the analytics and Workers endpoints, then execute with a short script that pulls performance metrics by route and lists the account’s Workers; it identifies a slow Worker and, after approval, deploys an optimized version through another execute call. End-to-end inside a single chat.

Example artifacts

Invocation.

{
  "name": "search",
  "input": {
    "code": "// JavaScript that filters spec.paths for Workers scripts"
  }
}

{
  "name": "execute",
  "input": {
    "code": "// JavaScript that calls cloudflare.request() on the endpoints found above"
  }
}

Setup.

{
  "mcpServers": {
    "cloudflare-api": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

Source: github.com/awslabs/mcp (broad family); awslabs.bedrock-kb-retrieval-mcp-server (Bedrock)

Intent

Retrieve from AWS Bedrock Knowledge Bases via MCP; access broader AWS services through the AWS Labs MCP project.

Motivating Problem

AWS Bedrock Knowledge Bases give organizations a managed RAG layer: documents are ingested, indexed, and queryable as vector retrieval. The AWS KB MCP exposes that as a tool any agent (not just Bedrock-hosted agents) can call. The broader AWS MCP surface is less consolidated than Cloudflare’s but growing rapidly through the AWS Labs MCP servers project.

How It Works

The AWS Labs Bedrock Knowledge Bases Retrieval MCP server wraps the Bedrock Agent Runtime retrieval APIs. Its tools are ListKnowledgeBases, QueryKnowledgeBases (pass a query and a knowledge-base ID, get back ranked passages with citations) and AgenticQueryKnowledgeBases. Authentication is via standard AWS credentials, usually an AWS_PROFILE.

Beyond Bedrock KB, AWS now points to a few starting servers: the AWS MCP Server (remote and managed by AWS, in preview) or the AWS API MCP Server (all services through validated CLI commands) for general AWS work, the AWS Knowledge MCP Server (remote, at knowledge-mcp.global.api.aws) for documentation, and the AWS IaC MCP Server for CDK and CloudFormation, which absorbed the earlier CDK server. The AWS Labs project (github.com/awslabs/mcp) adds specialized servers for S3, DynamoDB and many others. The ecosystem is more fragmented than Cloudflare’s because AWS’s surface is much broader.

When to Use It

Agents that need to retrieve from organizationally-curated knowledge stored in Bedrock KB. AWS infrastructure operations where a service-specific MCP is available. Documentation-heavy queries (AWS Knowledge MCP Server).

Alternatives --- boto3 (the AWS Python SDK) invoked via code_execution for ad-hoc operations. The AWS CLI via bash for command-line-shaped operations. The MCP layer pays off when the agent is doing repeated structured operations.

Sources

• docs.aws.amazon.com/bedrock

• docs.aws.amazon.com/aws-mcp/latest/userguide/what-is-mcp-server.html

• github.com/awslabs/mcp

Example

An internal-support agent grounded in company SOPs ingested into Bedrock KB. User asks a question; agent calls QueryKnowledgeBases to get the top relevant passages; answers from those passages with citations.

Example artifacts

Invocation.

{
  "name": "QueryKnowledgeBases",
  "input": {
    "knowledge_base_id": "KB123...",
    "query": "What's the on-call escalation policy?",
    "number_of_results": 5
  }
}

Setup.

{
  "mcpServers": {
    "aws-kb": {
      "command": "uvx",
      "args": [
        "awslabs.bedrock-kb-retrieval-mcp-server@latest"
      ],
      "env": {
        "AWS_PROFILE": "your-profile-name",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

Source: Flux159/mcp-server-kubernetes (kubectl wrapper); containers/kubernetes-mcp-server (native Go, API-based)

Intent

Inspect cluster state, read pod logs, apply manifests, manage deployments --- the standard kubectl operations as agent tools.

Motivating Problem

Kubernetes operations are a high-volume, high-skill domain: reading pod logs, applying manifests, scaling deployments, diagnosing pod failures. An agent with kubectl access turns natural-language debugging requests (“why is the api-service pod restarting?”) into the right kubectl commands without the user needing to remember kubectl idioms.

How It Works

Two community servers dominate. Flux159/mcp-server-kubernetes wraps kubectl operations: kubectl_get (pods, deployments, services, namespaces, custom resources), kubectl_logs, kubectl_describe, kubectl_apply, kubectl_delete, kubectl_scale, kubectl_rollout. containers/kubernetes-mcp-server (from Red Hat’s containers organization) calls the Kubernetes API directly rather than wrapping kubectl, and offers a read-only mode. The examples below use the Flux159 names. Authentication uses standard kubeconfig; the agent runs with whatever permissions the kubeconfig grants.

The discipline is to deploy with carefully-scoped kubeconfig: read-only access for diagnostic agents, write access only with explicit approval gates for any apply/delete/scale operation. The wshobson/agents skills (Section C of the Skills Catalog) include Kubernetes-specific patterns for templating manifests safely.

When to Use It

Cluster diagnostics agents that answer “what’s wrong with X?” Live-incident response agents that produce situation summaries from cluster state. Deployment-automation agents (with strict guardrails; kubectl apply is a Tier 4 operation).

Alternatives --- direct kubectl via bash for ad-hoc operations. Helm-specific MCPs for Helm-based deployments. The kubernetes-python-client wrapped via code_execution for richer queries that don’t fit kubectl’s shape.

Sources

• kubernetes.io

• github.com/Flux159/mcp-server-kubernetes

• github.com/containers/kubernetes-mcp-server

Example

On-call response: alert fires that the api-service is failing. Agent runs kubectl_get on the deployment, kubectl_describe to see events, kubectl_logs on the most-recently-restarted pod. Reports back: image pull error, the new tag doesn’t exist in the registry. Suggests rollback with kubectl_rollout undo --- but doesn’t execute it without explicit confirmation.

Example artifacts

Invocation.

{
  "name": "kubectl_get",
  "input": {
    "resource": "pods",
    "namespace": "production",
    "selector": "app=api-service"
  }
}

{
  "name": "kubectl_logs",
  "input": {
    "pod": "api-service-abc123",
    "namespace": "production",
    "tail": 100
  }
}

// Tier 4 --- requires approval:
{
  "name": "kubectl_rollout",
  "input": {
    "action": "undo",
    "resource": "deployment/api-service",
    "namespace": "production"
  }
}

Source: getsentry/sentry-mcp (remote server at mcp.sentry.dev/mcp; npm: @sentry/mcp-server for stdio)

Intent

Give a coding or incident-response agent direct access to error tracking and observability data: issues, stack traces, events, traces, logs, releases and monitors.

Motivating Problem

An agent fixing a production bug usually starts from a report that says “it crashed”. The facts it needs (the stack trace, how often it happens, which release introduced it, the request that triggered it) sit in the error tracker. Copy-pasting them into the chat loses detail and goes stale. Error-tracking and observability MCP servers have become a standard part of incident-response agents, and Sentry hosts an official one aimed at coding assistants.

How It Works

Sentry runs the server remotely at mcp.sentry.dev/mcp. Connections use OAuth: the first connection triggers a Sentry sign-in. The URL can be scoped to one organization (/mcp/{organizationSlug}) or one project (/mcp/{organizationSlug}/{projectSlug}); scoped connections default tools to that org or project and hide discovery tools, and Sentry recommends scoping to a project where possible. A stdio transport (npx @sentry/mcp-server with a user auth token) exists mainly for self-hosted Sentry.

Tools cover issues (get_issue_details, get_event_stacktrace, get_issue_breadcrumbs, update_issue), search (search_issues, search_events, search_errors, search_traces, search_logs), traces, replays, releases, dashboards, monitors and alert rules, project setup, Sentry documentation, and Seer, Sentry’s AI root-cause analysis (analyze_issue_with_seer). Tools are grouped into skills such as inspect, triage and seer, and a query parameter narrows the exposed set. The natural-language search tools call an LLM provider configured on the server side.

Sentry describes the server as built for human-in-the-loop coding agents and developer debugging workflows, not as a general-purpose MCP server for all of Sentry.

When to Use It

Coding agents fixing bugs that Sentry already captured. Incident-response agents that need error rates, traces and recent releases next to the cluster state from the Kubernetes tools. Triage agents that group and assign incoming issues (with approval on update_issue).

Alternatives: the observability vendor’s own MCP server when the team uses a different stack (for example Grafana, Datadog or Honeycomb); the Sentry CLI or REST API through bash for one-off queries.

Sources

• github.com/getsentry/sentry-mcp

• docs.sentry.io/product/sentry-mcp/

• mcp.sentry.dev

Example

An on-call agent gets a page for checkout errors. It calls search_issues for unresolved issues in the checkout project from the last hour, then get_issue_details on the top one: a null-reference error that started with the latest release. It reads the stack trace, notes the release that introduced it, and drafts a rollback recommendation for the human on call.

Example artifacts

Setup.

// Claude Code:
claude mcp add --transport http sentry
https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}

// Other MCP clients:
{
"mcpServers": {
"sentry": {
"url": "https://mcp.sentry.dev/mcp/my-org/checkout"
}
}
}

Invocation.

{
  "name": "get_issue_details",
  "input": {
    "organizationSlug": "my-org",
    "issueId": "CHECKOUT-41"
  }
}

Source: crystaldba/postgres-mcp (Postgres MCP Pro); Supabase MCP (supabase-community/supabase-mcp); MCP Toolbox for Databases

Intent

Query PostgreSQL databases from inside an agent --- schema introspection, table queries, and (with care) limited mutations.

Motivating Problem

Most internal data lives in Postgres. An agent that can query Postgres --- “how many users signed up last week?”, “show me the orders for customer X”, “what’s the schema of the events table?” --- becomes a working business-analyst layer. Without an MCP, the agent has to write SQL and ask a human to run it, which defeats the purpose.

How It Works

Postgres MCPs expose a small schema-plus-SQL surface: list the schemas and tables, describe an object, run SQL. Postgres MCP Pro has list_schemas, list_objects, get_object_details and execute_sql, plus explain_query, index tuning (analyze_workload_indexes, analyze_query_indexes) and analyze_db_health; its restricted access mode limits the agent to read-only transactions with an execution-time limit. Supabase’s hosted server (mcp.supabase.com/mcp) exposes list_tables and execute_sql plus apply_migration and project-management tools, and takes a read_only flag. Google’s MCP Toolbox for Databases (next entry) covers Postgres among many engines. The original reference server (@modelcontextprotocol/server-postgres) is deprecated, as are several small community packages, so check maintenance before installing.

Authentication via standard Postgres connection strings or service tokens. The discipline is connection-string-as-credential: production agents should be connected via a read-only role on a read replica, with the server’s read-only mode on as well; write access is a deliberate, separate configuration.

When to Use It

Internal-analytics agents grounded in Postgres data. Customer-support agents that look up account state. Database-introspection tools (“what’s the foreign key structure?”, “what indexes exist on this table?”). Pair with the wshobson/agents sql-optimization-patterns skill (Skills Catalog Section C) for query-tuning workflows.

Alternatives --- ORM-specific MCPs (Prisma, SQLAlchemy) for richer abstraction; direct psycopg via code_execution for one-off queries; Supabase MCP specifically when the deployment is on Supabase.

Sources

• github.com/crystaldba/postgres-mcp

• github.com/supabase-community/supabase-mcp

• registry.modelcontextprotocol.io

Example

A product-analytics agent asked “which features did users with churn risk use most?”. PostgreSQL MCP lists the relevant tables, describes their schemas, and runs a SELECT joining user_features and churn_predictions. The agent gets structured rows; it summarizes the result for the user.

Example artifacts

Invocation.

// Postgres MCP Pro tool names:
{ "name": "list_objects", "input": {
"schema_name": "public", "object_type": "table" } }

{ "name": "get_object_details", "input": {
"schema_name": "public", "object_name": "events"
} }

{ "name": "execute_sql", "input": {
"sql": "SELECT count(*) FROM users WHERE created_at >=
'2026-05-01'"
} }

Setup.

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "DATABASE_URI",
        "crystaldba/postgres-mcp",
        "--access-mode=restricted"
      ],
      "env": {
        "DATABASE_URI": "postgresql://reader:***@db.internal/analytics"
      }
    }
  }
}

Source: googleapis/mcp-toolbox (formerly Gen AI Toolbox for Databases; npm: @toolbox-sdk/server)

Intent

One open-source MCP server that connects agents to many databases, with prebuilt generic tools for exploration and a configuration file for defining narrow, safe production tools.

Motivating Problem

Teams rarely have one database. An agent stack that installs a separate community MCP per engine (one for Postgres, another for MySQL, another for BigQuery) inherits each one’s maintenance risk, auth model and tool naming. Google’s MCP Toolbox for Databases is the common answer to “which database MCP should we use”: one server, maintained by Google, that speaks to most engines and lets the team decide exactly which queries the agent may run.

How It Works

The Toolbox serves two purposes. As a ready-made server, it starts with a —prebuilt flag naming a database (for example —prebuilt=postgres) and exposes generic tools such as list_tables and execute_sql; a toolset suffix (—prebuilt=postgres/data) narrows that set. Connection details come from environment variables documented in the prebuilt reference. Supported engines include AlloyDB, BigQuery, Cloud SQL (PostgreSQL, MySQL, SQL Server), Spanner and Firestore on Google Cloud, plus PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, MongoDB, Redis, Elasticsearch, CockroachDB, ClickHouse, Neo4j, Snowflake, Trino and others.

As a framework, it reads a tools.yaml file that declares sources (database connections) and tools (a named, described statement with typed parameters, such as a parameterized SELECT that searches hotels by name). The agent then sees only those tools rather than raw SQL. The server handles connection pooling, IAM-integrated auth and OpenTelemetry tracing, and SDKs for Python, JavaScript/TypeScript, Go and Java load the same tools into ADK, LangChain, LlamaIndex or custom agents.

When to Use It

Development agents that need to explore several databases from one server. Production agents where the safe pattern is a fixed set of parameterized queries rather than open execute_sql. Google Cloud databases, where Google also offers managed MCP servers as an alternative.

Alternatives: an engine-specific server when it adds something the Toolbox lacks (Postgres MCP Pro’s index tuning, Supabase’s migration tools); MotherDuck’s DuckDB server for analytics over files.

Sources

• github.com/googleapis/mcp-toolbox

• mcp-toolbox.dev

Example

A support agent needs to look up orders but must never run arbitrary SQL against production. The team writes a tools.yaml with one Postgres source and two tools, find-orders-by-email and get-order-status, each a parameterized SELECT on a read replica. The agent connects to the Toolbox and can call only those two tools.

Example artifacts

Setup.

// Prebuilt generic tools for one Postgres database:
{
"mcpServers": {
"toolbox-postgres": {
"command": "npx",
"args": ["-y", "@toolbox-sdk/server",
"--prebuilt=postgres",
"--stdio"]
}
}
}

Custom tool (tools.yaml).

kind: tool
name: search-hotels-by-name
type: postgres-sql
source: my-pg-source
description: Search for hotels based on name.
parameters: [{ name: name, type: string,
description: The name of the hotel. }]
statement: SELECT * FROM hotels WHERE name ILIKE '%' || \$1 ||
'%';

Source: MotherDuck’s DuckDB MCP server (motherduckdb/mcp-server-motherduck); for Claude Code, DuckDB’s own skills plugin (duckdb/duckdb-skills)

Intent

Analytical SQL over local files (CSV, Parquet, JSON, Excel) or remote sources, using DuckDB’s friendly SQL dialect.

Motivating Problem

Many analytical questions are over files rather than databases: a CSV the user uploaded, a Parquet file on S3, an Excel workbook with multiple sheets. DuckDB is the standard tool for this; its SQL dialect handles all the relevant formats natively and runs in-process. DuckDB MCP wraps it as tools.

How It Works

The maintained DuckDB MCP server is MotherDuck’s mcp-server-motherduck, run locally with uvx against an in-memory database, a local .duckdb file, or MotherDuck (which also hosts a remote version). Its tools are execute_query (SQL in the DuckDB dialect), list_databases, list_tables, list_columns and, when enabled, switch_database_connection. A local file opens read-only unless the server starts with —read-write. Separately, DuckDB publishes duckdb/duckdb-skills, a Claude Code plugin of skills (attach-db, query, read-file and others) that call the DuckDB CLI rather than an MCP server; those belong with the Skills Catalog (Volume 2).

The friendly-SQL dialect matters: DuckDB supports operations like SELECT * FROM ‘data.csv’ or SELECT * FROM read_parquet(‘s3://bucket/file.parquet’) directly, without explicit table creation. This is what makes DuckDB MCP unusually well-suited to ad-hoc analytical work.

When to Use It

Ad-hoc analysis of uploaded files. Querying Parquet or CSV data on cloud storage. Cross-file analysis (joining multiple CSVs into one query). Particularly useful for data-science workflows where the data isn’t yet in a managed database.

Alternatives --- pandas via code_execution for richer Python-shaped analysis. ClickHouse MCP for column-store analytical workloads at scale. PostgreSQL MCP when the data is already in a managed Postgres.

Sources

• duckdb.org

• github.com/motherduckdb/mcp-server-motherduck

• github.com/duckdb/duckdb-skills

Example

A user uploads three months of CSV exports from a SaaS billing system. DuckDB MCP runs SELECT month, SUM(amount) FROM ‘invoices_*.csv’ GROUP BY month --- the wildcard syntax loads all three files; the aggregation runs in milliseconds; the result is a small table the agent renders inline.

Example artifacts

Invocation.

{
  "name": "execute_query",
  "input": {
    "sql": "SELECT region, SUM(revenue) FROM 'sales_2026_q*.parquet' GROUP BY region"
  }
}

{
  "name": "execute_query",
  "input": {
    "sql": "SELECT count(*) FROM read_parquet('s3://my-bucket/events/2026/05/*.parquet')"
  }
}

Setup.

{
  "mcpServers": {
    "duckdb": {
      "command": "uvx",
      "args": [
        "mcp-server-motherduck",
        "--db-path",
        ":memory:",
        "--read-write"
      ]
    }
  }
}

Source: Anthropic tool-use documentation (platform.claude.com); “Writing effective tools for agents” and “Building Effective Agents” (Anthropic)

Intent

Write a tool’s name and description so the model reliably selects the right tool for a request --- and declines the wrong ones --- given only the definitions it sees, never the implementation behind them.

Motivating Problem

The model chooses among tools by reading their descriptions; nothing else routes the call. A description that says what a tool does but not when to use it, or that overlaps a neighbor, produces the failure modes custom tools are plagued by: the model calls the wrong tool, calls nothing when it should, or picks unpredictably between two plausible matches. As the catalog grows, these routing errors compound. The description is a prompt --- the most-read prompt in the whole agent --- and it is too often written as an afterthought on top of an API doc.

How It Works

What, when, and when-not: the reliable shape for a description gives three things --- what the tool does, when to use it, and when not to. “Look up one order by its ID. Use when the user names a specific order. Do not use to search orders by customer or date; use search_orders for that.” The when-not clause is what separates two overlapping tools.

Disambiguation: when two tools could match a request, distinguish them explicitly. Anchor each by domain (get_invoice for billing, get_order for fulfilment), name the trigger that should fire it, and exclude the other’s territory by name. Distinct verbs help the model more than distinct nouns do.

Names prime, descriptions decide: the model weighs the description far more heavily than the name, but the name still primes selection. Prefer specific, verb-led names (search_orders over query, get_customer over lookup), and avoid generic names that collide as the catalog grows.

Framing the return in the description: telling the model what the tool returns --- a single object, a list, a boolean, a status --- shapes how it plans the next step and whether it calls the tool at all.

Selection is testable: routing reliability is a property you measure, not assume. Run the tool set against varied phrasings of the same intent, and against edge and adversarial phrasings, watching for misroutes and for selection drift as new tools are added. When two tools keep getting confused, the fix is usually a sharper description or a merged tool, not a third tool.

When to Use It

Every custom tool, and re-examined whenever a tool is added to an agent that already has several. The discipline matters most where tools overlap in domain --- multiple search tools, multiple write tools --- and where a wrong call is expensive or irreversible. It pairs with tool scoping: the fewer tools in scope, the easier the routing (Volume 18, Project subagents).

Alternatives --- system-prompt routing rules (Volume 15) when descriptions alone cannot disambiguate; consolidating two overlapping tools into one with an enum parameter rather than sharpening two descriptions.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/overview

• anthropic.com/engineering/writing-tools-for-agents

• anthropic.com/research/building-effective-agents

Example artifacts

Code.

{
  "name": "get_order_status",
  "description": "Get the current status of one order by its order ID. Use when the user names a specific order. Do NOT use to search orders by customer, product, or date; use search_orders for that. Returns a status object, or an order_not_found error.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "The order ID, e.g. ORD-4821" }
    },
    "required": ["order_id"]
  }
}

Source: JSON Schema specification; Anthropic tool-use and OpenAI function-calling documentation

Intent

Design a tool’s JSON input schema --- its parameter names, types, required set, and constraints --- as a contract that guides the model to generate valid arguments and rejects invalid ones, rather than as a loose shape validated only after the call.

Motivating Problem

The input schema is the second half of the interface: the description tells the model whether to call the tool, the schema tells it how. A schema with vague names, no constraints, and everything optional lets the model supply an email where an ID belongs, invent an enum value, or omit the one field the handler needs. Each parameter’s name and description is a micro-prompt the model reads while composing arguments; a sloppy schema produces sloppy arguments, and the handler pays for it downstream.

How It Works

Name parameters unambiguously: customer_id beats id; start_date beats when. Prefer snake_case, and let the name carry the meaning. Avoid overloaded names (a bare id when several entities are in play) and cryptic abbreviations.

Descriptions as micro-prompts: each parameter’s description guides the value the model generates. State the format (an ISO 8601 date, a Stripe customer ID like cus_1234, the ID and not the email), and note boundary cases. This is where extraction reliability is won.

Constrain the value space: use enum for fields with a fixed set of valid values, so the model cannot invent one; use type plus format (date-time, email) and bounds (minimum, maximum, minLength, pattern) to reject malformed input before the handler runs. Set additionalProperties to false so unexpected keys are caught rather than silently passed. On the Claude API, setting strict to true on the tool definition (strict tool use) makes the model’s inputs follow the schema exactly, so these constraints are enforced rather than advisory.

Design the required set deliberately: mark a field required only if the tool genuinely cannot function without it. A lean required set is more reliable --- fewer forced fields means fewer hallucinated ones. For useful-but-not-critical fields, make them optional with a sensible default and handle their absence gracefully.

Test the schema three ways: a positive case (valid input parses and runs), a negative case (invalid input is rejected with a useful error), and a disambiguation case (an ambiguous input maps to the intended field). Schema quality is measured, like description quality.

When to Use It

Every custom tool, and especially tools used for structured extraction, where the schema is doing the heavy lifting (Volume 15, structured output). The discipline is highest-value for tools that mutate state or spend money, where a wrong argument is costly, and for enums and identifiers, where a hallucinated value fails silently.

Alternatives --- accepting a free-form string and parsing inside the handler when the input genuinely does not fit a schema (at the cost of moving validation past the interface); vendor structured-output features (Volume 15) when the goal is a typed model output rather than a tool input.

Sources

• json-schema.org

• platform.claude.com/docs/en/agents-and-tools/tool-use/overview

• anthropic.com/engineering/writing-tools-for-agents

Example artifacts

Code.

{
  "type": "object",
  "properties": {
    "customer_id": {
      "type": "string",
      "description": "Stripe customer ID, e.g. cus_1234. Not the email address."
    },
    "reason": {
      "type": "string",
      "enum": ["duplicate", "fraudulent", "requested_by_customer"],
      "description": "Why the refund is issued. Must be one of the three allowed values."
    },
    "amount_cents": {
      "type": "integer",
      "minimum": 1,
      "description": "Amount to refund in cents. Omit to refund the full charge."
    }
  },
  "required": ["customer_id", "reason"],
  "additionalProperties": false
}

Source: Anthropic tool-use documentation; practitioner conventions for agent error handling

Intent

Shape what a tool returns --- both success results and errors --- so the model can decide what to do next: trim results to the signal the model needs, and return errors as structured, actionable responses rather than raw stack traces.

Motivating Problem

A tool’s return value is context the model must reason over, and it is the third face of the interface. Two failures are common. First, tools return everything --- an eighty-field API response when the agent needs three --- bloating context, burying the signal, and pushing key facts into the lost-in-the-middle zone. Second, tools surface errors as raw exceptions or opaque strings, so the model cannot tell a retryable timeout from a permanent not-found, and either gives up or retries forever. The result contract determines whether the agent recovers.

How It Works

Trim the result to the signal: return the fields the model needs to act, not the full upstream payload. For a stable response shape, keep a fixed field list; for a variable one, summarize; for a genuinely large payload, store it and return a reference the agent can fetch on demand. Trim at model time, not display time.

Errors as structured responses: return an error the model can branch on --- a stable error_code (ORDER_NOT_FOUND, RATE_LIMITED), a human-readable message that includes the triggering value, a context object, and, where useful, a suggested_action naming what to do next. Stable codes over prose; no raw stack traces.

Separate user errors from system errors: a bad ID the user supplied should be surfaced for the user to correct; a transient dependency failure should be handled or retried without bothering the user. The error’s shape tells the model which path to take.

Signal empty versus failed: distinguish “the query ran and found nothing” from “the query could not run.” A search that returns an empty list because the backend was unreachable is not the same as a search that found nothing, and the model must not report one as the other. A typed status (success, empty_result, access_failure) lets the model retry a failure but not a genuine empty.

Design for safe retry: for tools that mutate state, make retries idempotent --- accept a client-supplied idempotency key, store-and-return on repeat --- so a retried call does not double-charge or double-send. Surface partial success (which items succeeded, which failed and why) rather than an all-or-nothing result.

When to Use It

Every custom tool. Result trimming matters most for verbose upstream APIs and for multi-call workflows where bloat stacks. The error contract matters most for tools that fail in more than one way and for anything the agent is expected to recover from autonomously (Volume 1, Exception Handling and Recovery).

Alternatives --- returning raw output when the model has proven able to parse it and context budget is not a concern; handling all retries and idempotency in an orchestration layer (Volume 4, durable execution) rather than in the tool, when that layer already exists.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/overview

• anthropic.com/engineering/writing-tools-for-agents

• anthropic.com/research/building-effective-agents

Example artifacts

Code.

{
  "error_code": "ORDER_NOT_FOUND",
  "message": "No order with ID ORD-4821 exists.",
  "context": { "order_id": "ORD-4821" },
  "suggested_action": "Ask the user to confirm the order number, or call search_orders."
}

Source: Anthropic programmatic tool calling (platform.claude.com); “Code execution with MCP” (Anthropic Engineering, November 2025); “Code Mode: give agents an entire API in 1,000 tokens” (Cloudflare, February 2026)

Intent

Let the model write a short program that calls tools as functions inside a sandbox, so that many calls, loops and filtering happen in one step and only the final result enters the model’s context.

Motivating Problem

With one JSON tool call per model turn, two costs grow with the tool surface. Every tool definition sits in context before any work starts, and every intermediate result passes through the model even when it only needs to be filtered or handed to the next call. Checking budget compliance for 20 employees means 20 model round trips and thousands of expense lines in context. An API with thousands of endpoints cannot be offered one tool per endpoint at all: Cloudflare measured about 244,000 tokens for its API even with minimal per-endpoint schemas.

How It Works

The tools are presented to the model as a typed code API, and the model writes code against it that runs in a sandbox. Intermediate results stay in the sandbox; the model sees only what the code prints or returns.

• Anthropic programmatic tool calling: a tool definition with allowed_callers set to code_execution_20260120 (or later) becomes callable from Python that Claude runs in the code execution container. When the code calls the tool, execution pauses and the API returns a tool_use block whose caller field names the code execution run; your application returns the result, and the code continues. Intermediate results are not loaded into Claude’s context window. It requires code_execution_20260120 or later.

• Code execution with MCP: the agent harness presents MCP servers as a file tree of typed functions. The agent lists the tree and reads only the tool files it needs, which in Anthropic’s example cut tool-definition tokens from 150,000 to 2,000 (98.7%). Because data flows between tools inside the sandbox, the harness can tokenize sensitive fields so that, for example, customer emails move from a spreadsheet to a CRM without entering the model’s context.

• Cloudflare Code Mode: a server exposes a search tool (the model writes JavaScript to query the API’s OpenAPI spec) and an execute tool (the model writes JavaScript that calls the API), both run in a Workers isolate with no file system and outbound fetches disabled by default. Cloudflare’s API server covers about 2,500 endpoints in roughly 1,000 tokens of tool definitions, and new endpoints need no new tools.

For the workflow side (each agent step is a program rather than one call), see Volume 1, Code-as-Action (CodeAct / Code Mode).

When to Use It

Workflows that call the same tools many times (per item in a list, per page of results). Large tool surfaces or whole APIs that would not fit as individual tools. Pipelines where intermediate data is large or sensitive and only a summary should reach the model.

Weaker fit: single calls, and tools whose every result the model must read anyway. The pattern needs a sandbox and moves risk into generated code, so the sandbox’s network and credential limits become part of the tool design (Section C). Alternatives: tool search (Section A) when the problem is only the number of definitions; a few consolidated tools with enum parameters when the surface is small.

Sources

• platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling

• anthropic.com/engineering/code-execution-with-mcp

• blog.cloudflare.com/code-mode-mcp/

• github.com/cloudflare/mcp

Example

A finance agent checks 20 employees’ expenses against their budgets. With programmatic tool calling, Claude writes one script that calls get_expenses for each employee, sums each total, compares it with get_budget, and prints only the three employees over their limit. The model reads three lines instead of hundreds of kilobytes of line items.

Example artifacts

Tool schema.

tools: [
{ "type": "code_execution_20260120", "name": "code_execution"
},
{ "name": "query_database",
"description": "Execute a SQL query against the sales database.
Returns a list of rows as JSON objects.",
"input_schema": { "type": "object",
"properties": { "sql": { "type": "string" } },
"required": ["sql"] },
"allowed_callers": ["code_execution_20260120"] }
]

Invocation.

# The API pauses Claude's code and returns a call to your tool:
{ "type": "tool_use", "name": "query_database",
"input": { "sql": "..." },
"caller": { "type": "code_execution_20260120",
"tool_id": "srvtoolu_abc123" } }

# Return the tool_result with the same container ID; the code
# resumes, and only its final output reaches Claude's context.

Source: microsoft/playwright-cli and microsoft/playwright-mcp READMEs; ChromeDevTools/chrome-devtools-mcp (CLI and skills)

Intent

Give a coding agent a concise command-line tool plus a skill that teaches it the commands, instead of an MCP server, when the agent already has a shell and context is the scarce resource.

Motivating Problem

MCP puts every tool schema into context at connection time, and some servers return large payloads on every call: a browser server returns an accessibility tree after each action. For a coding agent that must also hold a codebase, test output and its own reasoning, that cost competes with the actual work. The agent already has a bash tool; a CLI with short, purpose-built commands can do the same job while the model reads only the output it asks for.

How It Works

The vendor ships a CLI and a skill (a SKILL.md, Chapter 3) that describes when and how to use its commands. The agent invokes the CLI through its shell tool. Nothing is loaded up front beyond the skill’s short description, and each command prints only what that step needs.

Microsoft’s Playwright README says this directly: coding agents increasingly favor CLI-based workflows exposed as skills because CLI calls avoid loading large tool schemas and verbose accessibility trees into context, and it recommends the Playwright CLI with skills for coding agents. The MCP server remains the better fit for loops that benefit from persistent state and rich introspection over page structure: exploratory automation, self-healing tests, long-running autonomous workflows. Google’s Chrome DevTools project ships its MCP server alongside a CLI and skills, and Google’s Workspace CLI sits alongside its Workspace MCP servers.

The trade-off is reach. MCP works in any MCP client, including chat apps with no shell; a CLI needs an agent with a shell and the permission to run it, which brings the bash tool’s permission tiers (Chapter 5) with it.

When to Use It

Coding agents with shell access (Claude Code, Copilot, Codex and similar) where context budget is tight and the vendor ships a CLI. Tools that produce large outputs the agent only sometimes needs.

Prefer an MCP server when the client has no shell, when the deployment needs MCP’s auth and per-tool approval, or when the workflow needs persistent session state across many calls. Alternatives: tool search (Section A) and Code Mode (this section) to keep MCP while cutting its context cost.

Sources

• github.com/microsoft/playwright-cli

• github.com/microsoft/playwright-mcp

• github.com/ChromeDevTools/chrome-devtools-mcp

Example

A coding agent asked to test a to-do app’s “add item” flow. With the Playwright CLI and its skill installed, the agent runs playwright-cli open on the demo URL, then type and press commands for each item, and takes a screenshot of each result. It reads only the command output it asked for, without a full accessibility tree after every action.

Example artifacts

Setup.

npm install -g \@playwright/cli\@latest
playwright-cli install --skills    # installs the skill for the
agent

# The agent then drives the browser through its shell:
playwright-cli open https://demo.playwright.dev/todomvc/
playwright-cli type "Buy groceries"
playwright-cli press Enter

Appendix A --- Tier Reference Table

Cross-reference between the four families (from Chapter 2) and the four permission tiers (from Chapter 5), with representative tools from across the catalog:

Appendix B --- The “Starter Pack” Recommendation

Across the agent community as of mid-2026, three MCP servers are consistently recommended as the starter pack for any new agentic coding setup, regardless of which LLM provider or which IDE/CLI host is in use:

1. GitHub MCP --- collapses “find that PR, read that file, open that issue” into a single agent ask. The vendor-maintained server (github/github-mcp-server) is the canonical implementation.

2. Context7 --- pulls version-pinned library docs into context so the model writes code against real APIs rather than from training-cutoff memory. Particularly valuable for libraries that have evolved fast.

3. Playwright MCP --- handles real browser actions for QA, scraping, and verification of generated UI changes.

With those three installed, an agent has reasonable coverage of code (GitHub), docs (Context7), and the web (Playwright). The other 50+ MCP servers in this catalog are additions to the starter pack, justified by specific workflows.

Appendix C --- Composition with Skills and Patterns

This catalog is the third volume of the Agentic AI Series, which now runs to nineteen volumes. The first two give the vocabulary for talking about how tools fit into larger systems:

• Patterns of AI Agent Workflows catalogs how LLM calls and tool calls compose in time. A tool by itself does nothing; it’s invoked inside a pattern (prompt-chaining, orchestrator-workers, evaluator-optimizer, autonomous-agent loop). Choose the pattern first; the tool surface follows.

• The Claude Skills Catalog catalogs the SKILL.md-format instruction packs that tell the model when and how to use tools. A skill is the bridge between a workflow (a pattern) and the tools that workflow needs. Many of the entries in this Tools Catalog have a corresponding skill in the Skills Catalog --- critical-code-reviewer uses git and filesystem tools; webapp-testing uses Playwright MCP; describe-design composes filesystem reads with Mermaid output.

Read together, the three catalogs describe agentic AI at three levels of abstraction: the pattern (timing), the skill (instruction), and the tool (primitive). Designing a new agent system involves picking from all three.

Appendix D --- MCP Discovery

Finding MCP servers in mid-2026 is a problem of filtering, not discovery. Community directories list 5,000—15,000+ servers; the practical universe is much smaller. The hubs that matter:

• Official MCP Registry (registry.modelcontextprotocol.io) --- the canonical hub maintained by the protocol community. Indexes verified, production-grade servers and tools.

• modelcontextprotocol/servers on GitHub --- the reference repository (80k+ stars, 9.8k forks). Home to the seven still-active reference implementations (Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time); the README now redirects users to the MCP Registry for browsing third-party servers.

• Smithery AI --- a popular third-party registry designed for one-click discovery, configuration, and install of MCP tools.

• MCPMarket --- aggregator tracking community extensions that mimic Claude Code behaviors, structured memory extensions, and reasoning environments. Has an Anthropic-specific hub at mcpmarket.com/businesses/anthropic.

• Glama (glama.ai/mcp/servers) and PulseMCP (pulsemcp.com) --- daily-updated server directories with usage metrics and trust signals.

• Community “Awesome MCP Servers” lists --- the appcypher and punkpeye GitHub lists are the most actively maintained, with category-by-category indexes.

Three pragmatic rules for navigating the directories. First, prefer vendor-maintained official servers over community forks where one exists (GitHub’s own server beats third-party GitHub wrappers; Sentry’s own beats community forks). Second, half the “official Anthropic MCP server” tutorials still online point at the 13 archived servers --- verify before installing. Third, MCP isn’t free --- each tool definition consumes context, every call costs tokens --- so install fewer servers than you think you need.

Appendix E --- The Catalog’s Omissions

This catalog covers 36 entries across 10 sections. The wider ecosystem is much larger; a non-exhaustive list of what isn’t here:

• Niche or industry-specific MCP servers (legal, medical, scientific, financial, geospatial). The patterns transfer; the inventory is too large to enumerate.

• Framework-specific tool surfaces (LangChain tools, LlamaIndex tools, OpenAI Agents SDK tools) when an equivalent MCP server exists. The recommendation is to build once with MCP and reach the same tool from any framework.

• Closed or proprietary tools that aren’t addressable from a documented schema.

• Tools for content generation that more naturally belong in the Skills Catalog --- image generation, music generation, design tools that ship as skills rather than as bare tool primitives.

• The full Slack/Microsoft Teams/Discord and Outlook/Gmail and JIRA/Linear/Asana/ClickUp and Calendar matrix. The catalog covers one of each shape; the others follow the same template. Slack is listed in Appendix G.

• Cloud-vendor MCPs for cloud platforms other than AWS and Cloudflare (Vercel, Netlify, Fly, Railway, GCP, Azure), and observability servers other than Sentry.

• Memory layers (Mem0, Letta) and vector databases, which the AI Agent Memory Catalog (Volume 6) covers.

• Anthropic’s tool-infrastructure features beyond Tool Search, Advisor and Programmatic Tool Calling (Section J): Tool Runner (SDK), Fine-grained Tool Streaming, Tool Combinations, Parallel Tool Use, and Strict Tool Use beyond its mention in Section J. These are runtime features rather than tools per se. See the platform.claude.com tool infrastructure docs for details.

Appendix F --- A Note on the Moving Target

Anthropic published MCP in November 2024 and the Linux Foundation’s Agentic AI Foundation (AAIF) took over governance in December 2025. Anthropic published the Skills feature in October 2025. The Tool Search tool went live in late 2025; the Advisor tool entered beta in March 2026. The function-calling primitive itself --- tool_use blocks and JSON schemas --- is older than all of these. The catalog’s structure is stable; the specific tool inventory is not. Star counts, version numbers, and the exact set of vendor-maintained MCP servers reflect snapshots from May 2026, with tool versions, package names and server URLs re-checked in October 2026. Treat the catalog as a map of an ecosystem still under rapid construction --- the shape of the landscape will hold even as individual landmarks shift.

The deepest structural fact to internalize: a tool is a name, a JSON schema, and a runtime handler. Everything else --- MCP, skills, patterns, frameworks, products --- is an arrangement of these primitives. Catalog the primitives well, and the larger system becomes navigable.

Appendix G --- Further Reading

Entries that are connector listings rather than patterns, kept here as references:

• Slack MCP server: Slack’s official remote MCP server for reading and posting messages, searching history and listing channels; Streamable HTTP with OAuth, usable from published Slack Marketplace apps or internal apps. The archived Anthropic reference Slack server has a community fork by Zencoder. docs.slack.dev/ai/slack-mcp-server/

--- End of The AI Agent Tools Catalog v0.1 ---