The Question

When MCP started appearing everywhere in AI product conversations, my first instinct was: Should Encatch have one too? But that turned out to be the wrong first question.

A more important question was: how would our users benefit from this addition? That question led us into a deeper exploration of "MCP UX" and where and how it could genuinely add value to Encatch.

The Decision

Encatch helps product teams collect and manage user feedback through in-app feedback forms and shareable forms. A product manager can gather responses and use those to identify patterns and opportunities.

Now, to answer the question, I dug deeper into the current usage patterns.

While Encatch already provides AI-assisted capabilities that help users build forms and summarise responses using prompts, these capabilities still require the user to enter Encatch, navigate through the application, and reach the relevant page.

This led us to our hypothesis:

Product managers may want to interact with their feedback through the AI tools they already use, instead of constantly switching between multiple platforms.

Because we were still at an early stage, we didn't have enough customer data to validate these assumptions directly. So we treated them as hypotheses rather than fact.

We wanted Encatch to meet our users where they are already comfortable (deeply immersed in their favourite LLM tool). And that’s what led us to the decision to build Encatch MCP.

But How?

Competitor research helped me understand how other products were approaching MCP. One common approach was to expose existing API functionality as MCP tools.

From a product perspective, we had to ask whether exposing an API automatically created a useful user capability. We wanted to do better.

The Approach

Initial Hypothesis: AI Is Most Valuable for Analysis and Inference

Our initial assumption was that feedback data becomes particularly valuable when users can ask questions about it and derive insights from it. This was shaped by discussions across different forums, as well as by combing through Reddit posts from product managers, where one challenge surfaced repeatedly: collecting feedback is relatively easy; turning large volumes of it into clear, actionable decisions is where the real difficulty lies.

This became our entry point for building the Encatch MCP: helping users analyse feedback and derive insights from it.

Questions That Followed

Surprisingly, as we started building this, a more important question emerged: how much should AI be allowed to do without the user explicitly taking action inside Encatch?

This required us to think more deeply about authentication, authorization, permissions, access to user data, and, most importantly, where AI autonomy should end and explicit user control should begin.

We came to the decision that some tasks should not be implemented by AI and must remain completely in the hands of the user, enabling a human-in-the-loop approach.

Drawing the Boundary

We began distinguishing between actions that helped users understand their data and actions that could expose sensitive information, change the state of their feedback system, or create consequences that were harder to reverse.

The decision was made to ensure that data containing critical user information would reside within Encatch only.

From Insight to Action

Insights are only useful if they lead to action.

Once we could analyse feedback and identify patterns through the MCP, the next logical question was: what happens next?

How do you take an insight generated by your AI tool and turn it into an actionable task?

The answer lies in using the tools already connected to your LLM. For example, insights generated from Encatch feedback can be turned into actionable tasks in Linear using the same AI conversation.

Some Loose Ends

After establishing a working model that could fetch and help users analyse feedback, something felt incomplete. If users could derive insights using their LLM tool, wouldn’t it make sense to add more capabilities that could help them build the feedback loop itself?

This led us to add another capability: building a feedback form.

With the ability to build and design a feedback form alongside feedback inference, the dependency on navigating to the platform reduces significantly.

Last Piece of the Puzzle

By allowing users to analyse feedback and build new forms through their AI tool, we had significantly reduced the need to navigate through Encatch. But there was still a problem.

There were some actions that were deliberately left for the user to perform. These tasks were categorized as destructive tasks, which formed a vital part of building and designing the feedback loop. They included publishing the form, setting up triggers and targets, archiving the form, and fetching or downloading responses.

Because these actions could materially change the feedback workflow or expose underlying data, we deliberately kept them behind explicit human control.

These controls were intentionally left with the human in the loop as a measure of security and to prevent unintended actions.

However, the trade-off was that this would require users to go back to the Encatch platform and navigate through multiple pages to complete the operation. This was counterproductive to our ambition of removing interruptions while designing the feedback loop.

This was when we decided that instead of making the user go back to Encatch, we could bring Encatch to the user through MCP using in-app deep linking.

Every action that requires human interaction would be provided with an intermediate deep link that redirects the user to the specific point in the journey.

Instead of asking the user to manually open Encatch and search for the right page, the AI could open a deep link that takes them directly to the exact step requiring their attention.

The link would also be SSO-enabled as an optional configuration, allowing the user to continue the workflow without another login or navigation step and providing a seamless yet secure experience.

What Building It Taught Us

1. An Existing API Is Not Automatically an MCP Capability

An existing API might be technically ready to expose through MCP, but that does not automatically make it an MCP UX-first capability. The question isn't just whether an AI can call the API but whether exposing that capability through an LLM actually makes the user's workflow simpler or more valuable.

2. AI Autonomy Needs Boundaries

Not every task should be automated simply because it can be. The level of autonomy should depend on:

Consequences
Reversibility
Data sensitivity
Impact on the user's workflow

3. Human-in-the-Loop Does Not Have to Mean Friction

We initially faced a trade-off:

Security and control vs. a seamless workflow.

But the deep-linking approach showed us that human control doesn't necessarily mean forcing users through a disconnected manual workflow. The user can still make the final decision while being taken directly to the point where their input is required.

4. Shipping Is the Start of Validation, Not the End of the Journey

We built based on hypotheses. Now the real validation starts.

The interesting questions are no longer about whether we can build these capabilities, but whether users will actually adopt them and whether they meaningfully improve the way product teams work with feedback.

Finish Line

And with that, we are LIVE.

We started with a simple question: would product managers want to work with their feedback through the AI tools they already use? We had our assumptions, explored the possibilities, and built what we believe is a useful starting point. Now we'd love for you to connect the MCP, try it in the feedback activities you do most often, and let us know how it goes. Does it actually help? Where does it fall short? Your experience will help us build better.

We have our hypotheses. Now it's time to see what happens when they meet the real world.

Give it a shot. Try Encatch now and see where the conversation takes you.

Want to learn how it works? Check out our MCP documentation.