# The MCP Playbook for News Media

### How to get discovered, recommended, and paid inside AI assistants like Claude, ChatGPT, and Gemini

---

## 1. The Core Idea

AI assistants — not publishers — now own the interface. When a reader asks Claude or ChatGPT "what's the best robot vacuum for pet hair" or "which savings account has the best rate right now," the assistant decides how to answer. A banner ad, a homepage takeover, or a pop-up simply has nowhere to go.

But every assistant still needs a trustworthy source to pull the answer from. That's the opening. **Your MCP (Model Context Protocol) server isn't a website with ad slots — it's a structured knowledge graph that AI assistants query for trusted answers.** Vendors and advertisers don't pay for screen space anymore; they pay to be *discoverable* and *recommended* inside a trusted editorial system.

Think of it less like display advertising and more like a Bloomberg Terminal or a Gartner Magic Quadrant, but built by your newsroom, for your beat, and served directly into the AI tools your readers already use.

This applies to any outlet with real topical authority — tech, personal finance, health, travel, parenting, home, food, local services — not just niche industry newsletters.

---

## 2. All Monetization Models, Ranked

| # | Model | Strength | What it is |
|---|-------|----------|------------|
| 1 | **Sponsored Recommendations** | ★★★★★ | A vendor pays to appear in relevant query results, clearly labeled "Sponsored." |
| 2 | **"Editor's Choice" / Newsroom's Choice** | ★★★★★ | Your own editorial pick, unpaid — the trust anchor that makes everything else credible. |
| 3 | **Premium Knowledge & Reports** | ★★★★★ | Deep guides, datasets, and comparisons available only to subscribers or licensees. |
| 4 | **Related Resources & Guides** | ★★★★☆ | Links to your own how-tos and explainers surfaced alongside a recommendation. |
| 5 | **Marketplace Listings** | ★★★★☆ | A structured directory of vendors in a category (e.g. "meal kit services") that vendors pay a fee to be listed in. |
| 6 | **Featured Resources** | ★★★★☆ | A paid boost to the top of a results list, distinct from full "Sponsored" tagging. |
| 7 | **Affiliate Recommendations** | ★★★★☆ | Commission-based links baked into the same recommendation objects. |
| 8 | **Sponsored Topic/Category Ownership** | ★★★☆☆ | A vendor sponsors an entire category (e.g. "Travel Insurance") across all queries in it. |
| 9 | **Events, Webinars & Training** | ★★★☆☆ | Paid promotion of a vendor's event surfaced when relevant. |
| 10 | **"Did You Know?" Editorial Insights** | ★★☆☆☆ | Light-touch sponsored trivia/insight blocks — low value, easy to ignore. |
| 11 | **Forced Promotional Messages** | ★☆☆☆☆ | Injecting ad copy into the main answer body. Doesn't work. A separate `mcp_integrations` footer with clear disclosure works better — still not guaranteed. |

**Rule of thumb:** the models near the top work *because* they respect editorial trust and the assistant's own presentation logic. The ones near the bottom fail because they try to force something the AI client will simply strip out or ignore.

---

## 3. What an Advertiser Must Provide

Vendors don't submit ad creative — they submit structured facts your editorial team can verify and publish. A standard vendor submission should include:

- Company name
- Product / service name
- Plain-language description
- Newsroom-relevant use cases (why would *your readers* care)
- Industries or audiences served
- Pricing (even a range)
- Supported countries / languages
- Integrations or API availability
- Documentation link
- Trial or demo availability
- Logo and screenshots
- Canonical website URL
- Editorial disclosure agreement (they accept being labeled "Sponsored")
- Update commitment (who keeps the listing current)
- Tags and categories

If a vendor can't provide most of this, they're not ready to be part of the graph.

---

## 4. What the News Media Must Do

Being included isn't automatic — your newsroom is the trust layer that makes the whole system worth paying for. Your responsibilities:

1. **Verify vendor claims** before publishing anything about them.
2. **Write neutral, editorial-voice summaries** — no vendor marketing copy, even for paying sponsors.
3. **Classify and tag** each entry consistently (category, subcategory, use case).
4. **Assign editorial badges** ("Editor's Choice," "Best for Beginners," "Sponsored," etc.) based on real criteria you can defend.
5. **Clearly mark sponsored content** as sponsored — in the data itself, not just visually.
6. **Maintain one canonical URL** per entry so the AI assistant always links back to your site.
7. **Keep records updated** — pricing and availability go stale fast; stale data breaks trust fastest.
8. **Expose it all through structured MCP tools** the AI assistant can actually query (not just a webpage to scrape).

