AI can explain things well, but that isn’t enough on its own.
At some point you need it to read live data, take action, and help you move forward. That’s where many AI implementations or features start to fall short.
Our sister company, Shake, reached that point with their AI assistant. It could describe a bug, but it couldn’t open the ticket behind it, update anything, or pull the logs that actually mattered.
And because the whole setup depended on a single model, it wasn’t built for the long haul and they needed a better foundation.
That’s what led them to build their MCP server. It’s still in the testing phase, but it already gives their assistant a clear way to access data, run actions, and stay flexible as models evolve.
In this article, you’ll see how they built it, why it works, and how it will help them build AI features that hold up in real-world use.
Let’s dive in!
How Shake built the MCP server
First, we’ll discuss how Shake built the MCP server.
Defining the limits of their current AI setup
Shake already had an AI assistant in place.
It did useful things like summarizing tickets, suggesting priorities, and pointing out which logs might be behind a bug. But the setup hit the ceiling pretty fast.
The biggest problem was that the assistant couldn’t read or act on real data from Shake unless engineers baked that logic straight into the LLM prompt.
And that meant long prompts, brittle behavior, and no reliable way to expand the assistant’s abilities.
Everything was inside one big prompt. So every improvement added more text, more instructions, and more chances for the model to get confused.
It also meant the team had no good way to fetch fresh data. If someone changed a ticket title or updated a description, the model wouldn’t know unless they found a way to stuff that into the prompt too.
There was another issue. The assistant had no structured way to take action. It couldn’t update a ticket, change its priority, or fetch logs on demand.
Shake needed a way for the model to call specific actions only when needed and stay within safe limits.
And there was the biggest blocker of all. The whole setup tied them to a single LLM. If a new model appeared or if users preferred a different one, Shake had no easy way to support that shift without rebuilding everything.
All of this pushed the team to the same conclusion. They needed a clean separation between the model and the logic around it.
They needed something standard, predictable, and flexible enough to grow. And that’s where MCP came in.
Choosing a standard that solves those limits
Once the team understood the limits of their AI setup, the next step was obvious. They needed a standard way to connect an LLM with real data, actions, and workflows.
And they needed it to work no matter which model users preferred. MCP fit that need perfectly.
Plus, an MCP server isn’t tied to any single LLM provider.
With an MCP server in place, a developer using VS Code can run any LLM without Shake having to rebuild their system for each one. This removed the biggest long-term risk they had.
MCP also solved another pain point. It gave the AI a safe and predictable way to chain steps.
For example, if a ticket title wasn’t enough, the AI could call another action to fetch logs instead of guessing or hallucinating its way through the task.
And there was one more important piece. MCP already had a modern, standardized approach to authentication.
This made it much easier for Shake to safely connect the assistant with real development data and confirm whether the user actually had access to the ticket or file they asked for.
In short, MCP gave them a clear structure, safer access to data, and long-term flexibility. It was the first option that solved all their limits at once.
Building the server around 3 simple components (resources, tools, prompts)
When Shake started building their MCP server, they kept the structure simple.
Shake’s MCP has three core building blocks: resources, tools, and prompts.
Resources are the read-only parts, with static or rarely changing information like documentation and redirects. LLMs can read them whenever they need extra context.
Tools handle everything dynamic. They fetch live data like ticket details, update a ticket’s priority, or pulled fresh logs when needed.
Each tool comes with a clear description. This matters because the LLM uses it to understand when to call the tool and what it could expect in return.
Prompts act like templates. Think of them as pre-written instructions that help users and the AI start a task the right way.
They define workflows such as how to analyze a ticket or how to guide a bug investigation. Prompts save users from repeating the same input and help the model avoid guesswork.
These 3 parts also work together. If the model can’t solve something with just the initial prompt, it could chain a set of tools.
For example, it might start by reading a ticket, then decide to fetch related logs if the first step didn’t give enough clues. This keeps the model focused and stops it from stuffing too much data into its own context window.
By sticking to these 3 components, Shake built a server that is clean, predictable, and easy to extend.
Adding secure authentication
Once the core server was in place, Shake needed a safe way for the AI to access real user data.
This part had to be rock solid. If an engineer asks the assistant to open a ticket or fetch logs, the server has to know they’re actually allowed to do that.
The MCP standard already supports a modern version of OAuth 2.1.
The Shake team uses it to handle all authorization between the code editor, the AI, and the MCP server itself. This solved one of the hardest problems right away.
Here’s how it works in practice. A developer signs in inside their editor. That editor gets a token tied to that user.
When the LLM tries to run an action through MCP, it sends the request with that same token. The server checks it, confirms the user’s rights, and only then performs the action they asked for.
This step is crucial because tools can update data, not just read it.
Without proper checks, the assistant could bump a ticket’s priority or change its status even for someone who shouldn’t have access.
By adding authentication at the MCP layer, Shake keeps everything isolated and auditable. The LLM never sees passwords or sensitive details. It only sees what the token allows.
This gave Shake the confidence to connect the assistant with their real development workflow. It also made it easier to add new tools later without rethinking security each time.
Benefits of the MCP server
Next, we’ll take a look at some of the key benefits users get from their MCP server.
Use any LLM
One of the biggest wins of Shake’s MCP server is simple. You can use any model you want.
Before MCP, the assistant depended on a single LLM. If you wanted a different one, you were out of luck.
Now the choice sits with the user. If you’re in VS Code, you can switch between ChatGPT, Claude, Gemini, Grok, or any other supported model without changing a line of Shake’s backend logic.
It’s the same server, tools, and workflows. Only the model changes.
This gives developers real flexibility.
Some want speed, some want deeper reasoning, and others want a smaller model that stays out of the way.
Shake’s MCP server supports all of that because it standardizes how the model talks to the server.
Shake also gains a long-term benefit.
They don’t need to chase every new model that comes out. As long as the model supports MCP standards, it just works.
And that future-proofs the entire assistant without extra engineering.
Connect AI to your development workflow
With the MCP server in place, Shake’s assistant can finally fully sit inside a user’s real development workflow.
The AI can read the file you’re working on in your editor. It can see the code you’re discussing and the ticket you’re trying to solve.
That context helps it give accurate suggestions instead of generic advice.
If the fix isn’t in the current file, the assistant can search through other files to find the real source of the problem.
Engineers can miss deeper issues, especially when they hide behind a simple error message. The AI doesn’t. It follows the trail until it finds the real cause.
The assistant can also take action. It can update ticket status, change priority, or pull fresh logs when the first step doesn’t offer enough information. This is where MCP shines.
All of this saves time and reduces unnecessary back-and-forth. And engineers don’t need to jump between different tools, dashboards, and terminals.
By connecting AI to the actual workflow, Shake turned the assistant from a “chatbot on the side” into a real teammate.
Cleaner, more accurate automation
Before MCP, the assistant tried to solve everything within one long prompt. That made automation messy, since the model had to guess too much.
And when it guessed wrong, it made things worse, not better.
MCP changes that. It gives an LLM a structured way to take action only when it needs to.
If a ticket title isn’t enough, the AI can call another tool to fetch logs. If the logs still don’t help, it can call another step after that. Each action is clear and predictable.
This step-by-step approach stops the model from pulling in too much data at once. It keeps its context focused.
And that alone makes answers far more accurate.
It also prevents the assistant from doing unsafe things. Because every tool has a defined purpose, the model can’t invent new actions or touch data it shouldn’t.
MCP takes guesswork out of the equation and replaces it with a simple rule. The AI can only do what the server explicitly allows.
This structure gives automation real stability. It’s clean, repeatable, and avoids the “black box” feeling
For Shake, this was a big leap. Their automation now follows clear steps, uses fresh data, and avoids the typical pitfalls of prompt-heavy systems.
The results are more accurate. And engineers trust the assistant more because they can actually see and understand how it works.
How Shake built its MCP server: FAQs
An MCP server is a piece of software that exposes your system to an AI model in a safe, structured way.
It tells the model what it can read, what it can do, and which workflows it can follow.
The server defines 3 things:
- Resources the model can access
- Tools the model can use to perform actions
- Prompts the model can follow as workflows
This structure gives you control, since the model can only do what the server allows.
In short, think of the MCP server as the bridge between your real system and an AI model.
No. The MCP server isn’t smart on its own.
It doesn’t generate answers or make decisions – it’s a structured gateway between the LLM and your backend, very similar to an API.
The server exposes data through resources, performs updates through tools, and offers templates through prompts.
The LLM decides when and how to use these pieces. The server just carries out the work safely and consistently.
Each tool in the MCP server comes with a clear description of what it does and when it should be used.
The LLM reads these descriptions and decides which tool fits the problem it’s solving.
This gives the model a reliable menu of actions instead of leaving it to guess based on vague instructions.
It also prevents the model from inventing actions or touching data it shouldn’t. If a tool isn’t described, the AI can’t call it. Simple as that.
Conclusion
Shake didn’t set out to build another AI experiment. They wanted something useful that works inside real engineering workflows, not around them.
Their MCP server is a big step in that direction. It gives their assistant a structured way to read data, take action, and stay reliable as models evolve.
And even though it’s still in testing, the foundation is solid. It already solves problems that hold many AI features back.
If you’re not familiar with Shake yet, their product is built for teams who take quality seriously. This work on MCP is just another example of how far they’re pushing that idea.
You can try it out and signup for free here.
