Add an MCP tool so an agent can file a bug report to AgentsRoom support

Today, when an agent running inside AgentsRoom finds a bug in AgentsRoom itself, it has no supported way to report it. I asked my agent to file the restore-state bug and it had to reverse-engineer the public-backlog page and POST to /api/public-backlog/<slug>/tickets by hand, because the AgentsRoom-MCP server exposes backlog_, memory_, skills_, prompts_, commands_, settings_, agents_, teams_, ssh_, db_, ideas_* ... and nothing at all pointing at AgentsRoom's own support. backlog_create only writes to MY board, which the AgentsRoom team never sees.

WHAT I WOULD LIKE An MCP tool on the AgentsRoom-MCP server, e.g. report_issue({ type: "bug"|"feature"|"question", title, description, details?, impact?, email?, includeDiagnostics? }), that files into the same public backlog as the in-app "Bug or feedback" button, and returns the ticket id and its public URL.

WHY IT MATTERS MORE HERE THAN ELSEWHERE Agents are the ones who actually see these bugs: they can read ~/.agentsroom, diff timestamps, inspect the bundle, and produce a repro with numbers instead of "it doesn't work". Right now that quality of report only reaches you if the user retypes it into a form. With includeDiagnostics the tool could attach app version, OS, the relevant setting values and the last log lines automatically, so you get complete reports instead of one-liners.

Guardrails I would expect, mirroring the rest of the server: the tool only fires when the user explicitly asks for it, one ticket per call, no bulk, and the exact text is shown to the user before it is sent.

Problem to solve

An agent that finds a bug in AgentsRoom has no supported channel to report it: backlog_create writes to the user's own board, and there is no feedback/report tool on the AgentsRoom-MCP server. The agent has to reverse-engineer the public-backlog HTTP API to file anything.

Proposed behavior

report_issue({ type: bug|feature|question, title, description, details?, impact?, email?, includeDiagnostics? }) on the AgentsRoom-MCP server, filing into the same public backlog as the in-app "Bug or feedback" button and returning the ticket id and public URL. Same etiquette as the other write tools: explicit user request only, one ticket per call, text surfaced to the user first.

Who benefits

Every AgentsRoom user running agents, and the AgentsRoom team: reports arrive with version, OS, settings and log excerpts already attached instead of "it doesn't work".

Acceptance criteria

From an agent session I can say "report this to AgentsRoom" and get back a ticket id and URL, without the agent hand-rolling an HTTP call to an undocumented endpoint.

[Product Manager @ 2026-09-02T06:53:53.435Z]

Cadrage PM (proposition P8 du rapport, en attente depuis 2 runs, validée le 2026-09-02)

Le problème, en une phrase

Un agent qui tourne DANS AgentsRoom et qui trouve un bug D'AgentsRoom n'a aucun canal pour nous le dire.

Preuve

Idée 1cb29027, rapportée par [email protected]. Cette personne a déjà obtenu une livraison (le mode vocal barge-in, v1.154.0) et ses signalements sont longs mais très étayés : elle contourne les manques en écrivant elle-même le remplacement avant de nous en parler. Ici, son agent a dû deviner l'adresse de notre formulaire public de retour et l'appeler à la main.

Une seule personne l'a demandé, mais l'intérêt est d'abord pour nous.

Pourquoi ça nous sert directement

Nos rapports de bug arrivent aujourd'hui par le bouton « Bug ou retour », remplis par un humain qui écrit souvent « ça marche pas ». Un agent, lui, connaît déjà le contexte exact : la version de l'app, l'OS, le CLI utilisé, l'appel d'outil qui a échoué et son message d'erreur. Un rapport déposé par un agent arriverait complet, sans aller-retour.

À rapprocher d'un chiffre du produit : sur 30 jours, 549 diagnostics d'erreur CLI sur 733 ne nomment aucune cause. Ce sont autant de situations où quelque chose casse et où personne ne nous le décrit.

Ce qu'il faut faire

Ajouter un outil report_issue au serveur MCP d'AgentsRoom, à côté de backlog_* et memory_*. Il dépose dans le même board que le bouton « Bug ou retour » du produit, pas dans le backlog du projet en cours : c'est un retour SUR AgentsRoom, pas une tâche du projet de l'utilisateur.

À cadrer :

• la description de l'outil doit être restrictive. Un agent ne doit pas se mettre à ouvrir un ticket chez nous à chaque erreur qu'il rencontre dans son propre code. La formulation doit dire : « seulement quand le défaut est dans AgentsRoom lui-même, jamais pour un problème du projet en cours ».
• ce qui est joint automatiquement (version, OS, provider, dernier appel d'outil en échec) et ce qui ne doit jamais l'être : aucun contenu du projet de l'utilisateur, aucun chemin absolu, aucun secret.
• consentement : ce ticket envoie des données depuis la machine de l'utilisateur vers nos serveurs. Il doit passer par la même porte que le reste de la télémétrie produit (isDataSharingEnabled()), ou par une confirmation explicite au moment de l'envoi. Ne pas ajouter un nouvel envoi réseau sans ce gate.
• limite de débit, pour qu'un agent en boucle ne nous inonde pas.

C'est fait quand

Un agent tournant dans AgentsRoom peut déposer un rapport de bug qui apparaît dans notre board de retours, avec la version et l'OS déjà renseignés, et sans qu'aucun contenu du projet de l'utilisateur ne parte avec.

Taille : petit. Le rapporteur est notifié à la fermeture.