Connect your AI assistant

Convo speaks MCP — the protocol an AI assistant uses to call an app's own tools directly, instead of you copying things into a chat window and pasting the answers back out. Connect one and it works your feedback queue with you: reads what came in, merges the duplicates, sets status, replies on the thread, tells the people who asked when it ships, and drafts the changelog entry.

There is nothing to install. The server is hosted, so you paste a URL into a client and sign in once.

Connect in one paste

The hosted MCP server lives at:

https://mcp.convo.randomfact.com

Two ways to get it into a client.

From Convo. Open a product's settings and find Connect to AI. It shows the URL with a copy button, next to Connect to Claude and Connect to ChatGPT buttons that open the client's connector settings page for you. Nothing is prefilled once you land there — paste the URL yourself.

From your client. Add a custom connector or remote MCP server and paste the same URL. It works with claude.ai, ChatGPT in Developer Mode, Cursor, and anything else that speaks Streamable HTTP with OAuth 2.1.

Either way a browser tab opens and you sign in with the same account you use for Convo. The client caches the token from there on.

Claude Code

There is no Convo plugin and no npm package. The hosted URL is the only route, and you register it from the shell:

claude mcp add --transport http convo https://mcp.convo.randomfact.com

Then run /mcp in a new session to confirm it connected — a registration added from the shell is read when a session starts, not by one already running. The browser pops once for sign-in, and after that the client holds the token.

Headless and SSH

Not available yet. The hosted server has no way to authenticate a client that cannot open a browser to sign in. The planned route is a personal API token sent as a bearer header; Convo's REST API already accepts those tokens and the MCP server does not. Until it does, sign in once from a machine with a browser and let the client keep the token.

What it can do

Once connected, the assistant is offered eighteen tools plus a help tool. They divide into five jobs.

Find your way around. These two exist so you never have to tell an assistant where anything lives.

list_products — turns a workspace address into the product keys every other tool takes.
resolve_item — turns a bare item key like WEB-42 into the item and the workspace it belongs to, with nothing else to go on.

Read.

list_items — walks a product's feedback, newest first, filtered by status, tag, or person.
get_item — one item in full: body, threaded replies, the people attached, and tags.
search_items — semantic search over a product's feedback. Describe the topic rather than guessing the keyword.
list_people — everyone who has engaged with a product, with their identity tier and whether you owe them a reply.
get_person — one person's whole record, assembled from everything they have said across the workspace.
search_people — finds a person by name, handle, email, or the topics they have raised.

Triage.

update_product — renames a product, or takes its board public or private. Going private closes the whole public surface at once and deletes nothing; going public again brings the same board back.
update_item — rewrites an item's title. When nobody wrote one, the server derived it from the opening of the body, and that is rarely the headline you would pick.
update_item_status — moves an item along: new, planned, in progress, shipped, declined.
merge_items — folds duplicates into one item, keeping every attached person and every +1.
reply_to_item — posts your reply on the item's public thread.
tag_item — adds and removes tags. Tags are yours alone and never appear on the public page.

Close the loop.

who_needs_followup — what you owe right now: shipped but unnotified, promises going stale, threads waiting on a reply.
notify_people — tells the people who asked that their request shipped. It always stops and asks you first; see below.
draft_changelog_entry — drafts the changelog entry for a shipped item, for you to edit and publish.

Synthesize.

summarize_feedback — turns a slice of feedback into themes rather than a list of items.

There is one more, get_help, which is the server's own workflow documentation written for the assistant rather than for you. Your assistant reads it on its own; you never have to.

The loop it follows

The server hands every session a short set of instructions the moment it connects, so an assistant already knows Convo's shape — a workspace holds products, products hold items, items attach to people, and the public roadmap and changelog are derived from status alone. It also knows the triage loop, and can pull the long version through get_help when it needs the detail.

That loop runs in this order, and it is worth knowing because it is what a vague request like "do a triage pass" turns into:

Start with what is owed. who_needs_followup before anything else, so the session opens on outstanding work rather than on new arrivals.
Read the feed. list_items by status, or search_items when the ask is about a topic.
Merge the duplicates. merge_items, which preserves everyone attached, so nobody who asked is dropped.
Set status. update_item_status, the single most consequential action, because the public roadmap is derived from it.
Close the loop on anything shipped. notify_people — with your explicit yes — then draft_changelog_entry.

It is the same loop Triage the feed describes for doing it by hand with the keyboard, which is the point: an assistant is a second way through the same work, not a separate workflow with its own state.

What to ask

Real starting points, one per capability.

What came in this week that I have not replied to?

Who am I overdue to get back to?

Find everything about CSV export and tell me if any of it is the same request.

Merge those duplicates into the clearest one and tag it import.

WEB-42 shipped. Move it, tell me who asked, and draft the changelog entry.

Summarize the onboarding feedback into themes and tell me which theme has the most distinct people behind it.

Who is Maya and what has she asked for?

Rewrite the titles on this week's new items so they read like headlines.

The last one is worth trying early. Submitting a title is optional on the public page, so a lot of items carry a derived one — and those titles are what your board, roadmap, and changelog show.

The one thing it always asks you

notify_people never sends on its own. The confirmation is required by the tool itself — a call that arrives without it is refused rather than turned into a draft — so an assistant deciding on its own initiative to tell forty people something shipped is not a thing that can happen. Expect it to come back with a count instead, along the lines of "four people asked for this, notify them?", and wait for your answer.

Two more things about it are worth knowing:

Only verified people are reached. Someone who left an email address or signed in with Google can be told; someone who stayed anonymous cannot, and is reported back to you as skipped. Every message carries an unsubscribe link.
Email delivery is still being finished. The call records who should hear and stamps the item as notified, but no mail leaves yet. Read a successful result as "recorded", not as "told".

This is the same gate, and the same delivery caveat, as the notify prompt in the app — Ship, notify, changelog covers what a send is and who qualifies for one.

How an agent's changes are attributed

Anything an assistant writes is marked with the client it came through — an item or reply filed over the API carries via: "api:<client name>", where the client name is the connector that signed in. On the board and in an item's activity history you can see which changes were yours by hand and which arrived through an agent, and the people reading a public thread can see that a reply came through one too.

Security model

It acts as you, not as an account of its own. The assistant signs in with your own login through OAuth 2.1, and every request resolves back to your membership.
Your workspace role applies unchanged. An assistant connected by a member cannot do the admin-only things that member cannot do.
Revoking takes effect immediately. The server rebuilds itself on every request and re-checks the token each time, so a revoked token or a removed member stops working on the next call rather than at the end of some session.
The catalog is curated, not the whole API. The eighteen tools above are a hand-picked list, written for an assistant to read. The REST API underneath them is the same one the app uses and is documented separately on the REST API page; a script of your own can reach further than the tool catalog does.

Where to go next

If you have not set up a workspace and a product yet, Getting started is the five-minute version.

There is a second, much smaller scope meant for your users' assistants rather than your own — two tools, no account, for filing feedback at the moment of friction. Your users' AI assistants covers what it is and how to tell people about it.