Building AI into your product with an MCP server

The advent of AI has seen an explosion of companies scrambling to integrate the newest and most innovative AI features into their products. You've almost certainly seen it: a summary that writes itself, a search box you can ask questions, an assistant in the corner. Sometimes these changes are great. Other times, you sit there scratching your head, wondering: "Was this really necessary?"

Herein lies the ultimate question about this emergent technology: is there a repeatable way to adopt AI that works for any company, improving both how the business runs and how customers use the product? Whether there is an answer to this remains to be seen, but as time goes on I'm more inclined to think a one-size-fits-all approach doesn't exist. Each company needs AI for different uses, which invariably leads to a tailored implementation for each one. So the question becomes: "What tools can we build to create a concrete foundation from which a custom solution can be achieved?"

One of these tools is the MCP server. Since Anthropic introduced MCP as an open standard in late 2024, many companies have added their own MCP server to their applications, and for good reason. Connecting all your different apps to your AI agents through these servers feels like magic, supercharging workflows. And we at Sentia believed we had the perfect place to build our own: Ribica, our internal delivery log app.

The problem we were solving

Ribica is a tool developed in-house to streamline the scoping, estimating, quoting and approval process, while also logging decisions, scope creep and changes during the development lifecycle. It began as a decision logging tool, but quickly expanded to include the pre-dev work: turning a raw brief into a structured scope outlining what was in scope, what was left for later and what was left out, then turning that into a real, itemised estimate and quote for the client. We call that workflow Ballpark.

Ballpark already ran on Claude, but it ran beside Ribica, not with it. The method was a set of files in a Dropbox folder that Claude Cowork read at the start of each session, and everything it produced was saved back there as files: the scope, the copy for the quote, and a spreadsheet for importing tickets into ClickUp. Ribica only heard about the work once the client had accepted.

So we had two flows that should have been one, and the work had to cross between them:

• Each project's context had to be brought in. The method's files covered Sentia in general, but not the project at hand. Claude couldn't see Ribica's clients, projects or anything already agreed there, so the PM supplied the brief and any history for every new piece of work.
• The output lived in the wrong place. Scopes and estimates sat in a folder, away from the project they described. Anyone looking at the project in Ribica couldn't see them.
• It only worked for one person. The method was set up on one person's Cowork and Dropbox, so nobody else on the team could run it, and nothing in Ribica showed the work was happening.

What we built

To solve these problems, we gave Ribica an MCP server. Think of it as a port on the side of your product: the product describes a set of actions, and any compatible assistant can use them once a person connects it and signs in. Our team uses Claude, but the server works with any AI assistant that supports MCP. Nothing in it is specific to one provider.

Ribica is a Ruby on Rails app, so we used mcp, the official Ruby SDK from the MCP project. It handles the connection and the message format, so we could focus on our tools and what each one should do. We started with eight actions (MCP calls them tools), and the list grew one workflow at a time. Today Ballpark has around thirty tools, covering the whole path from a client's first message to the scope, the estimate, the quote and the tickets in our project tracker.

A piece of work now goes like this:

1. The PM adds a scope request in Ribica, with the client's words exactly as they arrived.
2. A button on the request copies a short reference ("Scope request REQ-12"), which the PM pastes into Claude.
3. Claude fetches the method, reads the request, the client's words, the team's comments and any answers to open questions, then drafts the scope with the PM and saves it to the project.
4. Questions only the client can answer go to the PM. Questions for our own team are answered by the project lead in Ribica, and Claude picks up the answers next session.
5. Claude saves the estimate story by story, and Ribica turns it into a quote that the client signs in Ribica.
6. Claude imports the tickets into ClickUp and links each one back.

Months later, a developer working on a ticket can ask their own assistant what was agreed. It reads the agreed scope, the business rules and every decision made on that ticket, straight from Ribica.

Five things we learned

1. Put your process in the product, not in a prompt

Ribica serves the method itself, one file per step: scoping a new build or an existing app, estimating, revising an estimate after review, writing an RFP response, and so on. The AI fetches each step when it reaches it. We edit the method centrally without anyone changing their AI setup. Adding a step means adding a file and a name to the list.

2. Let the AI judge the work, and let the product do the maths

We split the work by what each side does best. The AI makes the judgement call: how many hours each piece of the project will take. Ribica does everything that has to be exactly right: it adds testing and project management time, applies the client's rates and tax, and totals the quote. An AI can occasionally get a sum wrong. Code doesn't, and you can test it.

3. Enforce your rules in the app, not in the instructions

During implementation, we found that describing the rules in the method wasn't enough. The agent follows the instructions most of the time, but most of the time isn't good enough for critical business records. So the server enforces the business rules itself, and when the agent makes the occasional mistake, it tells the agent what to do instead. For example: a project has one original scope, and more work is a variation; a story's hours must equal the sum of its tasks; and the estimate, costs and terms are locked once the client has signed. Making sure the agent can't break these rules belongs in the app, not in the method.

4. Assistants don't all behave the same

MCP lets a server send instructions to the assistant when it connects. Some assistants use them; others don't pass them on to the model. So we moved the method into a tool, because every assistant can read what a tool returns.

We also found that some assistants show the model only a tool's name until it decides to look closer. A clear name like get_method, and a description that starts by saying when to call it, matter more than you'd expect. Each tool also says whether it only reads or changes something, so the assistant knows to ask before it overwrites work. Thirty well-named tools are easier for an assistant to use correctly than a handful of vague ones, and much easier than your whole API.

5. Security is your existing permissions, applied per person

Each person connects their own assistant through a normal sign-in (OAuth). Every request carries who they are, and the server applies the same roles as the app. Managers can scope, estimate and save. Developers get a read-only subset: they can look up what was agreed and why, but never costs or anything they couldn't see in Ribica. Nothing reaches beyond the person's own organisation.

Where this leaves us

We started by asking whether there's one right way to bring AI into a product. Building this MCP server hasn't changed our answer: we still don't think there is, as the right shape will always depend on the workflows and goals of the client. However, an MCP server comes close to the next best thing. Integrating a foundation that works with any assistant, any tech stack and any business lets your team work in the tools they already use while you tailor the solution to your own needs. It turned our two disconnected flows into one, and every workflow we've added since has been a few more tools on the same foundation rather than a new project.