Building Nayya's MCP server for enterprise AI delivery

At the time of writing, I've been a product manager at Nayya for a little over a year. Not a long time, but long enough to watch both the company and the market change fast. AI and complex partnership motions both shape how Nayya operates and how it delivers its product.

Historically, Nayya delivered its flagship product through integrated partners using a customizable UI that embeds in partner systems. That's where I came in, as the product manager for the integrations team. My job was to make integrations simple and reliable, and to get our applications in front of end users. These integration motions aren't new or novel, but they matter. They're also a building block.

Then the market shifted. Just about every partner Nayya works with has released or started building its own AI agent, and what they needed from us changed with it. Beyond integrating our application, we now had to help partners deliver a strong agentic experience to their own users. As the fight for the front door began, we changed our strategy. We would be the back-end partner that powers those front ends.

Nayya built a schema for representing benefits data, designed for machine readability. Alongside the schema, we have a knowledge base full of data, plus the ability for partners, employers, and employees to connect their own data so Nayya can deliver better insights. Synthesized insights from that data let our partners add value inside their own systems. How we deliver that data is what makes the difference.

Enter Model Context Protocol

Model Context Protocol (MCP) is Anthropic's open standard for connecting AI models to external tools and data sources. An MCP server exposes capabilities as tools: discrete, typed functions that an AI model can call. When a partner's agent needs to query a database, retrieve a record, or pull an insight from another system, MCP is the bridge that lets it do so in a structured, predictable way.

The reason it fits our strategy is that MCP separates the capability from the interface. We don't have to own the front end to deliver value through it. A partner's agent handles the conversation and the presentation, and our server provides the data and the logic behind it. That maps cleanly onto the back-end role we'd decided to play. We bring the benefits schema, the knowledge base, and the connected data; the partner brings the user relationship and the agent.

It also changes how the same capability reaches different people. A traditional UI ships one experience that has to work for a broad population. With MCP, we hand the data to the agent, and it decides how to present it based on what it knows about the user. One person gets a map, another gets a list, another asks a follow-up question, and reshapes the answer entirely. We deliver the substance once, and the agent tailors the form.

The implementation is the easy part. The hard part is deciding which tools to expose, and at what level of granularity.

Building the MCP server

I worked with my team to build Nayya's first MCP server.

Most of the effort went into one question: which tools to expose. Too few and the agent can't do anything useful. Make them too specific and the agent can't tell which one to call. We ended up modeling tools on the questions people actually ask, rather than on the shape of our data.

Provider search was one of the first we shipped. Finding a doctor usually means logging into a portal, checking your network, filtering by location and specialty, and guessing at quality across a few tabs. Now a user can ask their AI assistant for an in-network dermatologist nearby with good reviews and get an answer in seconds, shown as a map, as cards, or as a plain list depending on what they want.

The tools are only part of it. Who we build the server for matters just as much. Nayya works with Systems of Record and with AI labs, and they ask for different things. The differences show up in what context we can share, which authentication patterns we support, and how data authorization is handled. Get any of those wrong and the experience breaks for the person at the end of it.

Partner roadmaps are the other moving piece. A partnership that works tends to grow, and partners come back wanting more than the server was first built to do. MCP handles a lot of that, but not all of it. Some of what they want sits outside what an MCP server is good for.

Agentic integration strategy

The MCP server was the first step. Delivering the full Nayya experience takes more than handing tool calls to a partner agent. So I led the team in building out our Agent-to-Agent (A2A) strategy for the more complex interactions.

Some interactions don't fit inside a single tool call. Deeper conversations, cases where Nayya needs to own more of the message, and experiences that require richer artifacts call for a different protocol. MCP is the right fit when a partner agent wants to call a function and present the result itself. A2A is the right fit when our agent needs to carry the conversation, reason across multiple steps, and return something fuller than a single response can hold.

Keeping both protocols and using each where it fits is how we work with partners at very different stages of building their own agents.

What I took away from this

A few things stuck with me from building this.

Distribution is a product decision, and it has to be made early. The old bet was that a strong product would earn a spot in someone's day. With AI assistants, that spot has moved. Showing up inside the tools people already use beats hoping they come find ours.

The technical side was rarely the hard part. Standing up an MCP server is straightforward. The decisions that mattered were what to expose, how to word it, and how the agent should present what comes back — and those are product calls more than engineering ones.

No single protocol covers everything. MCP and A2A solve different problems, and working out which one a given interaction needs has become part of how we think about delivery.

The gap between enterprise software and the people it's supposed to help has been around a long time. Building for agents is one of the better ways I've seen to close it.