Exposing Agents as MCP servers with mcp-agent: Sarmad Qadri

My name is Sarmad, and today I want to talk about Building Effective Agents with Model Context Protocol, or MCP. So, a lot has changed in the last year, um, especially as far as agent development is concerned. I think 2025 is the year of agents, and things like MCP make agent design simpler and more robust than ever before.

So I want to talk about what the agent tech stack looks like in 2025. The second thing is, a lot of MCP servers today are just, you know, one-to-one mappings of existing REST API services to MCP tools. But MCP servers can be a lot more than that; they could even be agents.

And so I want to show how agents can be represented as MCP servers. And the last thing is a little bit of a look into agent architecture and modeling agents as asynchronous workflows, with workflow orchestration infrastructure like Airflow, Temporal, etc.

So, a little bit about me. I'm the CEO of Lastmile AI, and I've, in the past, been working on developer tools for a while, for many years. And back in 2016 to 2018, I was working on Language Server Protocol and Language Servers at Microsoft.

LSP revolutionized IDEs. Here on theright, you can kind of see the list of hundreds and hundreds of language servers that are now available. But before this, every IDE had to, uh, had a unique API surface, and so every language server had to implement, you know, a VS Code-specific way of doing things, or an Eclipse-specific way, and it was very fragmented as an ecosystem.

And LSP completely, you know, changed that by standardizing a single interface, API interface, for how language services should be exposed in IDEs. And so when, you know, LLMs took off, even before tool calling was a thing, I've been thinking about what it would take to make a LSP-style protocol for LLMs.

And I've been thinking about this for a long time. Here you have this, like, scratchpad from 2023, where this is the era of, you know, ChatGPT plugins. And I was thinking of how, you know, agent authentication should work, or how LLMs should be connected to tools, resources, data in some way.

And so Model Context Protocol, which Anthropic created a few months ago, has been a godsend, and I think it incorporates a lot of the things that are really necessary to get, you know, agents into production. And we'll talk a little bit about that.

Like I stated before, I think 2025 is the year that agents hit production en masse. Until now, there have been a lot of high-impact use cases that our customers see that have been stalled in proof-of-concept stage. Things like, you know, people want to work, do workflow automation, they want to deal with unstructured data and process it in interesting ways.

They want to do information retrieval. And you're starting to see agents appear in each of these categories already, and I think that pattern will accelerate in the coming months. So, what does this tech stack look like for agents in 2025?

There are three big, kind of, updates or changes that are happening, which I think allow you to build effective agents much more easily than ever before. So the first thing is better models. We have reasoning models and LLMs that are pretty reliable for a lot of use cases.

And with test-time compute, a lot of the complexity, things like, you know, chain-of-thought reasoning, or React, or other kind of patterns that had been implemented at the framework layer, are actually now shifting left into the inference layer. And all that allows is for less complexity and less burden for app developers, because they can get a lot more done by just invoking a model API than ever before.

The second thing is Model Context Protocol, or MCP. For folks who are not familiar, MCP is basically a standardized interface for connecting LLMs to tools, to data, to resources, to the world around them. And so the really revolutionary thing about it is that it is a single way, it provides a single interface to connect and give context to LLMs.

Whereas in the past, there used to be, you know, a multitude of data connectors that were platform-specific that you would have to integrate with. And MCP has taken off. You know, Google, OpenAI, Microsoft, many other companies, potentially competitors, have all kind of coalesced around MCP.

And so it is going to become the de facto standard for how LLMs connect to the world around them. And the last part that's really changed in the last few months is, there are simpler architectures for how agent applications should look.

Agents today, unlike the past, are now simply, you know, orchestrators of better models and MCP, and connecting LLMs to these tools and resources using these standard protocols in some well-defined patterns. There's no longer a need for monolithic AI frameworks that did a lot of heavy lifting at the framework layer in the past.

Now you can have simple agent patterns, you implement them with standard protocols, with good LLMs, and you can get a long way. And just to show you, Anthropic at the end of last year, beginning of this year, released this very influential blog post called [Building Effective Agents].