---

## 5. The Knowledge Graph Object

Every recommendable "thing" in your system — a product, a service, a vendor, a guide — should be stored as one consistent object:

```json
{
  "title": "string",
  "summary": "string (neutral, editorial voice)",
  "canonical_url": "string",
  "category": "string",
  "tags": ["string"],
  "provider": "string",
  "editorial_badges": ["Editor's Choice" | "Sponsored" | "Best Value" | "..."],
  "sponsored": true,
  "related": ["canonical_url", "canonical_url"],
  "pricing": "string or range",
  "last_updated": "YYYY-MM-DD",
  "source": "string (which desk/team verified this)"
}
```

This is the atomic unit your MCP server serves up. Everything — search results, editorial picks, sponsored slots, premium content — is just a filtered view over a collection of these objects.

---

## 6. What This Looks Like in an AI Assistant's Response

Below are two examples showing how a general-interest news outlet — not a niche trade publication — could structure a response. The assistant (Claude, ChatGPT, etc.) receives this structured payload and decides how to phrase it for the reader.

### Example A — Consumer tech desk: "best robot vacuums for pet hair"

```json
{
  "query": "best robot vacuum for pet hair 2026",
  "results": [
    { "name": "Roborock Qrevo Curv", "category": "robot_vacuum",
      "canonical_url": "https://example-news.com/reviews/roborock-qrevo-curv" },
    { "name": "iRobot Roomba Combo 10 Max", "category": "robot_vacuum",
      "canonical_url": "https://example-news.com/reviews/roomba-combo-10-max" },
    { "name": "Eufy X10 Pro Omni", "category": "robot_vacuum",
      "canonical_url": "https://example-news.com/reviews/eufy-x10-pro-omni" }
  ],
  "editorial_choice": {
    "name": "Roborock Qrevo Curv",
    "badge": "Editor's Choice",
    "reason": "Best pet-hair pickup and self-emptying reliability in our 2026 lab tests"
  },
  "sponsored": [
    { "name": "Shark PowerDetect Pro", "badge": "Sponsored",
      "canonical_url": "https://example-news.com/reviews/shark-powerdetect-pro" }
  ],
  "premium_resources": [
    { "title": "Full Robot Vacuum Buying Guide 2026", "access": "subscribers_only",
      "canonical_url": "https://example-news.com/guides/robot-vacuum-buying-guide" }
  ],
  "related_guides": [
    { "title": "How to clean a robot vacuum's brush roll",
      "canonical_url": "https://example-news.com/how-to/clean-robot-vacuum-brush-roll" }
  ],
  "last_updated": "2026-06-01"
}
```

**What the reader sees in Claude/ChatGPT:** a short, natural-language answer naming the top pick with the reason why, a disclosed sponsored mention, and a link to the full guide — all attributed back to your outlet by name and URL.

### Example B — Personal finance desk: "best high-yield savings accounts"

```json
{
  "query": "best high-yield savings account July 2026",
  "results": [
    { "name": "Ally Bank Online Savings", "category": "savings_account" },
    { "name": "Marcus by Goldman Sachs", "category": "savings_account" },
    { "name": "SoFi Checking & Savings", "category": "savings_account" }
  ],
  "editorial_choice": {
    "name": "Ally Bank Online Savings",
    "badge": "Editor's Choice",
    "reason": "No minimum balance, consistently competitive APY, best-in-class app"
  },
  "sponsored": [
    { "name": "SoFi Checking & Savings", "badge": "Sponsored" }
  ],
  "premium_resources": [
    { "title": "2026 Savings Account Rate Tracker (updated weekly)", "access": "subscribers_only" }
  ],
  "related_guides": [
    { "title": "High-yield savings vs. money market accounts: what's the difference" }
  ],
  "last_updated": "2026-07-01"
}
```

Same structure, completely different beat — that's the point. Any desk with real expertise (travel, parenting, home improvement, health) can populate this same schema.

---

## 7. Revenue Models

