When an agent working in Cogny hit a wall, the request used to travel the long way round. The agent told you a tool was missing, you opened Discord or your inbox, retyped what you wanted, and someone at Cogny read it and worked out which tool you meant. By then the agent's context was gone: the tool it tried, the error it got, the call that came closest.

Now the agent files it itself. The Cogny MCP server has three new tools.

TL;DR

report_bug: a Cogny tool errored, returned data that's clearly wrong, or didn't do what its description says. The agent attaches the tool name and the raw error. Clearly scoped bugs are fixed by Cogny's coding agent and ship after a human reviews the change.
request_feature: something Cogny can't do yet. Usually that's a tool missing from an integration you already use ("add keywords to a shared negative keyword list in Google Ads"). It also covers a platform Cogny doesn't connect to yet.
contact_support: a message to a person on the Cogny team, for billing, account questions or anything that isn't a bug or a missing feature. It works even if the workspace has no active subscription.
Bug reports, support messages and requests for a tool on an existing integration return a reference. The answer arrives in the Cogny app (the life-buoy icon in the header), with an email if it's unread after a day. A request for a new platform usually gets its verdict back in the same call, within a minute.
A workspace can file up to 10 requests per 24 hours.

What happens to a feature request

Where a request goes depends on what it's about.

A missing tool on an integration you already use. This is the most common case: Google Ads can attach a shared negative keyword list to a campaign, but you want to add keywords to the list itself. Within about 30 minutes the request is checked three ways:

Against the tools that already exist. Agents sometimes miss a tool. If one already does the job, the request closes and the reply names the tool.
Against open requests. If someone already asked for the same thing, you're added to that request rather than starting a second one.
Against the platform's own API documentation. If the platform's public API supports it with the access your connection already has, Cogny's coding agent writes the new tool and its tests. A person reviews the change before it ships.

Sometimes the API doesn't support a request, or it would need new permissions that every customer would have to re-approve. When that happens, the reply says exactly what blocks it, or a person on the team picks it up.

A platform Cogny doesn't connect to yet. The request goes through the same process as Wish for an MCP. Cogny reads the platform's API docs. If customers can authorize it on their own, a coding agent starts building the integration. Your agent usually gets the verdict back in the same call.

Something about Cogny itself, like reports, tickets or the dashboard, goes to a person on the team.

When a new tool ships, your agent won't see it until it reloads Cogny's tool list. Start a new chat, or reconnect the Cogny connector (Claude: Settings → Connectors; Claude Code: /mcp).

Why the agent files it, not you

The agent has the details that make a request useful: the exact tool it called, the arguments, the raw error, and the closest tool that fell short. When you retype a request by hand, most of that gets lost.

The agent knows when to use these tools. Every workspace's connector instructions say to file the request directly instead of sending you to support, and the cogny_status summary mentions them too. You don't need to tell the agent about them. Ask for what you want, and if Cogny can't do it yet, the agent files the request.

Try it

Connect Cogny to your MCP client at https://app.cogny.com/mcp (see the MCP docs), then ask your agent for something your connected platforms can do but Cogny's tools don't cover yet. If you're not sure a tool exists, ask anyway. If it does, the reply tells you which one to use.