Skip to main content
Assistants and agents increasingly ask a company’s own MCP server before they guess. The brand MCP server is that server for your brand. It holds no credentials and can write nothing. Every answer comes from your product feed, so it says exactly what the feed says: the facts you confirmed and marked public, and nothing else.

​
Address

{slug} is your product feed’s slug. The transport is streamable HTTP, and no key or sign-in is needed. An unknown slug answers 404. If you turn your feed off, the address answers 410 within a minute, and serves nothing it served before. Turning it back on is picked up within a minute too. Each client IP has a rate limit; past it, the server answers 429 with Retry-After. This is a separate server from the Attensira MCP server you use to run your own workspace. It shares no credentials with it and never reads your workspace, only your published feed.

​
Tools

Every tool is read-only, and is marked so for clients (readOnlyHint, not destructive, idempotent). No tool writes anything. The resource brand://{slug}/facts is the whole feed, exactly as it was published. Every answer carries a source: the feed’s address, its version and updated_at, and the fact_ids of the Brand Book facts it came from.

​
Freshness

The server reads your feed at most once a minute per brand. See how fast an edit reaches the feed.

​
How agents find it

Two files on your own site point agents at the server. Each is filed as a change to your site, the same way a page fix is: a pull request to your connected GitHub repository, and your approval settings for your own site decide whether to open now, open after the veto window, or hold for your yes. Closing or reverting the pull request undoes it.
  • /.well-known/mcp.json: a small card naming the server’s address, its transport (streamable HTTP), that it needs no sign-in, and where your product feed and llms.txt are. It lists no tools, so it never goes stale when your Brand Book changes.
  • One line in your llms.txt: a ## MCP section with a link to the server. Nothing else in the file is changed. If your site has no llms.txt, a short one is created.
Both files go where your site serves its root from: the repository root, public/ or static/, wherever your llms.txt or robots.txt already lives. If a file already says what it would say, nothing is filed. Your product feed must be on: a pointer to a server that answers 404 is worse than none. .well-known/mcp.json is the only file under a dot-directory we ever write. If your site already serves a /.well-known/mcp.json that we did not write, we leave it alone at every approval level: it comes back as conflict, with a reason, and nothing is filed for it. Add the server’s address to your own file if you want agents to find it there too. The llms.txt line is still filed, because it only adds to that file. A mcp.json we wrote earlier is updated when its card changes, for example after you rename the brand. Ask for both files with POST /v1/agent-readiness/brand-mcp/discovery (body {repo?, dir?}, the steer scope). Each file in the answer has an outcome: proposed (with the change’s id), unchanged, finding_only (at your approval level for your own site we only report it, and nothing is filed) or conflict. During a trial the files are proposed as on a paid plan: they are drafts in your Inbox, and the pull request opens on your yes.

​
The MCP registry

We do not list your server in the public MCP registry for you. The registry removes mass-created servers as spam, and one copy of the same server per brand under our name is exactly that. Instead you get a ready server.json named in your own domain’s namespace (for acme.com, com.acme/brand), pointing at your server’s address. Publish it with the registry’s mcp-publisher after proving your domain (mcp-publisher login dns or http). Get it from GET /v1/agent-readiness/brand-mcp/registry-entry (?domain=, your workspace’s domain by default). Its published is always false, because the entry is yours to publish.

​
What agents ask

analyze(view=brand_mcp_queries) (over REST, GET /v1/views/brand_mcp_queries) shows what agents asked your server over the last 1 to 90 days (30 by default; a longer window is cut to 90):
  • total calls, and counts by_tool and by_client.
  • top_questions: the questions asked most, grouped regardless of case, spacing and closing punctuation, each with its count, how many different clients asked it, and last_asked_at. limit sets how many (1 to 50, 10 by default).
  • A question’s text is shown only once it was asked at least twice (min_count). Questions asked once are counted in unshown, never printed, so a one-off question that named a person stays out of the view.
Queries are kept for 90 days. Turning your feed off stops new queries being counted.

​
What is logged

For each tool call we keep your slug, the tool, the client’s product name (the first word of its User-Agent, for example Claude-User, and only when it looks like a product name) and the text of the tool’s own parameters. Email addresses and phone numbers are removed from that text, and it is cut to 200 characters. Arguments a tool does not take are not kept, their names included. We never keep the IP address or any other header. When we file the call under your workspace, we remove email addresses and phone numbers again, along with the query string and fragment of any link in the text.