--- title: "Give agents a tool to send you feedback" description: "Agents are the ones using your MCP now, and they hit friction you never see. One extra tool lets them tell you what broke, what they expected, and which model and harness they were running. Here's the shape I use and a real report I got." date: 2026-09-17 language: en canonical: https://gduv.club/articles/agent-feedback-tool source: gduv.club --- If you ship an MCP server, most of the people using it aren't people. An agent reads your tool descriptions, picks one, sends a payload, gets a result, and decides what to do next. That whole loop happens without anyone watching it. So when something goes wrong in there, nobody tells you. The agent retries, works around it, or gives up and tells its user the task can't be done. You see none of it. The fix is small: add one more tool to your MCP, and let the agent report the problem to you. ## One tool, and a description that says when to use it The tool does nothing to the product. It takes a description of what went wrong and forwards it to you. What makes it work is the description the agent reads, because that's the only instruction it gets. Here's the one I use on [AI Glot](https://ai-glot.com/docs/mcp/standard-tools): ```text Use this tool while using AI Glot when an AI Glot tool, response, error or workflow behaves differently from what you expected, or when you wish something worked differently. Call it once the issue is clear. Describe the situation, what you observed and what should have happened. If known, include the related tool, API operation or CLI command, the AI model and the agent harness. Do not include API keys, tokens, signed URLs or full file contents. This tool only records feedback, does not retry or change your translation, and costs no credits. ``` Three things in there are doing real work. "Once the issue is clear" stops it firing on the first transient error. "Does not retry" stops the agent reaching for it as a recovery step when a call fails. "Costs no credits" matters because agents are cautious about anything that might spend a user's money, and a tool they're unsure about is a tool they don't call. 1. **The agent hits a problem**. A rejection, a surprise, a missing tool 2. **It calls the feedback tool**. Still holding the whole context 3. **Your server adds what it knows**. Workspace, surface, timestamp 4. **It lands wherever you want**. A webhook, and then your problem _The agent is already in the failure when it calls this. Nothing has to be reconstructed afterwards, which is the part that makes the report worth reading._ ## The fields This is where most of the value is. An open text box gets you "it didn't work". Named fields get you something you can act on. What [AI Glot's tool](https://ai-glot.com/docs/mcp/standard-tools) asks for, with the three required fields first: **Six fields: observed problem, situation and expected solution are required; related action, AI model and agent harness are optional.**
observed_problem What went wrong, was confusing, or should work differently
situation What it was trying to do, and what happened around the problem
expected_solution What it expected instead, or how it would improve this
related_action The tool, endpoint or command involved
ai_model If known. Do not guess
agent_harness Claude Desktop, Cursor, a CLI
`expected_solution` is the one I'd keep if I could only have one. A user tells you something is broken. An agent tells you what it thought the call was going to do, which is a direct read on whether your tool description matches your tool. The optional three exist because "do not guess" is a real instruction an agent will follow. I'd rather have the field empty than filled with a plausible model name. When they are filled, you can sort by model and by harness, and a problem that only happens on one of them stops looking random. **Don't ask the agent for what you already know** Workspace, credential, surface, timestamp and a feedback id are added by my server, not by the agent. Anything the agent could get wrong, or could invent, is worth taking out of its hands. It also keeps the tool cheap to call, which is the difference between a tool that gets used and one that doesn't. ## What one actually looks like This is a real one, exactly as it reached me on 10 September: _Nobody would have filed this. The run finished, the translation happened, and the workaround was one extra call. It is exactly the kind of friction that never reaches you._ That's a bug report with a reproduction, a diagnosis and a proposed fix, written by the thing that hit it, seconds after it happened. I didn't ask for it and I didn't pay for it. ## Why this is better than the feedback you usually get I'm not saying agents replace users. I'm saying this particular channel has properties user feedback doesn't. **A user telling you** (Hours or days later) - Remembered, and partly reconstructed - Filtered through what they think is worth reporting - Softened, because complaining feels rude - Rarely says what they expected instead - Only from the few who bother **The agent telling you** (Seconds later) - Written while the whole context is still loaded - No judgement about whether this is worth your time - States what it expected, because that is the field - Names the exact call, model and harness - From every run that hits the problem _Both are worth having. The column on the right is the one you currently have no way of collecting._ The unbiased part is what I keep coming back to. An agent has no relationship with you to protect and no worry about looking demanding. It read your description, formed an expectation, and the expectation didn't match. That gap is the whole report, and it's the most honest documentation review you'll ever get. ## Where the reports go Mine POST to a webhook and land in a channel I read. That's the entire setup, and it was enough to be worth it. You can take it further, and the options get interesting once the reports are structured: - **Store them** and group by `related_action`. Three reports on the same tool is a spec, not an anecdote. - **Notify on the ones that matter**, filtered on whatever you care about: one tool, one model, one harness. - **Put an agent on the queue** to deduplicate, prioritise and draft a proposed fix against your repo. The reports already contain a reproduction and an expected behaviour, which is most of what a fix needs. - **Run it on autopilot**, if you trust your tests enough for that. I don't yet. None of that is required. The webhook alone changes what you know about your own product. ## Two rules I'd not skip **It must never break the conversation that called it.** If your webhook is down, the tool returns a plain "this could not be delivered, nothing else to do", not an error. An agent that gets an exception from a feedback tool will start treating the failure as part of the task it was doing. Mine also carries a short timeout for the same reason: a hanging webhook holds the agent's turn open. **Say what not to send.** Agents are helpful, and a request for context will otherwise get you API keys, signed URLs and file contents. Naming them in the description is enough, and it means you're not storing things you never wanted. **A smaller version is fine** On my documentation framework the tool is `report_issue` and it takes three fields: the page, what's wrong, and an optional kind from a list of four. The server adds the page URL, the agent's product name, the site version and the timestamp. It took an afternoon. ## Try it on your own MCP If you already ship an MCP server, this is one tool, one webhook and a description you'll rewrite twice. The first report that arrives will tell you something about your product you didn't know, and it'll be about a tool you thought was fine. Agents are your users now. Give them somewhere to complain. ## Sources - [My original post on the idea](https://www.linkedin.com/posts/guillaume-duvernay_idea-give-your-users-claude-code-a-tool-activity-7503753518369980416-g46b) - [Max Tkacz filmed me explaining it](https://www.linkedin.com/posts/maxtkacz_mcp-llm-kewl-ugcPost-7506271906975686657-sq8X) - [Model Context Protocol: tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools)