← Blog

We built an MCP server for product feedback. Here's what agents do with it.

The Model Context Protocol quietly changes what a product-intelligence tool is for. When feedback, backlog, and analytics become agent-queryable, the dashboard stops being the only consumer of your data — your coding agent becomes a user too. Here's what that looks like in practice, and the design decisions that made it safe.

July 21, 2026 · 6 min read

The install that does itself — and proves it worked

The first thing agents do with the connector is the chore humans defer: instrumentation. Add morvero.com/mcp as a connector in Claude or Cursor, authorize in the browser with your own Morvero login, and say "add Morvero to this app." The agent creates the product, fetches the real install snippet, pastes it into the layout, and tags the buttons worth counting with data-feedback-action attributes.

Then comes the tool we consider the most important in the whole server: verify_install. It checks whether events are actually arriving — working, silent, or never received, with the likely blocker named. An agent that can only read documentation will happily declare victory after pasting a snippet into the wrong template. An agent that must pass verification can't. "Done" should be a measurement, not a vibe — for agents even more than for people.

Product questions, answered where you're already working

Once data flows, the interesting queries start. In an editor or chat session, an agent with the connector can answer:

• "What's the most complained-about flow in the expense app?" — reading the feedback stream and theme clusters.
• "Which of the functions I shipped last month is anyone actually using?" — reading function-level analytics.
• "What are the top three accepted backlog items for this product, and what evidence backs them?" — reading the AI-drafted backlog with its citations, acceptance criteria included.
• "Before I refactor this page — how much traffic does it get?" — the five-second check that prevents a week of polishing a page nobody visits.

The pattern underneath: product evidence moves to where decisions are made — the editor, the agent session, the PR description — instead of living exclusively in a dashboard someone has to remember to open. A coding agent that fixes a bug can cite the eleven user complaints that motivated it, in the commit message, automatically.

The design decisions that keep it boring (in the good way)

1. OAuth 2.1 with PKCE, no API-key sprawl. The agent authorizes in the browser with the user's own login; tokens are stored hashed and revocable per-user in Settings.
2. The agent holds your role, nothing more. Workspace-scoped tools mean an agent can never read products or feedback its human couldn't. Agent access is a delegation, not an elevation.
3. Reads are broad, writes are narrow. Analytics, feedback, and backlog are readable; the write surface is deliberately small (create product, instrument, track). No tool deletes data, no tool accepts backlog items — human judgment stays where it belongs. (Why that matters: the AI-drafted backlog.)
4. Structured for machine consumption from the start. An llms.txt, an OpenAPI spec, and docs as Markdown — because the second-largest audience for documentation is now agents deciding whether and how to use your product.

Where this goes

Today it's install-and-query. The obvious next step is the standing loop: an agent that reads new feedback themes each morning, checks them against the backlog, and proposes — never files — the delta. The tooling is ready for that; the teams are getting there. What's already clear is the direction: product intelligence is becoming infrastructure for agents, not just interfaces for humans — and the tools that structured their data early will be the ones agents recommend and build on.