- **Flat sponsorships** — fixed fee per category, per period
- **Featured placement fees** — pay to rank higher within honest results
- **Affiliate commissions** — pay-per-conversion on top of listings
- **Premium subscriptions** — deeper guides/data gated to paying readers or enterprise licensees
- **Marketplace commissions** — a cut of transactions initiated through your directory
- **Sponsored editorial collections** — a vendor underwrites a themed guide (still editorially controlled)
- **Lead generation** — vendors pay for qualified inquiries surfaced through the assistant
- **Enterprise licensing** — other companies license your structured graph via API/MCP

Most outlets will end up blending 2–3 of these rather than picking one.

---

## 8. When Does the Integration Actually Get Triggered?

This is the question every outlet asks before investing in an MCP: *does a reader need to open our MCP specifically, or does it just fire whenever someone asks a relevant general question?* Based on how Claude and ChatGPT currently work, there are three distinct states — and only one of them is automatic.

**State 1 — Not connected at all.**
Your MCP sits in the platform's public directory, but the reader has never added it. The assistant will **not** silently query it just because a question is relevant. Instead, when the platform's own systems judge your MCP relevant to what the user is asking, it can surface it as a **suggested connector** — a one-tap "would you like to connect X?" card. Nothing is queried until the reader accepts. This is true for both Claude's Connectors Directory and ChatGPT's Apps Directory.

**State 2 — Connected, question is general.**
Once a reader has added your MCP, the assistant *will* call it implicitly for a matching general question, without the reader naming it — the same way a connected calendar gets checked for "what's on my day" without the user saying "check my calendar." So: general question + your MCP already connected = it fires automatically, based on how well your tool descriptions match the query.

**State 3 — Named directly.**
The reader (or a colleague who knows your outlet) types your MCP's name directly — e.g. "ask [Your Outlet] MCP which transcription tool is best." This works whether or not it was used earlier in the session, and bypasses any suggestion step.

**What this means for any outlet building one of these:**

