Every week someone asks us for an integration we don't have yet. Until today that request travelled by email, landed in a Slack thread, and waited for a person to read the vendor's docs and decide whether it was worth a build. We have now wired that whole path into the product.

At the bottom of Settings → MCPs For Cogny there is a new card: Wish for an MCP. It takes one thing — a link to the tool's API documentation, or just the tool's name — and does the research for you.

What happens when you click "Wish for it"

The docs get read. Claude fetches the documentation you linked (or searches for the official one), and works out the base URL, the authentication scheme and the main read endpoints.
The catalog gets checked. If the tool is already one of the integrations Cogny ships, the box tells you so and points you to the card above where you connect it.
A verdict comes back in the same box, usually in under a minute:
- Building it — the tool has a public API you can authorize yourself (an API key, a private token or a service account). A ticket is filed in the shape our coding agent executes, and the agent starts on it immediately: proxy server, credential form, settings card, tests, launch post. The result is a pull request that goes through the same CI and human review as everything else we ship.
- Already on the build list — someone asked before you. You're added to the ticket so you hear about it too.
- Queued for the team — buildable, but a human has to do something first. The usual case is an OAuth-only API, where Cogny must register an app with the vendor before an agent can wrap the endpoints.
- Not right now — no public API, an API locked behind a partner program, or a tool outside the marketing, sales, commerce, analytics and finance work Cogny is built for. The box says which.
The team is told either way, with your email and workspace, so we can circle back when it ships — or explain why it won't.

The research call is on us. Wishes are never metered against your workspace credits, on any tier.

Why the agent, and where the human is

We already let a coding agent fix reported bugs unattended — a triaged bug becomes a pull request without anyone pressing Run. Integrations are the same shape of work: a vendor API, a proxy server that wraps it, a credential form and a settings card. The Litium integration we shipped this week is the reference the agent follows.

The human gate hasn't moved. Nothing merges itself: every run ends in a pull request that needs the automated sanity check, the preview smoke test and a review from us. Wishing for a tool starts the work; it doesn't skip the review.

What to write in the box

Anything that identifies the tool. The grey example text shows the two shapes we handle best:

A docs link: Here are the docs for the Abicart API: https://developer.abicart.se/
Just a name: Voyado

If you know the API needs an API key rather than OAuth, say so — it shortens the research and makes an unattended build more likely.