API Evangelist Conversation with Dave Eyler on Product Analytics for MCP Servers, Capturing Agent Intent, and Products That Develop Themselves

I am the founder of Good Timing. We make Baton, product analytics for MCP servers. The future, and I do not think I have to convince you of this, is that people are going to tell agents to use apps for them. I use all my apps like that now. I am always looking for MCP servers because I just want Claude to take care of stuff for me. That is the vision. I have been doing tech for a long time. I was head of product at SingleStore, which is a super high-performance database, and I worked at Apple, Databricks and some other companies before that.

It depends on where you are in your MCP journey. Some people are early, with a new experience they want to create. Some of the companies we work with are much bigger, with a fleet of MCP servers, and they want to know how to make it faster, how to reduce the tokens their customers are burning, and how to create a great product experience inside MCP. The agent surface is a new surface, and these companies have people whose whole job is to make it good. Today Baton captures the intent on each tool call. We add a parameter asking the agent why it is calling this tool, and a feedback tool where the agent can say whatever it wants about the MCP server.

The constant feedback loop is key, and almost everybody we talk to asks for it. People tell us we are showing them cool data on how their MCP server is used and where the problems are, but what they really want is to give it to Claude Code and have it fix it. So we are building Autopilot. You point Claude Code at our MCP server, they talk to each other, and it generates the pull requests and does the instrumentation for you. It is a product that can develop itself.

Maybe I should start calling it something different, but the main thing it does is help you make your product better. I have done product management my whole career, and the hard part is getting people to tell you what they want. They get confused about it and do not really describe it. If the agents are telling you what they want in the tool calls and the feedback all the time, you just make a better product, and if it keeps iterating on itself, the more value you create, the more money you can get from it. I was talking to someone who wants to monetize their MCP server, and the dream is to charge for value created. Now that the robot is telling you what it wants and what it is doing, maybe it stops being about tokens and becomes about the outcomes you drove.

I think the role of dashboards and analytics has changed. You used to need the dashboard to solve your problem and see the answer. The agents do not need to look at a dashboard to see what is going on, but you still need it to convince the humans involved that it is real. It has almost moved to being the proof rather than the place where you make the fix. The bigger chasm to cross is getting normal people to realize they can just have Claude use apps for them. I used a startup that lets you talk to your LinkedIn network, and it was magical. So many apps are a hundred times better if you just talk to Claude, but installing a custom MCP server is still too much friction in most clients.

We run what we call agent taste tests. We take three CRMs and ask each to log the same 40 messages. One of them takes four times as long and costs four times as much, and if you only look at the tool calls, you see a lot of 200s and you cannot tell what it is doing. If you look at the intent, you can see it is looking up 40 people one at a time, writing 40 people one at a time, and the agent asks for five fields while the MCP server returns the entire database. We did the same with three Postgres MCP servers asked to tune a query, and they were all over the place. Once you can see the agent thinking, fixing it is so much easier. Observing your customer’s agent is a new problem, because you are not running the inference.

Right now we help the people who make an MCP server make that experience great for their end user, and great usually means getting what you want as fast as possible and burning as few tokens as possible. Discovery is another huge problem I have not thought about as much. We do have a proxy configuration, so if you want to observe an MCP server that is not yours, and you cannot install our SDK in it, you can put the proxy in front of it and see how it behaves. You could use the SDK on your own MCP server and the proxy for the ones you are onboarding with.