This is super cool! We use a similar approach for CheepCode: our agent process connects to an MCP server that then "drives" the rest of the interaction.
This paradigm feels like the obvious next step for agents. It more closely models human interaction (to the degree that this is desirable) and unlocks a lot of optimizations + powerful functionality.
This is a fascinating evolution of the MCP ecosystem. How are you thinking about agent discovery, authentication, and trust in a world where agents are both clients and servers
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.
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.
Agents should be given a time budget, which they can allot to other agents as they see fit. And it's easy to enforce: you kill the process after the allotted time.
That's a valid concern. In `hacker-news-agents`, we're exploring ways to manage the complexity of multi-agent interactions. Perhaps a structured approach to agent communication and state could mitigate some of that 'microservice hell' feel.
Super cool direction. Making agents first-class MCP servers feels like a natural next step—especially for scaling multi-agent coordination across infra boundaries. Curious how you’re handling observability at the server level—do you expose structured logs or telemetry for workflows running across agents? This could be huge for debugging large-scale agentic chains.
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.
This is super cool! We use a similar approach for CheepCode: our agent process connects to an MCP server that then "drives" the rest of the interaction.
This paradigm feels like the obvious next step for agents. It more closely models human interaction (to the degree that this is desirable) and unlocks a lot of optimizations + powerful functionality.
It is going to be an exciting rest of the year!
This is a fascinating evolution of the MCP ecosystem. How are you thinking about agent discovery, authentication, and trust in a world where agents are both clients and servers
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.
Really cool, but it seems like recursive agents are going to bog down into microservice hell.
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.
Agents should be given a time budget, which they can allot to other agents as they see fit. And it's easy to enforce: you kill the process after the allotted time.
Agreed. Time, token, cost budget caps would be a great addition. Will add it as a feature request :)
Yeah, that was my first thought. I actually wrote a blog post a few weeks ago modeling the point at which agent recursion really gets out of control. https://www.neuralwatt.com/blog/agent-bedlam-a-future-of-end...
That's a valid concern. In `hacker-news-agents`, we're exploring ways to manage the complexity of multi-agent interactions. Perhaps a structured approach to agent communication and state could mitigate some of that 'microservice hell' feel.
This a bit confusing, and maybe I am missing a piece of the puzzle, are mcp agents and mcp clients being used interchangeably?
This diagram might be helpful: https://pbs.twimg.com/media/GrgGy2jWQAAittE?format=jpg&name=...
i've used this repo, it's a great starter pack
That's great to hear! We'd love to know more about your experience and any thoughts you have on it.
Would love your feedback on the Temporal support and the MCP agent server concept which we merged in yesterday
Super cool direction. Making agents first-class MCP servers feels like a natural next step—especially for scaling multi-agent coordination across infra boundaries. Curious how you’re handling observability at the server level—do you expose structured logs or telemetry for workflows running across agents? This could be huge for debugging large-scale agentic chains.
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.