And in it, they highlighted a couple of agent patterns that work well in production from their experience with, you know, deploying agents into enterprises. And so the simplest example of this pattern is this thing called an augmented LLM, which is basically an LLM that has access to tools and resources or data.

And you basically, you know, it's the base building block. You run this LLM in a loop, it gets an input, it may call tools, it may retrieve data in order to do its job, and it runs, you know, several iterations and returns a response at the end.

And then you can build more interesting patterns on top of that. So then you could have an augmented LLM, which is the optimizer that generates a response, and you can connect it to another augmented LLM, which is the evaluator, that evaluates the quality of the generated response and gives feedback to the generator LLM to see what it could do better.

And this process happens over, like, a set of iterations until the evaluator LLM is happy with the quality of the response, and then it, you know, returns the final response to the user. You could have, you know, distributed systems practices like fanning out to multiple sub-agents and then fanning back in to aggregate the results.

And perhaps the most sophisticated one, which we're starting to see in tools like Claude Code and other, you know, agentic systems, is this idea of an orchestrator, where you have one LLM that does, that generates a plan and assigns tasks to sub-agents dynamically, and then synthesizes the results before responding back to the user.

And this process can also run in a loop, but really the idea is that there is a planner that is reasoning and deciding what to do next, kind of dynamically.

So, what I did towards the end of last year, as part of my Christmas break, was I wanted to build an agent library that implemented all of the patterns that this Building Effective Agents blog post had, and basically was very opinionated about the world being MCP native in the very near future.

And so that's what I built. It's called MCP Agent. It's on GitHub, you can check it out. And it is basically making a few very key opinionated choices. One is that MCP is going to be everywhere. So every line of business application, think like, you know, Notion, Google Docs, Cursor, or Claude, is soon going to be an MCP-compatible client.

So that means that it could connect to MCP servers. And on the flip side, I think every service, this is already starting to happen, is going to have an MCP server equivalent for it. And so you're going to see things like, you know, a linear MCP server, a GitHub MCP server, and any kind of like SaaS product that needs to expose itself to LLMs will have an MCP server.

The second thing that I'm going to show in a little bit is that agents should be thought of as microservices, and they can be deployed as MCP servers themselves. And as we'll talk about in a little bit, that actually gives a lot of benefits on how multi-agent interactions can work.

And the last part is agents are async workflows, and they should be modeled as such, because they can be paused, resumed, retried, you may have a human in the loop, and that's really a workflow orchestration that's asynchronous instead of something that's, you know, happening in your chat session in-proc.

You know, if you think of agentic behavior in the MCP world today, it all happens on the client side. So you use Claude or Cursor, and they in turn use MCP servers to solve your, the tasks you give them.

But what if agents themselves were exposed as MCP servers? In that case, if you connect an agent as an MCP server to an MCP client, then that client can invoke that agent, it could coordinate across multiple agents, it could orchestrate, similar to the patterns I showed you, the same as it does today with any other MCP server.

Also, you could do multi-agent communication also over MCP. So agents can then invoke other agents. In this diagram, you kind of see an MCP client that's connected to MCP, regular MCP servers like GitHub, Slack, Linear, etc. But it's also connected to agent servers.

And these agent servers, in turn, can connect to other MCP servers just over the base MCP protocol. And so then you can kind of get multi-agent collaboration and coordination for free. The MCP client can invoke, in this case, MCP agent server A, which in turn may invoke other MCP servers, or it may even invoke other agents.

And as a result, you basically have this network of agents that may get activated from a single command that a user sends through Claude, Cursor, or some other MCP client. So what are the benefits of this? If you expose agents as MCP servers, the first thing you get is composable agents.

Like I mentioned, you have complex multi-agent systems that can operate over the same base protocol that everybody's adopting. We know MCP is going to be a common standard, and so we can safely build on top of it. The second thing is you get platform-agnostic agents.

You can build these agents once, and then you can reuse them anywhere that is MCP-compatible. And finally, you get scalable agents. If you run agent workflows on dedicated infrastructure, then you can kind of separate the, where the agent is, where the agent compute is happening from the client that is being used to invoke the agent.

