saqadri

Hey folks, Sarmad from the LastMile team here that built MCP-c and mcp-agent.

We're looking for thoughts and feedback so will be happy to take any questions here! And as the post shows, it's really easy to try this out -- would be grateful for you to try deploying an agent as an MCP server and get your impressions!

Thanks for sharing this! We've reached out to the benchmark owners are are going to get our deep research agent benchmarked soon.

Thanks for sharing, this looks great! Do they have an MCP server? It should be easy to wrap around their JSON API but I couldn't see MCP support in the repo/docs.

Haha, I didn't have control on the blog website, just the content. The readme and code is the ultimate source of truth (and easier to read):https://github.com/lastmile-ai/mcp-agent/blob/main/src/mcp_a...

So the core idea is the Deep Orchestrator is pretty unopinionated on what to use for searching, as long as it is exposed over MCP. I tried with a basic fetch server that's one of the reference MCP servers (with a single tool called `fetch`), and also tried with Brave.

I think the folks at Jina wrote some really good stuff on the actual search part: https://jina.ai/news/a-practical-guide-to-implementing-deeps... -- and how to do page/url ranking over the course of the flow. My recommendation would be to do all that in an MCP server itself. That keeps the "deep orchestrator" architecture fairly clean, and you can plug in increasingly sophisticated search techniques over time.

OP here -- I think the general principle I would recommend is using a big reasoning model for the planning phase. I think Claude Code and other agents do the same. The reason this is important is because the quality of the plan really affects the final result, and error rates will compound if the plan isn't good.

This is so cool. A big reason I used prisma was for prisma studio. Having this kind of support in vscode is nice to see

This diagram might be helpful: https://pbs.twimg.com/media/GrgGy2jWQAAittE?format=jpg&name=...

Agreed. Time, token, cost budget caps would be a great addition. Will add it as a feature request :)

I think that's a fair point. How I envision this to realistically evolve is that MCP servers will expose workflows that handle common tasks. These workflows will be "agentic" because they'll involve LLMs interacting with tools and data, and it will be facilitated over MCP. For example, it would be great to have a "triage" workflow agent exposed by Linear, which in turn might use some MCP servers to make tool calls etc.

I don't know of a usecase where there are such deep recursive agent chains that it becomes unmanageable.

I almost think of mcp-agents as a modern form of scripting – we have agent workflows (e.g. generating a summary of new GitHub issues and posting on Slack), and exposing them as MCP servers has enabled us to use them in our favorite MCP clients.

This is exactly what we're working on at the moment! (If you're curious about following along progress, check out feature/distributed_tracing branch -- https://github.com/lastmile-ai/mcp-agent/tree/feature/distri...)

The nice thing about representing agents as MCP servers is we can leverage distributed tracing via OTEL to log multi-agent chains. Within the agent application, mcp-agent tracing follows the LLM semantic conventions from OpenTelemetry (https://opentelemetry.io/docs/specs/semconv/gen-ai/). For any MCP server that the agent uses, we propagate the trace context along.

Authentication and authorization is something we are thinking about a lot at the moment, especially for agents that are MCP servers.

Our thoughts here are to handle auth the same way that the MCP spec outlines auth (https://modelcontextprotocol.io/specification/2025-03-26). The key thing is to send authorization requests back to the user in a structured way. For example, if Agent A invokes Agent B, which requires user approval for executing a tool call, that authorization request needs to be piped back to the client, and then propagated back to the agent.

This is technically possible to do with the MCP protocol as it exists today, but I think we will want to add that support in mcp-agent itself so it is easy to pause an agent workflow waiting for authentication/authorization.

One nice property of representing agents as MCP servers is that Agent discovery is the same as server discovery.

Would love your feedback on the Temporal support and the MCP agent server concept which we merged in yesterday

You should comment on the issue! I would love native support as well, but I also understand the desire to keep the framework lightweight. It should be fairly straightforward to add an extension package

Creator of mcp-agent here, OP and I are going to be keeping these projects in sync, and build agent apps on top of these patterns. MCP is pretty new and people are adding lots of servers for different software services. I think the next step is exposing agents (i.e. compound AI workflows) themselves as MCP servers.

In addition to simple abstractions for declaring agents, fastagents has a really nice CLI utility, which can be useful for interaction with MCPs outside of Cursor and Claude Desktop, where they are most popular atm.

Reach out when you get started!

These notes are really great!

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

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

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

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

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. :)

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

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!

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

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