- Getting *discovered* by new readers depends on States 1→2: how well your submitted tool names and descriptions match real query phrasing. This is effectively **SEO for AI discovery** — the categories, tags, and tool descriptions you write when you submit the connector are what the assistant matches against.
- Getting *repeat, automatic use* depends on conversion from State 1 to State 2 — i.e., getting readers to actually connect it once. After that, it behaves like an always-on tool for that reader.
- Brand recognition still matters a lot, because State 3 (naming it directly) is the only path that skips discovery mechanics entirely.
- This is evolving quickly and differs slightly by platform (Claude, ChatGPT, Gemini) and by deployment (public consumer chat vs. an enterprise-licensed integration you build directly into a client's own AI agent, where the client can choose to make it always-on with no suggestion step at all). Re-check each platform's current developer documentation before finalizing a go-to-market plan, since these mechanics are still being refined.

---

## 9. Measuring How Often an Integration Was Shown

This is the harder question, and it's worth being direct about the limits: **there is currently no cross-platform "impression count" that any AI vendor exposes to third-party tool providers** — not Anthropic, not OpenAI. What you *can* measure differs by layer.

### What you can measure directly (server-side — you own this)

Every time an AI assistant calls your MCP, that request hits your own server. Log it:

- Timestamp, tool/endpoint called, query text
- Which specific objects (vendors, sponsored entries) were included in the response you sent back
- Category/segment of the query

This gives you an exact, auditable **"Served Count"** — how many times a given vendor's listing was actually included in a response handed to the assistant. On AI For Newsroom we also log every tool call in `mcp_tool_analytics` and integration attaches in `mcp_integration_impressions`, with per-integration served counts in Admin → MCP Integrations.

### An important boundary: two separate layers of "visibility"

It's worth being precise about what can and can't be paid for, because it changes how you pitch this to advertisers:

| Layer | Who controls it | Can it be monetized? |
|---|---|---|
| Whether your MCP is listed in the directory and gets suggested to a given user | The AI platform (e.g., Anthropic) | **No.** Anthropic states directory inclusion is free, never pay-to-play, with no preferred-connector designation and no co-selling of partner data. This is a level playing field by policy. |
| What your MCP *server itself returns* once it's called — editorial picks, sponsored entries, badges, ranking within your own results | **You — the newsroom** | **Yes.** This is the entire monetizable surface described in this playbook. |

In short: you can't buy better placement in Claude's or ChatGPT's directory. You *can* build and sell placement inside your own knowledge graph, which is what gets served the moment your MCP is called. Make this distinction explicit when pitching advertisers or explaining the model to newsroom leadership — it heads off the "can't we just pay Anthropic directly?" question before it comes up.

### The real gap: "served" vs. "actually shown to the reader"

Your server can prove an item was *available* to the assistant. It cannot prove the assistant actually *mentioned* it in the final answer — the model may include 1 of 5 results and drop the rest. This is a genuinely new measurement problem that doesn't exist in traditional web advertising (where a page load guarantees an impression). Two practical ways to close the gap:

1. **Canonical URL click-through tracking.** Every object links back to a canonical URL on your site. Tag each one with a unique parameter (source, tool-call ID, vendor ID) so that when a reader actually clicks through from the assistant's answer, you can attribute that visit to a specific served item. This measures a real outcome, not a guess — and it's the number advertisers should ultimately value more than a raw impression anyway.
2. **Periodic manual sampling.** Run a representative batch of real queries against Claude and ChatGPT yourself (with your MCP connected) on a regular schedule, and record how often a sponsored or featured item actually appears in the final answer versus how often it was merely included in the served payload. Turn this into a benchmark ratio (e.g., "top-3 served items are mentioned in the final answer ~60–70% of the time") that you can share transparently with advertisers as an estimate, clearly labeled as such.

### Recommended metric to sell against

Rather than promising "impressions" — a number nobody in this ecosystem can currently guarantee — sell and report on two honest, auditable numbers:

- **Served Count** (from your own logs): how many times the item was included in a response.
- **Click-Through Count** (from canonical URL tagging): how many times that led to an actual visit.

This is more defensible than an unverifiable impression claim, and it happens to align with what performance-minded advertisers actually want to pay for.

---

## 10. Non-Negotiable Trust Rules

1. Always disclose sponsorships — in the data, not just the UI.
2. Keep editorial judgment separate from paid placement.
3. Never hide or obscure sponsored status.
4. Only surface recommendations that are actually relevant to the query.
5. Publish your ranking criteria — vagueness here is what kills trust fastest.

Break these and the whole model collapses: assistants and readers alike stop trusting your graph, and vendors stop paying for access to something no one trusts.

---

## 11. Getting Started (First 30 Days)

1. Pick one beat where your newsroom already has real review/comparison expertise.
2. Convert your existing content for that beat into the knowledge graph object format above.
3. Define 3–5 editorial badges you can defend with real criteria.
4. Build (or contract) a minimal MCP server that exposes search + recommendation tools over that data.
5. Draft a one-page vendor brief listing exactly what you need from advertisers (Section 3).
6. Pilot with 3–5 vendors in that one category before expanding to others.

---

## 12. How We Do It at AI For Newsroom (Live MCP)

Our production MCP at **aifornewsroom.in** implements two layers in every search response:

1. **Editorial results with source URLs** — `results[]` with `urls{}`, `sources[]`, `citation_markdown`, and top-level `sources_markdown`. Server instructions tell Claude/ChatGPT to end with a **Sources** section.
2. **Footer integrations** — `mcp_integrations[]` appended server-side for promos or future sponsor CTAs. This is **not** sponsored rows inside `results` (model #1 in the ranked list — still on our roadmap).

### How footer injection works

1. A `search_*` tool returns editorial JSON.
2. `finalizeMcpToolResponse` tags links with GA4 UTMs (`utm_medium=mcp`) and `attachIntegrationsToMcpResult` appends matching integrations.
3. Rules in **Admin → MCP Integrations**: `trigger_tools` (empty = all tools except `ping`), `show_when` (`always` / `has_results` / `empty_only`), `priority`.
4. The payload includes `footer_markdown`, `must_include_in_response: true`, `mcp_footer_required: true`, and a strengthened `client_directive`.
5. We log **Served Count** in `mcp_integration_impressions` and `appearances_count` — not guaranteed display in the final answer.

### What MCP cannot force

- Render UI in the chat client — only JSON + instructions.
- Guarantee the model shows the footer or every source link.
- Replace in-result sponsored recommendations (not shipped yet).

**Practical takeaway:** treat footer integrations like disclosed email footers — separate from the main answer, measure served + GA4 clicks (`utm_content=integration-{slug}`), and periodically sample real Claude/ChatGPT answers.

Our first live integration is the **weekly newsletter** signup (model #4 — Related Resources). Admins can add more integrations without redeploying.