And that gives enormous benefits in terms of, you know, scalability, performance, and durability as well.

So I've talked about agents as async workflows. What I mean by that is that agents can be paused and resumed. They need to await on human feedback in some cases. They may fail, and then they need to be retried.

Agents could be triggered or scheduled. It's not just a chat application that is agentic. You could have a webhook that triggers an agent, or a cron job that, you know, triggers an agent every, every day or every week or something.

And so theright way to model all of this is as asynchronous workflows. And so that's what we do in MCP Agent as well. We use temporal as the durable execution backend to do the compute or the orchestration of agent execution.

So let's do a quick demo to show what all of this looks like, just to make it more real. So the first thing you'll see here is I have this task that I want to build an agent for.

In this case, it's a fairly complex task. I'm asking an agent to load the student's short story from a Markdown file, which is this, but we assume this is a student's short story. And then I want to generate a report, basically grade this short story across proofreading, factual and logical consistency, as well as style adherence.

And by the way, for the style adherence, I want to use the APA style guide from this URL. And finally, I want to write that graded report to the Markdown file, graded-report.md. So the agent that I've created here is actually going to do a couple of things.

But first, I connect it to a couple of MCP servers. I have the fetch MCP server, which can connect to URLs and get fetch data from the internet. And I have the file system MCP server to interact with the file system.

Soright off the bat, because of MCP, I don't need to interact with the file system or interact with the internet and fetch URLs in a unique way. It's all over the same base protocol, and it's all exposed as tools from these MCP servers.

And then I define a couple of these agents, where I have a finder agent that can fetch content from the internet or from disk. I have a writer agent that can write stuff to disk. I have a proofreader, a fact-checker, a style enforcer.

And then I have an orchestrator recall from, you know, those agent patterns I showed you. This one will basically generate a plan given the task, and it will use, it will orchestrate these agents that I've defined in a way that it sees fit.

So this workflow is about like 100 lines of code, and that, it's still doing something fairly sophisticated. So if we run this, we're going to use temporal to run this. And so I'll kick this off, and you'll see that the worker job has triggered, and it's going to start executing.

Workflow UI, you see that there is a workflow that's been triggered. And the first thing you'll see that the agent does is it actually generates a plan. So over here, you see that it's broken down the task I gave it, the fairly complex multi-step task, into a series of steps that it's going to do.

First, it's going to load the student's short story, and it's going to use the finder agent for that. In turn, the finder agent is going to use the file system MCP server. Then it's going to analyze the short story using the proofreader, the fact-checker, the style enforcer.

And finally, it's going to generate the graded-report.markdown file and write with the writer agent. And so then you see that the agent is executing. There's a whole workflow graph. This can fail at any step and can be retried.

It can be terminated. It can await for human feedback. And here you see that it already completed. So we should have a graded-report.markdown file that's generated for us. And if we see what's in it, you can kind of see that it did what I asked it to.

Factual consistency, APA style guide. It was able to do all this correctly. Lastly, you can actually do the same thing now by exposing this agent as an MCP server. You can connect it to an MCP client like Claude Desktop.

Here I have the agent exposed as an MCP server, and you see that it exposes itself as workflows. And so I gave it the same short story here, and I asked it to grade it with this basic agent.

And so what it does is it runs the workflow, it gives the input of the story, and then it pulls for the status of that workflow job. Because note that the agent is executing in a different execution environment.

I could close my Claude Desktop and come back, and it can check the status of that workflow and get me the results at a later date. And so the asynchronous nature of this work, of this agent, helps me kind of, you know, kick off agent tasks from anywhere.

And then it, like, once the agent completes, it presents me the report over here. And so I can still use this agent in a chat bot environment. I can run this agent anywhere that is MCP compatible. Thank you all for listening to this.

There's a lot more that you can do with agents because of the revolution that MCP is causing. I'd love to chat more in general about the future of agents. So you can come find me over email, Twitter, or GitHub.

Thank you.