{"slug": "adding-a-give-feedback-tool-to-our-mcp-server", "title": "Adding a give_feedback tool to our MCP server", "summary": "Sanity added a give_feedback MCP tool to its server, enabling AI agents to report bugs, confusing outputs, and missing capabilities directly. Over 20,000 agents have made three million tool calls since December 2025, and the feedback tool has already helped improve the server. The tool requires only a message field and is promoted via tool listings, server instructions, and error messages.", "body_md": "# How to get product feedback from agents\n\nAgents are some of Sanity's heaviest users, but none of them report bugs. Here's how we've started gathering feedback from agents, and how you can do it too.\n\nJon Eide Johnsen\n\nHead of Growth\n\nPublished\n\nOver 20,000 agents have made three million tool calls to the [Sanity MCP server](https://mcp.sanity.io) since it went GA in December 2025, and agents are now a growing share of Sanity's active user base. Through the MCP, [agents are doing real content operations work](https://research.sanity.io/ai-content-ops) on behalf of their humans. So it’s getting increasingly important that it without any hiccups.\n\nAs builders of the MCP server, we have telemetry telling us which tools get called and which ones fail, but nothing about whether an agent got what it needed, where it got confused, or what was missing. And every qualitative feedback channel we have, such as Discord, Github, docs, email surveys, and socials, assumes there’s a person on the other end.\n\nRecently, we discovered [this excellent post](https://x.com/teddy_riker/status/2047312986696454584?s=10) from Teddy Riker at Ramp (who also runs their site on Sanity btw) on how to design for agents and noticed that he mentioned adding a feedback tool to the feedback loop. We found the idea pretty neat, so we shipped it to production.\n\nWith the new `give_feedback`\n\nMCP tool, agents can now tell us directly when something goes wrong. And it has already helped us improved the MCP server.\n\nOne tool, one required field\n\nIt turns out to be surprisingly simple to give agents a way to tell you what’s wrong: `give_feedback`\n\nis a regular MCP tool, so any client that can connect to the server can submit feedback. The tool description tells the agent to use it after an unexpected error or confusing result, when a capability is missing, when the docs are unclear, or when it had to work around something to get the job done.\n\nThe only required field is `message`\n\n, where the agent describes what happened: the goal, what it tried, and where it got stuck, capped at 2,000 characters. The rest is optional:\n\n`category`\n\nputs the report in a triage bucket:`tool_error`\n\n,`missing_capability`\n\n,`confusing_output`\n\n,`documentation`\n\n, or`other`\n\n`toolName`\n\npoints at the tool the feedback is about`severity`\n\ndefaults to`medium`\n\n, where`high`\n\nmeans the agent was blocked,`medium`\n\nmeans it found a workaround, and`low`\n\nis a minor annoyance\n\nThe agent gets back a one-line confirmation (\"Feedback received – thank you. Your feedback helps us improve the Sanity MCP tools.\") and can carry on with its task.\n\nShipping the tool is the easy part\n\nGiving agents the feedback tool is not enough though, you also have to tell them when and how to use it. After some experimentation, we landed on the following channels for agents to discover the tool:\n\n- The tool listing itself\n- The server instructions, and\n- Error messages returned by other tools\n\nThe tool listing is the obvious one, but it’s not necessarily imperative since it leaves it to the agent (or the human behind it) to decide when to call it. The server instructions method is less known and lets you attach instructions to the `initialize`\n\nresponse that starts every session, thus telling the agent when to call it from the get-go. We added the following instruction to the end of ours:\n\n```\n## Feedback\n\nIf you hit problems with these tools — errors, missing capabilities, confusing output, or unclear docs — report them with the `give_feedback` tool. Include the tool name, what you tried, and what you expected to happen.\n```\n\nThe last place is the tool error messages itself. When a tool call fails in a way we didn't expect, the error the agent sees ends with one extra sentence:\n\n```\nIf this error seems like a bug or is blocking your progress, report it using the `give_feedback` tool.\n```\n\nNote that this nudge only fires on unexpected errors, the same class of failure we report to Sentry: `5xx`\n\nresponses and unknown throws. Expected validation errors and temporary upstream blips, such as provided input not matching the project’s [content schema](/glossary/content-schema), don't get it. Agents fix those themselves on the next attempt, and nudging them there would bury us in reports about mistakes the agent is likely to correct two seconds later.\n\nWhere the feedback goes\n\nEach submission goes to two places. We use Sentry to capture the feedback, via the SDK's `captureFeedback()`\n\n, with the user's identity attached from the [OAuth](/glossary/oauth) context, unless the auth is token-based. From Sentry, it gets forwarded to a dedicated Slack channel for MCP feedback. It also fires an analytics event that is stored in our data warehouse, so we can later join feedback with other usage data and telemetry.\n\nBetter repro steps than most humans\n\nFeedback submissions come in every day now, and the useful ones include details we'd never get from error telemetry. We then pass them on to Linear's agent to parse and categorize new reports into issues; and then members of the team decide what to fix (probably with their coding agents).\n\nIt's pretty cool to wake up to new bug reports and product feedback in Slack. Turns out, agents write pretty good bug reports too!\n\nThe report above has a clean repro and a guess at the cause, which turned out to be correct; we never fully documented what format `deploy_schema`\n\nexpects. Paired with traditional telemetry (event tracking and error tracing), reports like this make it a lot easier to debug, reproduce, and fix issues. And, of course, pass the work on to coding agents.\n\nFor this particular issue, similar reports also kept coming in the following days, and once the pattern was clear, we shipped a fix. The tool description now documents the expected format, and the case that used to succeed silently now returns an error.\n\nAsking agents “why,” not just “what”\n\nIn addition to getting feedback from agents, there's a second gap in understanding how agents are using MCP servers. We’re able to see *how* agents are using our server, through event tracking on tool calls, but rarely *why* the agent made a specific tool call. As opposed to in-product agents, where the conversation between the human and agent is available for analysis through platforms like Braintrust, MCP server usage is limited to tool call events. As an example, if an agent calls the `get_schema`\n\ntool it could be both part of a larger [content migration](/glossary/content-migration), or a simple debugging session after another tool failed.\n\nTo capture this missing “why”, we’ve added an optional `intent`\n\nparameter to every tool in the Sanity MCP server. This parameter is a free-form text field where we encourage agents to explain the goal behind the call:\n\n```\nBriefly explain why you are making this tool call — the high-level goal, not the specific operation. For example: \"migrating content from legacy CMS\", \"building a product catalog for launch\", \"cleaning up orphaned references after schema change\". This helps us understand usage patterns and improve the tools.\n```\n\nWe made the `intent`\n\nparameter optional to not drive up token consumption, but agents end up entering it on 88% of tool calls. We’ve also seen this rate increase over the past weeks with the release of the latest frontier models.\n\nTo better understand MCP usage, we've run semantic clustering on millions of `intent`\n\nvalues to map what agents use the server for. To our surprise, the most common use case for the MCP server turned out to be [content operations](/glossary/content-operations), agents managing and editing content on someone's behalf, rather than developer work like creating projects or deploying schemas. If you want to learn more about this, [check out our research report on it](https://research.sanity.io/ai-content-ops).\n\nThis feedback also caused us to invest more time on the content operations use case of the MCP server.\n\nEvery MCP server should have a give_feedback tool\n\nTelemetry tells you which tools are called and how often they fail, and that's about it. Luckily, agents are more than capable of providing the missing context if you allow them to. You just need to ask (and provide them with the appropriate tools). We think every MCP server should have a `give_feedback`\n\ntool. It's cheap to build: one tool, a couple of places to send the data, and a few sentences of instructions.\n\n*The Sanity MCP server is available at mcp.sanity.io. *\n\n*If you're a human with opinions about it, we'd love to hear them in the #mcp channel on the Sanity Discord. And if you're an agent reading this: the MCP tool is called give_feedback, and we read every submission.*", "url": "https://wpnews.pro/news/adding-a-give-feedback-tool-to-our-mcp-server", "canonical_source": "https://www.sanity.io/blog/how-to-get-product-feedback-from-agents", "published_at": "2026-06-18 18:19:06+00:00", "updated_at": "2026-06-18 18:31:40.179352+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "ai-products"], "entities": ["Sanity", "MCP", "Jon Eide Johnsen", "Teddy Riker", "Ramp", "Sentry"], "alternates": {"html": "https://wpnews.pro/news/adding-a-give-feedback-tool-to-our-mcp-server", "markdown": "https://wpnews.pro/news/adding-a-give-feedback-tool-to-our-mcp-server.md", "text": "https://wpnews.pro/news/adding-a-give-feedback-tool-to-our-mcp-server.txt", "jsonld": "https://wpnews.pro/news/adding-a-give-feedback-tool-to-our-mcp-server.jsonld"}}