[HN Gopher] Show HN: Representing Agents as MCP Servers
___________________________________________________________________
Show HN: Representing Agents as MCP Servers
Hey HN! A few months ago we shared mcp-agent
(https://github.com/lastmile-ai/mcp-agent) [1][2], a lightweight
framework that implements every agent pattern from Anthropic's
Building Effective Agents blog [3] and handles MCP server/client
management seamlessly. Our core bet is that connecting LLMs to
tools, resources, and external systems will soon be MCP-native by
default. Today we're launching a significant update: Agents as MCP
servers. Currently "agentic" behavior exists only on the MCP
client side - clients like Claude or Cursor use MCP servers to
solve tasks. With this update, Agents can be MCP servers
themselves, so that any MCP client can invoke, coordinate and
orchestrate agents the same way it does with any other MCP server.
This paradigm shift enables: 1. Agent Composition: Build complex
multi-agent systems over the same base protocol (MCP). 2. Platform
Independence: Use your agents from any MCP-compatible client 3.
Scalability: Run agent workflows on dedicated infrastructure, not
just within client environments 4. Customization: Develop your own
agent workflows and reuse them across any MCP client. How an agent
server is implemented: We've implemented this in mcp-agent with
Workflows. Each workflow is an agent application that can interact
with other MCP servers (e.g. summarizing GitHub issues - Slack
message). mcp-agent exposes workflows as MCP tools on an MCP Agent
Server [5]: - workflows/list - list available workflows -
workflows/{WorkflowName}/run - Execute the workflow (async) -
workflows/{WorkflowName}/get_status - Check workflow status -
workflows/{WorkflowName}/resume - Resume paused workflow (e.g. with
human input) - workflows/{WorkflowName}/cancel - Terminate workflow
We've also implemented Temporal for durable execution [6], so agent
workflows can be paused, resumed and retried in production
settings. This demo [7] shows Claude invoking an MCP agent server,
running workflows when appropriate, and polling for status. It
basically shows agentic behavior on both the MCP client and MCP
server side. We're excited about the potential this unlocks--
especially as more applications become MCP-compatible clients. We'd
love your feedback and ideas! [1] -
https://news.ycombinator.com/item?id=42867050 [2] -
https://github.com/lastmile-ai/mcp-agent [3] -
https://www.anthropic.com/research/building-effective-agents [4] -
https://github.com/github/github-mcp-server [5] -
https://github.com/lastmile-ai/mcp-agent/tree/main/examples/...
[6] - https://github.com/lastmile-ai/mcp-
agent/tree/main/examples/... [7] - https://youtu.be/pLe2GAjEoYs
[DEMO]
Author : saqadri
Score : 35 points
Date : 2025-05-21 17:19 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| msamadi wrote:
| 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
| saqadri wrote:
| 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.
| yujian wrote:
| i've used this repo, it's a great starter pack
| saqadri wrote:
| Would love your feedback on the Temporal support and the MCP
| agent server concept which we merged in yesterday
| SlimIon729 wrote:
| That's great to hear! We'd love to know more about your
| experience and any thoughts you have on it.
| Beefin wrote:
| 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.
| saqadri wrote:
| 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.
| datadrivenangel wrote:
| Really cool, but it seems like recursive agents are going to bog
| down into microservice hell.
| scottcha wrote:
| 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...
| esafak wrote:
| 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.
| saqadri wrote:
| Agreed. Time, token, cost budget caps would be a great
| addition. Will add it as a feature request :)
| SlimIon729 wrote:
| 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.
| saqadri wrote:
| 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.
| max_on_hn wrote:
| 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!
| 3abiton wrote:
| This a bit confusing, and maybe I am missing a piece of the
| puzzle, are mcp agents and mcp clients being used
| interchangeably?
| saqadri wrote:
| This diagram might be helpful:
| https://pbs.twimg.com/media/GrgGy2jWQAAittE?format=jpg&name=...
___________________________________________________________________
(page generated 2025-05-21 23:01 UTC)