Your users' AI assistants

Your own assistant gets the full triage surface. Your users' assistants get a different, much smaller one: two tools, no account, meant for the moment a person hits friction in your product and their assistant can file it for them right there.

This page is about that second surface — what it is, how a client asks for it, what it cannot do, and a paragraph you can paste into your own documentation to tell your users about it.

What the public scope is

The same hosted server at https://mcp.convo.randomfact.com serves two different tool lists, and the token a session connects with decides which one it gets. A token carrying the convo.public scope is offered exactly two tools:

• submit_feedback — files a piece of feedback on a product's public board on someone's behalf. An idea, a bug, confusion, a complaint: it all goes in the same box, exactly as it would through the capture box on the page. A title is optional, and a display name can be included if the person offered one.
• get_public_roadmap — reads a product's roadmap exactly as a visitor sees it, grouped into Planned, In progress, and Shipped.

The synthetic get_help tool is there too, so an assistant can read the etiquette for both without you explaining it.

Four things are true of this surface by design:

• No membership. The person on the other end is a user of your product, not a member of your workspace, and nothing here asks them to become one.
• It is aggressively rate-limited and runs the same spam defenses as your public page, because it is the same submission path.
• Agent-filed items are visibly attributed. An item arriving this way is marked as having come through an agent, so you can tell a person's assistant filed it from the person writing it themselves.
• It reads nothing else. No items but the roadmap, no people, no replies, no other person's feedback.

How a board is addressed

Both tools identify a board by the two parts of its public URL, /{workspace}/{KEY}:

• the workspace slug — 5 to 20 lowercase letters, digits, and hyphens, like acme
• the product key — 3 to 5 uppercase letters, like WEB

So a board at convo.randomfact.com/acme/WEB is the slug acme plus the key WEB. There is no separate public identifier to hand out — the address you already share, described on The public page, is the address an assistant uses. It is the same pair the embed widget and the capture endpoint take, so an assistant filing feedback and a form on your own site are pointed at one board by one address; Wire Convo into your product and Build your own capture UI cover those other two routes in.

How a client obtains it

The scope is convo.public, and a client gets it by asking for it on its authorization request when it signs in. Convo cannot hand it out on a client's behalf, so this is entirely a property of how the client is configured.

Two things about that are worth knowing before you point anyone at it, both confirmed against a running server:

• A client cannot register itself for the scope. Convo's OAuth server refuses a dynamic client registration whose metadata names convo.public, with "scope must only contain Authorization Server supported scope values". The scope has to be requested at sign-in instead, by a client that registered without naming it. Once requested that way, the issued token carries it and the session is offered exactly the two tools above.
• A client that does not ask for it gets the maker surface instead. There is no way to end up public-scoped by accident: a token minted without convo.public on the request is treated as a maker token and gets the full catalog, gated by whatever workspace membership the person signing in actually has.

Together those mean the public scope is for a client whose authorization request you control — the assistant built into your own product, or your own integration — rather than something a person configures by pasting a URL into a consumer chat app. Whether any particular client can request a custom scope is a question about that client, not about Convo.

What it cannot do

No status changes, no replies, no people lookups, no notifications, no reading anyone else's feedback. Those belong to the maker surface, and an assistant on the public scope is never offered them.

The scope is a real boundary, not only a tidier tool list. It decides which tools a session is offered, and the API underneath enforces the same two: a token carrying convo.public that reaches for any other operation is refused with a 403 and an insufficient scope error, whatever workspaces the person who signed in happens to belong to. So if you are the maker and you connect a client on the public scope, you get the two public tools and nothing else — your own membership does not widen it back out. A token minted without the scope is the maker surface, gated as always by the live membership of whoever signed in.

Telling your users

Nothing about this is discoverable on your public page, so if you want people to use it you have to say so. Something like this, adjusted to your own board:

Filing feedback from your AI assistant. If your assistant supports MCP, you can point it at our feedback board and have it file things for you without leaving what you are doing. The server is https://mcp.convo.randomfact.com and our board is acme/WEB. Ask it to submit feedback for you, or to check what is already planned before you write something up — it can read our roadmap too.

Two things are worth saying alongside it. First, that anything filed this way lands on the public board under their name or as Anonymous, exactly like the web form — it is not a private support channel. Second, that asking their assistant to check the roadmap first is genuinely useful: if a thing is already Planned, adding a +1 to it says more than a second copy of the same request.

Where to go next

• Connect your AI assistant — the other side of the same server: your own assistant, the full triage surface, and the loop it follows.
• Getting started — creating the workspace and product whose address the two tools above take.