How MCP helped my team do more with less

2025 has been described as “the year of the agents”, and MCP is the protocol that is powering the connection between LLMs and agents. 

MCP, or model context protocol, is the latest AI concept to go viral. Right now, my LinkedIn feed is full of posts about MCP, generally focusing on the technical details. But the important questions engineering leaders are asking are “Why should I care? Is this just hype?”

In this post, I dig more into how MCP can bring value to any organization, allowing knowledge workers to be more productive and engineering teams to deliver AI apps faster and easier.

What is MCP?

MCP has been described as the USB-C for AI agents. It’s a protocol that defines a standard way for AI-powered applications to interact with agents via tools – functions that can be called on the agent to do something or return information. 

It essentially allows AI apps to speak the same language. Agents can describe their tools in natural language, AI apps can pass these descriptions to an LLM, and the LLM can decide which tool to call.

Apps that provide tools are known as MCP servers; apps that consume these are known as MCP client apps (strictly, these are host apps, and the LLM is the MCP client, but the term MCP client is being used for the host apps).

How MCP makes complex integrations simpler

The implementation of MCP is surprisingly simple but very powerful. 

For example, if you want to extract information from a database and send it in an email in an AI app, you would use 2 MCP servers. One would be able to query your database, the other would be able to send an email.

The database MCP server would have a tool such as get_order_details described as “gets the details for an order including the product and customer details”. The email MCP server would have a tool for send_email. These tools would be parameterized in that they describe parameters that have to be sent to them, such as the customer ID, order ID, and recipient, subject, and body for the email.

Once these tools are connected to an AI app, you could prompt it with “Get the details for order 66. Send the order status to the customer in an email”.

The LLM would be able to determine from this prompt and the details about the tools that it needs to:

1. Call get_order_details on the database MCP server to get the details of the order, including details on the product ordered and the customer who ordered it.

2. Summarize the order details, then extract the customer's email from the order details. Send that email, a generated subject, and an email body generated from the order details to the send_email tool on the email MCP server.

Whilst this sounds like a pretty typical flow where you manually connect APIs from different tools and services, the big difference here is that the MCP server has a standard interface, and you connect it with a couple of configuration fields instead of writing code. You can wire send_email up to any MCP server just through configuration and instantly send emails.

My colleague Ellie wrote a great blog post with a detailed overview if you want to learn more.

The value MCP brings to your organization

Whilst all this sounds cool from a technical level, the important question is, why should you care? What benefit is there to an organization by leveraging MCP?

There are multiple benefits, mainly based around boosting the productivity of folks using AI tools, and reducing time to delivery of AI-powered apps.

Faster integrations

MCP allows supporting apps to be integrated with minimal effort and speeds up integrations between components of an AI-powered application. 

❕Faster delivery means lower development costs and faster shipping of a product or new features, allowing your customers or your employees to do more in less time.

Integrations with existing tools

For example, if you are a developer using Cursor or GitHub Copilot, you may need to check the details of a GitHub issue that you were looking at previously. 

You could jump from your IDE into your browser, look for the ticket, copy the details, head back to your IDE, and then paste it into the AI chat. 

But we all know that these context switches impact your productivity and lead to distraction. 

Instead, you could add the newly announced Pieces MCP server to your IDE and ask, “What was the GitHub issue I was just looking at in my browser? 

Give me all the details of the code change I need to make”. This gives you the details of the ticket inside your AI chat, where you can then ask the agentic coding tools to generate the relevant code for you.

This is one example, but imagine the productivity boost when this is scaled up to include crash reports in tools like sentry, database queries, access to discussions in chat tools around the work that needs to be done, researching packages and tools on the web, and many other day-to-day activities that can now be done without leaving your IDE.

Integrations in your own apps

If you are building an AI-powered app, chances are you want to integrate with many other components, both first and third party, for agentic workflows.

Rather than having to understand the API or SDK for the component you want to integrate with, you add MCP client functionality to your app, and then any component that has an MCP server can be registered. 

Your app needs to make one call to each MCP server to get the list of tools, pass this to the LLM with each call, and then process the response from the LLM that contains instructions to call the relevant tool and pass the parameters. You do this just once, then any MCP server will work.

You may even have this built in already – popular AI frameworks like LangChain, LangGraph, and Semantic Kernel all support MCP and will do the heavy lifting; you just need to tell them about the tools.

Integrating your product into other tools

