saqadri
Joined 3 years ago
Karma
193
Submissions
88
Member since
Mar 25
CEO @ lastmile ai
formerly @ Meta and Microsoft
reach me @ [email protected]
View on Hacker NewsRecent submissions
Comment · 1 year ago
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!
Comment · 1 year ago
Thanks for sharing this! We've reached out to the benchmark owners are are going to get our deep research agent benchmarked soon.
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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
Comment · 1 year ago
This diagram might be helpful: https://pbs.twimg.com/media/GrgGy2jWQAAittE?format=jpg&name=...
Comment · 1 year ago
Agreed. Time, token, cost budget caps would be a great addition. Will add it as a feature request :)
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
Would love your feedback on the Temporal support and the MCP agent server concept which we merged in yesterday