Skip to content(if available)orjump to list(if available)

Show HN: Mcp-Agent – Build effective agents with Model Context Protocol

Show HN: Mcp-Agent – Build effective agents with Model Context Protocol

24 comments

·January 29, 2025

Hey HN, I spent my xmas break building an agent framework called mcp-agent [1](https://github.com/lastmile-ai/mcp-agent) for Model Context Protocol [2]. It makes it easy to build AI apps with MCP servers, and implements every pattern from the popular Building Effective Agents blog [3] as well as OpenAI’s Swarm [4]. I’m sharing it early to get community feedback on where to take it from here, and to ask for contributions.

For those who aren’t familiar with MCP, I think of it as a standardized interface to let AI communicate with software via tool calls, resources and prompts.

mcp-agent provides a higher level interface to build apps with MCP. It handles the connection management of MCP servers so you don’t have to. It also implements the Building Effective Agents patterns: - Augmented LLM (an LLM with access to one or more MCP servers) - Router, Orchestrator-Worker, Evaluator-Optimizer, and more - Swarm

The key design principles are composability and reusability – every pattern is an AugmentedLLM itself, so you can chain them into more complex workflows.

Some background: I worked on LSP [5] and language servers at Microsoft, and saw firsthand how standards and protocols can revolutionize developer workflows. Before LSP every IDE had its own esoteric ways of providing language services. LSP changed all that, and arguably made every language server better, since they can focus on improving a single implementation for all clients.

I think AI development is in a similar pre-LSP space right now. There are tons of frameworks [6], every model provider has its own way of handling messages, tool calls, streaming, etc. I really think we need a protocol to standardize these patterns.

Pretty soon every service is going to expose an MCP interface, and mcp-agent is about letting developers orchestrate these services into applications (i.e. build “MCP apps”). This can cover any use of an AI model that needs to interact with the world around it: - RAG pipelines and Q&A chatbots - Process automation via AI workflows/async tasks - Multi-agent orchestration, with human in the loop

The repo contains examples [7] to build RAG agents, streamlit apps and more. There’s a lot left to build, like streaming support, server auth and tighter integration with MCP clients.

But I wanted to share early in the hopes that you can guide me: - If you find this useful, please let me know. If it’s useful to you, I will dedicate all my time to improving it. - I really welcome contributions. If you want to collaborate, please reach out on github to help take this forward.

I want to help standardize AI development, so developers a few years from now can look back with horror at the pre-MCP days.

[1] - https://github.com/lastmile-ai/mcp-agent

[2] - https://modelcontextprotocol.io/introduction

[3] - https://www.anthropic.com/research/building-effective-agents

[4] - https://github.com/openai/swarm

[5] - https://microsoft.github.io/language-server-protocol/

[6] - https://xkcd.com/927/ (I understand the irony)

[7] - https://github.com/lastmile-ai/mcp-agent/tree/main/examples

a1j9o94

This is really interesting. Has anyone seen a good registry of MCP servers somewhere? What I would love to be able to do is ask for a task and have the agent figure out what servers and tools it needs to accomplish that task directly.

auntad

There's a number of people building various flavors of this. I'm one of them -- pulsemcp.com - we expose our data via API (pulsemcp.com/api) that is theoretically the starting point for what you're asking.

The issue with the current state of the ecosystem to do what you're saying is that server implementations all have extreme variances of quality. Some are very robust and reliable. Others have very poor and limited UX, if you can even get them to start up on your local machine.

So we're not really in a place where we can trust that a server "does what it says it can do [well]", and so any autonomous solution to "choose tools (servers)" probably won't work well today (yet) while the signal to noise ratio is poor.

Personally: I think autonomously choosing between tools is not the most compelling approach in the short to medium time horizon. I expect client application creators to get a lot of mileage by thoughtfully curating the possible servers exposed to their users, and building nice UX to integrate usage of relevant servers as-needed.

saqadri

This is something I have thought a little bit about. I think a registry would be useful and I know a few projects trying to set that up, but there may be multiple MCP servers for the same thing (already there are a few community implementations of an Atlassian server for e.g.).

It is conceivable that we make it completely dynamic where the agent first decides which set of servers it should need for its task/instruction. Another way of framing that is it should be possible to create agents themselves dynamically based on the objective.

I don’t have a good answer to this yet but if you want to help figure that out we can collaborate

nilslice

mcp.run is your friend! it’s actually much more than a registry, but a whole control plane to dynamically install servlets into your apps or agents.

sparacha

OP - congrats on this launch! I think there are a lot of useful bits here, especially the communication abstractions for MCP and having clear recipes to implement patterns mentioned by Anthropic team is a big plus.

exclipy

This looks very nice, and obviously needed in hindsight.

I would love to see a Typescript/node port of this.

VenturingVole

Seconding this, it looks exceptionally cool and will dig into it a little further later as I've got a use case within a product I'm building which would also call for a TypeScript version.

saqadri

Would love to get in touch! Happy to prioritize a TS implementation if that's a popular ask.

VenturingVole

I haven't been hugely focused in the agent space for the last few months, so want to get myself up to date a bit as there's potential I could fairly quickly contribute in a few ways - including porting to TypeScript.

I'll then either send you an email or jump onto your Discord.

saqadri

You know, I personally would love that too. TypeScript is my favorite language and tons of infra is built on Node now. Would you like to collaborate on building an mcp-agent.js? I think it can be done within a week or so. Let me know!

exclipy

Actually, I would be interested! I'll get in touch

saqadri

Amazing, looking forward to it. My email is on my account, but feel free to just create an issue in the GitHub and we can get started that way

saqadri

Please let me know if you have any questions - I'll be monitoring the post today and would love to discuss!

justintorre75

MCP Agent seems super promising and the team behind it is amazing!

lgas

Isn't the poster the whole team?

saqadri

It’s possible commenter is referring to my team. But yes this project was solely my fault :D, along with a few amazing contributors from the open source community who are credited in the readme

nurettin

What's so special about this other than poisoning straightforward python code with async/await?

Claude message API already accepts a tools=[] parameter. All you need is a json schema of your python class and docs which you can easily generate with a few dozen lines of code.

Then just call whatever the LLM outputs like getattr(instance, result["name"])( **result["kwargs"]) and your computer is controlled by AI congratulations.

wedn3sday

The example code reminds me how much I absolutely loath python async/await syntax.

>>> server_names=["fetch", "filesystem"]

This is, IMO, bad design. Where is the fetch defined? How would I find these? If it was an imported module I could easily find the definition to see what its doing, or subclass it to make my own, but instead its just some magic strings getting passed making it astronomically more difficult to understand what the heck is going on.

saqadri

Ah, just saw your edited comment. I am open to suggestions about this. These names are defined in the mcp_agent.config.yaml (e.g. https://github.com/lastmile-ai/mcp-agent/blob/main/examples/...). The logic that manages keeping track of them is mcp_server_registry.py.

I am open to alternative suggestions for this. I just wanted to make it easy to reference MCP servers by name and hide the logic of how they are initialized, what transport they use, what args are passed to them, into configs

saqadri

Haha, are you referring to the async context managers? I have an example that calls .initialize and .cleanup explicitly: https://github.com/lastmile-ai/mcp-agent/blob/main/examples/...

Python isn't my first programming language and I find a lot of it peculiar, but with some of the latest tooling around it (uv, ruff, etc.), I must confess it has grown on me. :)

shrisukhani

this is neat - congrats!

null

[deleted]