If you are building a component or service for third parties to use, then supporting MCP allows your users to integrate your product much faster. They are not relying on complex API references, SDKs, and lots of documentation, instead, you create an MCP server that provides all the instructions that an LLM can use to call your product.

By adding an MCP server, you open up your product to AI developers. If you don’t, your competitors will.

Common API surface for your developers

This speed of integration is all down to a common API surface area. MCP works over either stdio or HTTP, with a well-defined JsonRPC spec. There are also standard SDKs to provide the implementation in Python, TyeScript, Java, Kotlin, Rust, C#, and more.

• This means whatever you are building, be it a server or a client, you have a single standard to follow. This makes it faster to build and reduces the need to develop and document APIs. Less code to write, less bugs, faster shipping of more reliable software.

In your client app, once you have code to extract tools from an MCP server and send them to the LLM, then any MCP server will work. Many LLMs support tool calling, so you can use a huge variety of LLMs in your apps, and they will work with the same MCP servers.

• If you are building a component or service that will be called by an AI app, then you can just implement MCP instead of a more complex API with a range of SDKs.

If you have existing legacy APIs that you need to integrate, you can write an MCP server that wraps the API, making it readily available to any MCP client that wants to use it. Write once, use everywhere across the organization.

As long as your developers understand MCP, then they have a common development platform.

Focus on user-centric API design and documented servers

The ‘API’ of MCP is natural language. MCP servers define in natural language what each tool is and what parameters it expects. It has to be clear and concise so that an LLM can call it. This has 2 benefits:

User-centric design

The tools have to focus on a user-centric design. Often, APIs match the organizational structure or database structure. 

Instead of considering the ways a user will interact with a system, they focus on CRUD over a database table or have different APIs for features shipped by different teams that are not cohesive.

When you have tools that are called by an LLM, you need to consider the actions a user will take rather than simply having tools to create, replace, update, and delete a record in a database. This helps you to consider the user and design the tools based on what they would do.

In the example above, I mentioned an MCP server to get order details that returns those details, along with product and customer details. 

In a bad API, this would be 3 calls – one to get an order, then calls to get the product and customer details using ID fields in the order.

In the real world, a user would want all these details in one response. You could create multiple tools that get called, but there is a risk the LLM will not correctly call the tools in order. To get the best response, the tool should mimic the user's actions so there are fewer tool calls per request.

By having the natural language interface as a forcing function, you are more likely to build a better interface for your customers and a better product.

Good documentation

This is inherent in the nature of MCP servers. 

You have to have them well documented, otherwise, the LLM won’t know what tools to call. 

When your MCP server defines a tool, it has to provide a clear name and description for the tool and any parameters that it expects. This is provided in code to the client, so has to be built in to your app. These details have to be clear enough for the LLM to know when to call your tool and what information it needs to extract from the prompt to fill out the parameters.

If the documentation is bad, the tool just won’t work.

Developers praise good documentation and complain about bad; after all, documentation is part of the product. If it’s not documented, it doesn't exist. 

Unfortunately, developers rarely want to take the time to build out their own docs, or support their documentation teams. By embedding good documentation into the API of the tool, you are forcing developers to write and test the documentation.

How do my engineers leverage MCP?

MCP can be leveraged by engineers in many ways. By combining these, they get a substantial boost in their productivity, driving down developer costs and speeding up time to delivery.

Faster access to information with reduced context switching

Developers live in their IDE. Every time they context switch and leave their IDE, that reduces their productivity and has an increased chance of distraction. 

Going to a chat tool to check on a previous conversation means they will read new messages that may not be relevant, researching in their browser to find something opens up a rabbit hole of reading news or other articles. 

Every distraction pulls the developer out of their state of flow.

If you can provide the information developers need in their IDE, they stay more focused. By using MCP servers from an MCP client like Cursor or GitHub copilot, engineers can query traces, look up tickets, or get information from their chat tools inside the same copilot chat they use to understand and generate code. No context switching, reduced distractions.

Faster time to connect components in the AI apps they are building

If you are building AI powered apps, and calling different systems for information based on the interactions with the LLMs, then MCP allows you to very quickly bolt on new tools, without having to extract the intent from the user in code, then use this to call an API that you may not understand and need time to learn. 

Adding tools almost becomes configuration instead of code, setting a URL or command in a configuration that your AI framework reads to register the tools, allowing them to just work.

❕This can reduce the time to connect components by days or even weeks. Your developers don’t have to waste time learning an API to use once, instead, they can focus on adding the core logic to the applications they are building.

