What Is an MCP Server? A Plain-English Guide to Model Context Protocol

The problem MCP solves

Before MCP, giving an AI assistant access to a real system meant a custom integration: a bespoke plugin, a bot framework, or a one-off API wrapper built specifically for that one assistant. Every new tool and every new assistant meant rebuilding the connection from scratch.

Model Context Protocol (MCP) is Anthropic's open standard that replaces all of those one-off integrations with a single, consistent way for an AI assistant to discover and call external tools. Build one MCP server, and any MCP-compatible client — Claude, Claude Code, or others — can use it without custom glue code.

How it actually works

An MCP server exposes a set of "tools" — named functions with a description and a defined set of parameters. When you talk to an MCP-connected assistant, it reads the available tools, matches your request to the right one, calls it with the right parameters, and gets a structured result back.

That result becomes part of the conversation, so the assistant can reason about it, summarize it, or chain it into a follow-up action — all without you leaving the chat window.

• You ask a question or give an instruction in plain language
• The assistant matches it to one or more available tools
• The MCP server executes the underlying action — usually an API call to a real system
• The result returns to the same conversation for the assistant to use next

Why this matters for marketing specifically

Ad platforms have had APIs for years, but APIs require code. MCP turns "I have an API" into "any AI assistant can use this through natural language," without engineering work on the user's side.

That is the gap MCP Ads fills: a single remote MCP server that exposes Google Ads, Meta Ads, LinkedIn Ads, TikTok Ads, GA4, and Search Console as tools Claude can call directly — reporting, audits, and scoped campaign actions, all from one conversation.

Read vs. write, and why that distinction matters

Not every MCP tool changes something. Most marketing-relevant tools are read-only: pulling a report, checking account structure, reviewing change history. A smaller set can write — creating a campaign, adding a keyword, adjusting a budget — and a well-built MCP server only takes those actions when explicitly asked.

This is also why MCP servers vary a lot in trustworthiness. The protocol defines how tools are called; it does not guarantee what a specific server is allowed to do with your accounts. That is a product decision each MCP server makes for itself.

A worked example: one question, end to end

The abstract description makes more sense with a concrete trace. Suppose Claude is connected to MCP Ads and you type: "What did we spend on Google Ads last week, and which campaign had the worst cost per conversion?"

First, the client (Claude) already holds the list of tools the server advertised when it connected, each with a name, a one-paragraph description, and a schema of the parameters it accepts. Claude reads your sentence, decides it needs campaign-level performance for a date range, and picks google_ads_campaign_performance. It fills in the parameters — a start date and end date covering last week — and sends a tool call to the server. It does not write code and you do not see JSON; the call is a structured message that the protocol defines.

Second, the MCP Ads server receives the call, checks that the OAuth token you granted covers that account, calls the Google Ads API on your behalf, and returns a structured result: one row per campaign with spend, clicks, conversions, and cost per conversion. That result is delivered back to Claude as a tool result — a message in the conversation that you can usually expand and inspect in the client.

Third, Claude reasons over the result exactly as it would over text you pasted in. It adds up the spend, finds the campaign with the highest cost per conversion, and writes the answer. If you follow up with "why is that one so expensive," it chooses a different tool — google_ads_search_terms for the queries triggering the ads, or google_ads_change_history to see whether someone changed the bid strategy — and the loop repeats. Every step of that chain is an ordinary tool call; the protocol is what makes the second and third calls as easy as the first.

The vocabulary you will actually run into

MCP documentation uses a handful of terms that are worth knowing because they show up in setup screens and error messages. None of them are complicated.

• Host and client: the application you are talking to (the Claude app, Claude Code, Cursor, and so on). The host runs an MCP client that speaks the protocol to each server.
• Server: the program that exposes tools. MCP Ads is one server; a filesystem server or a database server is another. A single client can connect to many servers at once.
• Tool: a named function with a description and a parameter schema. The description is what the model reads to decide whether the tool fits your request, which is why good tool descriptions matter more than they sound.
• Resource and prompt: two other things a server can expose besides tools — read-only documents the model can pull in, and pre-written prompt templates. Marketing servers lean almost entirely on tools.
• Transport: how client and server talk. A local server runs as a process on your machine over standard input and output; a remote server like MCP Ads is reached over HTTPS, which is why you connect it with a URL rather than an install.
• Dispatcher: a pattern some servers use when they have hundreds of tools. Rather than listing all of them, the server exposes one tool per platform — google_ads_action, meta_ads_action, ga4_action — with a list_actions helper to search the underlying actions by keyword. This keeps the model's context small while leaving the full surface reachable.

Connecting an MCP server, step by step

The mechanics differ slightly per client, but the shape is the same everywhere, and for a remote server it is short. The full per-client instructions live in the quickstart; this is the outline so you know what to expect.

• Step 1 — Get the server URL. For a remote server this is a single HTTPS address. For a local server it is a command to run instead.
• Step 2 — Add it to your client. In the Claude app this is the connectors or integrations screen; in Claude Code it is one `claude mcp add` command; in Cursor or Windsurf it is a line in the mcp.json file. See the how it works page for what happens under the hood.
• Step 3 — Authorize. The client opens a browser window and the server asks you to sign in to the accounts it should be allowed to reach. With MCP Ads that is a standard Google or Meta OAuth screen, and the token stays with the server, not in your chat client.
• Step 4 — Verify. Ask a small read-only question ("list the ad accounts I have access to") and check that the answer is your data. That single prompt confirms the connection, the authorization, and the tool discovery all at once.
• Step 5 — Scope. Decide which accounts the server can see and whether you want write tools available at all. A good server lets you make that choice; the protocol itself leaves it to the server.

Limits and misconceptions

Because MCP is new and the name sounds technical, a few wrong assumptions circulate about it. Clearing them up early saves confusion later.

• MCP does not make the model smarter. It gives the model access to data and actions. The reasoning about what a result means is still the model's job, and a bad question still gets a mediocre answer.
• MCP does not run continuously. A tool is called when the model decides to call it during a turn of the conversation. For scheduled work — a Monday report, a daily budget check — you need something on top, such as a routine in the client or a bot that opens the conversation for you; see the Grok Bot pattern for one example.
• MCP does not define permissions. Whether a server can change a budget, and whether it asks first, is the server's design. Read the server's documentation before connecting it to anything that spends money.
• The model can pick the wrong tool. With hundreds of tools available, a vague request can route to a nearly-right one. Naming the platform and the date range in your question removes most of that ambiguity.
• Results have size limits. A tool result that returns ten thousand rows will be truncated or summarized. Ask for the top N, a date range, or a specific breakdown rather than "everything."
• One connection per client. Connecting MCP Ads in the Claude app does not connect it in Cursor; each client keeps its own server list, although the server-side authorization is shared.

Bottom line

MCP is infrastructure, not a feature. It is the reason an assistant like Claude can go from "writing about your campaigns" to "working inside your campaigns" — and it is why that capability does not have to be rebuilt separately for every new AI client that adopts the standard.