MCP Server: The Tool List Is the Capability List

An MCP server is a program that exposes a menu of actions — tools — that an AI assistant is allowed to order from. Nothing more mystical than that. Each tool has a name, a description the model reads, and a schema for its inputs. The server sits between the AI client and a real system, executes the calls it receives, and returns results as structured data. It is the entire boundary between the AI and your stuff.

That framing has a useful consequence: the tool list is the capability list. Read it and you know precisely what the AI can do through the server — and, just as important, what it cannot.

How an MCP server works

The Model Context Protocol defines three things a server can expose:

• Tools — actions the model may request: run a query, create a campaign, add a negative keyword. This is where nearly all the value and all the risk live.
• Resources — readable data the client can load as context: files, reports, documents.
• Prompts — pre-written instruction templates the server offers the user.

A call is a round trip. The client sends a tool name plus arguments; the server validates them, executes against the underlying system, and returns the result; the model reads it and continues. The server never initiates anything — no schedule, no background jobs. If nobody asks, nothing runs.

Local or remote — the same server, a different address

A server can run on your machine, launched by the client with credentials in local config files, or on hosted infrastructure, reached as a URL. The protocol is identical; the operational burden is not. Who patches it, who stores the tokens, who can revoke access — those answers differ enough that remote versus local deserves its own entry.

What a Google Ads MCP server's tool list looks like

Concretely: a full Google Ads MCP server runs to around 36 tools. Reads — list_accessible_customers, GAQL queries for spend, search terms, change history. Writes — create search and Performance Max campaigns, ad groups, responsive search ads, keywords and negative keywords, budgets, geo targeting, ad schedules, pause and enable.

What matters just as much is what a careful hosted deployment leaves out. AdCopilot's hosted connector exposes 32 of those 36 tools: the four remove_* tools are never exposed, and any mutate carrying status REMOVED is refused server-side before it reaches Google — in any letter case. Deletion is not gated behind a prompt; the capability is absent. That distinction only exists because a server's tool list is an enforceable boundary, not a suggestion.

How to judge any server in five minutes

The tool list turns vendor evaluation from marketing-reading into an inspection. Five minutes with any MCP server's list answers five questions:

1. What can it read? Enough to be useful — search terms, spend, change history?
2. What can it write? Campaigns and keywords only, or budgets and statuses too?
3. Can it delete? If remove tools are present, ask why. If they are absent, that is architecture doing safety's job.
4. Where do credentials live? In local files you secure, or in hosted custody you can revoke?
5. What gets logged? Every call, or only writes?

An AI managing your account is exactly as capable, and exactly as bounded, as the server you connect it to. Choose the server the way you would set a new hire's permissions on day one — because that is literally what it is. Start with what MCP itself is, then read a live Google Ads server with this checklist in hand.