Downsides of MCP

Whilst having a common protocol and simplicity of connection that adds value, MCP is not always a perfect solution. There are a few downsides.

LLMs are non-deterministic

You can have the most perfect MCP tool, defining in clear, concise language what it does and what parameters it needs, and the LLM can still decide not to call it, or to call it badly. LLMs are non-deterministic and often make mistakes or hallucinate.

This means that there is no guarantee that the MCP server will be called or be called with the right parameters.

Unlike traditional app development, where you write the code to explicitly make calls, the decision lies solely with the LLM. If you are developing against an MCP server, you may need to build in checks and retries. If you are using an MCP server in a third-party app, you may need to improve your prompts or retry repeatedly.

Tokens cost money

When you call a cloud based LLM, you have to pay based on the number of tokens you send and receive. Even if this LLM is in your cloud infrastructure, calls cost CPU/GPU time, which costs money.

When you use an MCP server, you use a lot more tokens:

• The details of every tool you use is passed to the LLM with every call. This uses a lot more tokens.

• In most scenarios, the flow is: call LLM → get back a request to call a tool → call the tool -> send the tool response to the LLM. This is 2 LLM calls, which again you pay per token.

• If the LLM decides not to call the tool, and you need to re-prompt, that is more tokens.

If you use a traditional API call, you don’t have to send tokens defining the tools, and you can get the data you need up front, so you only need 1 LLM call.

If you roll out MCP based apps to your organization, you may need to evaluate the additional cost of using more tokens, with the reduced development costs due to faster integrations.

Limited range of LLMs

Not all LLMs support tool calling, so won’t work with MCP servers.

For example, Phi-4 came top for accuracy in my recent LLM benchmarking, but the base Phi-4 model doesn’t support tool calling, instead, you have to use the Medium or Mini variants, which may not give as good results. 

If you want to use local LLMs, then some of these don’t support tool calling.

The same with cloud models – some may not support tool calling or not be great at it. For example, all current Claude models support tools, but they don’t recommend you use 3.5 Haiku, as it is not great at getting the parameters correct.

Authentication, authorization, and access control

MCP is a simple protocol and is only just starting to get basic authentication with the latest protocol specifications supporting oAuth. As a protocol, it lacks a lot of the controls that are needed for good governance. 

This means your CISO, CTO, or AI governance teams may have issues with connecting apps to MCP servers.

Controls can be added at the MCP server level, just leaving the risk of unauthorized clients connecting. 

This is an area that is under active development and should be strengthened in the future.

Pieces LTM-2 + MCP

At Pieces we understand that saying in flow is important for developers. We know developers want access to their activities via the Pieces Long-Term Memory so that they can gather the project context they need quickly. We also know that developers want to use as many tools as possible from one place, and avoid context switching, hence the massive ecosystems of IDE extensions and plugins.

Pieces has extensions and plugins for a variety of tools developers use everyday, such as VS Code, JetBrains IDEs, and browsers like Chrome and Edge. Because MCP allows teams to access more context in the tools they are using, it made complete sense for us to create an MCP server in PiecesOS. This means that you can add Pieces as an MCP server in tools like Cursor or GitHub copilot, then query the long-term memories from these tools interweaved with your normal daily developer workflow in the agentic chats.

As a real world scenario, one of our developers was discussing package versions in a Google Chat, then looked up some packages in their browser, then was able to not only ask Cursor to recall the package versions, but automatically update the relevant package files. Vibe memory + vibe coding!

You can even take these integrations further as engineers and build out solutions that can connect to Pieces and access memories for custom applications. By supporting MCP we have opened up Long-Term memories to our users in any form they wish.

Going forward

The pace of AI change is rapid, but underlying protocols like MCP will be with us for a while. It opens up so many capabilities, making it easier to connect the AI tools we use with other systems, reducing the time to integrate tooling and agentic workflows into our AI apps.

As developers leverage agentic workflows to make them more productive and as apps are built that use tool calling and agents to empower knowledge workers and automate systems, having this common means of connectivity means we can all use agents with less effort.

If you are not already, you need to be looking into MCP, seeing which servers and clients can help your organization, and being prepared for the governance challenges it brings.

Pieces recently announced an MCP server so you can connect to your Pieces Long-Term Memory from any MCP client. 

Give it a try, and share your thoughts on MCP and what having Pieces available over MCP unlocks for you on X, Bluesky, LinkedIn, or our Discord.