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.
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.
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
I've seen a number of them. Some are a simple listing, others do some level of validation and ranking based on various heuristics, others are an actual service that will run the mcp servers for you in an encapsulated form so that it becomes more of an app store-like experience and you don't need to do manual configuration in your client. mcp.run is basically this - they run the servers in a webassembly sandbox for you. I'm probably not doing it real justice, but it's a really interesting concept in a very interesting space(MCP) right now.
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.
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.
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.
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!
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
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.
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
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. :)
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.
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.
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
https://glama.ai/mcp/servers/
https://www.mcp.run/
I 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.
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
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. :)
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.