Show HN: Mcp-Agent – Build effective agents with Model Context Protocol (github.com)
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
30 comments
[ 4.0 ms ] story [ 88.3 ms ] threadI would love to see a Typescript/node port of this.
I'll then either send you an email or jump onto your Discord.
>>> 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.
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. :)
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
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
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.
https://glama.ai/mcp/servers/
https://www.mcp.run/
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.