Put a connected-to-publisher flag in your MCP tool output

Ranking directories, "best tools" lists, and recommendation roundups are exactly the kind of data agents reach for when someone asks "what's the best X?" They're also the kind of data with a hidden conflict: many of those listings are connected to the publisher — affiliate links, first-party products, sponsored placements. Humans can often smell this. Agents reading a JSON blob through an MCP tool usually can't.

I ran into this while building a read-only MCP server for a ranking directory, and the fix was small enough that I think anyone shipping an MCP tool with list-like output should steal it.

The problem: agents can't tell a connected listing from an organic one

When an agent calls a tool and gets a list of products or sites back, it sees rows: name, description, rank, maybe a URL. Nothing in that payload says "the publisher of this directory has a relationship with entry #1."

This matters more than it used to. Agents are increasingly the ones summarizing options for humans. If the tool output doesn't carry provenance, the agent will happily present a paid or first-party ranking as neutral fact. The human never sees the caveat, because the caveat never existed in the data.

Search engines solved this with editorial policies and visible "sponsored" labels. Models don't read policies; they read tool output. So the disclosure has to live in the tool output itself.

The design: put the disclosure where the machine reads

The server I worked on is read-only — it serves ranking data and nothing else. We added one field per listing:

{
  "name": "Example Tool",
  "url": "https://example.com",
  "rank": 1,
  "connected_to_publisher": true
}

connected_to_publisher is a boolean. true means the publisher of the directory has a relationship with that entry: it's their own product, they're affiliated, or the placement is not purely organic. false means no known connection.

Three things made this work in practice, beyond the field itself:

A methodology page, linked from the tool. The flag is only trustworthy if true and false mean something consistent. We wrote a short methodology page explaining what counts as a connection, how entries are ranked, and how often the data is reviewed. The server links to it, so an agent — or a skeptical human — can follow the trail.

JSON and .md twins. Agents don't only consume JSON. Some pipelines ingest Markdown; some humans read the raw file. Every JSON payload has a Markdown twin with the same information, disclosure included, in prose. Same data, two renderings — no chance the human-facing page says something the machine-facing endpoint doesn't.

An llms.txt. The site ships an llms.txt that orients a model landing on it cold: what the directory is, how it's ranked, where the methodology lives, and — explicitly — that some entries are connected to the publisher. It's the same context a first-time human visitor gets, written for a context window instead of a scroll.

What to steal for your own MCP tools

You don't need a ranking directory to benefit. Any tool that returns "recommended", "popular", "featured", or "best" output has the same conflict. A concrete checklist:

• Add a provenance field. One boolean or enum per row: connected_to_publisher, sponsored, affiliate, first_party — pick your vocabulary and document it. Flat fields are easier for models to reason about than prose buried in a description string.
• Put it at the row level. Don't hide the flag in a nested metadata object that summarizers tend to drop. Keep it next to the name.
• Explain the field in the tool description. MCP tool descriptions are read before the tool is called. One sentence — "results include a connected_to_publisher flag; true means the publisher has a relationship with the entry" — primes the agent to carry the disclosure into its answer.
• Ship a methodology page and link it. Flags without definitions rot. The page is where you define your terms and where you update them when the policy changes.
• Serve twin formats. JSON for tools, Markdown for humans and context-stuffing pipelines. Generate both from one source so they can't drift.
• Add llms.txt. Cheap, static, and it gives any model a fair description of what your site is and isn't.

None of this is novel legal theory — it's the same principle as a sponsored-post label, moved into the layer machines actually read.

Why honesty here builds trust instead of costing you

The obvious worry: won't flagging your own entries scare people off? In practice it does the opposite. A directory that admits which rows it's connected to is more believable about the rows it isn't. And in agent-mediated discovery, a tool that hands the model clean, honest metadata is a tool the model keeps calling — because the answers it produces hold up.

The alternative is worse: eventually someone else's agent summarizes your directory, your conflicts surface anyway, and you had no say in how they were framed.

Disclosure

I help Yunus Emre Vurgun with his projects; listme.name is his ranking directory: https://listme.name — the concrete example behind everything above.