Exposing Agents as MCP Servers with mcp-agent: Sarmad Qadri

Why should an MCP server expose only individual API operations? Many servers map existing REST endpoints directly to tools. But the same interface can expose an agent: a service that receives a task, decides which operations to perform, and returns the result. That moves the server boundary from a single operation to a coordinated piece of work.

This opens up three connected design questions: what belongs in the agent stack, how agents can become MCP servers, and where their execution should live. Workflow systems such as Airflow and Temporal provide the last piece of the framing: an agent can be an asynchronous workflow rather than something whose lifetime is confined to a chat session.

Sarmad Qadri, CEO of LastMile AI, approaches MCP through his experience working on Language Server Protocol at Microsoft during 2016–2018. Before LSP, language tooling had to accommodate editor-specific interfaces: supporting VS Code meant one integration, while supporting Eclipse meant another. LSP standardized how language services were exposed to editors, allowing the same service to work across those boundaries.

That precedent suggested a similar question for LLMs: could tools and context connect through one interface? Qadri’s 2023 scratchpad, from the ChatGPT plugins era, explored agent authentication and connections to tools, resources, and data. MCP subsequently supplied the common interface he had been looking for.

The motivation was practical. Customers wanted workflow automation, processing of unstructured data, and information retrieval, but Qadri had seen valuable applications remain at the proof-of-concept stage. His prediction in this 2025 talk was that agents would reach production more broadly as these integration and architecture problems became easier to solve.

The first change is in the models themselves. Reasoning models and test-time compute move some work previously implemented in frameworks—such as explicit reasoning scaffolding and ReAct-style patterns—into inference. Developers can accomplish more with a model invocation, reducing the amount of application code needed to guide the model through a task.

The second change is Model Context Protocol. MCP gives LLM applications a shared interface to tools, data, and resources, replacing a collection of platform-specific connectors. Qadri points to adoption by Google, OpenAI, and Microsoft as support for his forecast that MCP would become the common integration standard.

The third change follows from the first two: applications can concentrate on orchestrating capable models and MCP tools through a few well-defined patterns. In this architecture, there is less work for a monolithic AI framework to perform. Anthropic’s Building effective agents provides the pattern vocabulary used throughout the rest of the talk.

The basic building block is an augmented LLM: a model with access to tools and data. It receives input, calls a tool or retrieves information when necessary, and continues through further iterations before returning a response. The useful unit is therefore a loop around the model, not necessarily a single model call.

An evaluator–optimizer pattern connects two such units. One generates an answer; the other evaluates it and supplies feedback. The generator revises its output, and the cycle continues until the evaluator accepts its quality. This adds an explicit feedback mechanism to the basic tool loop.

More elaborate workflows distribute work or decide its structure dynamically:

Qadri points to Claude Code as an emerging example of orchestrator-style behavior. The distinguishing mechanism is the planner: it reasons about what to do next rather than simply executing a fixed list of subtasks.

During his Christmas break, Qadri started mcp-agent to implement these patterns with MCP as a foundational assumption. Its first commitment is that MCP connectivity will become widespread. He anticipates applications such as Notion, Google Docs, Cursor, and Claude acting as compatible clients, while services such as Linear and GitHub expose servers. These examples describe the ecosystem he expects the library to inhabit, rather than a demonstration of every integration.

The second commitment is that agents can be deployed as microservices exposed through MCP. This makes an agent available to other applications and agents through the same kind of interface used for ordinary tools.

The third is that agents are asynchronous workflows. A task may pause, resume, retry, or wait for a human. Those lifecycle requirements belong to workflow orchestration infrastructure, beyond an in-process conversation loop.

In the familiar arrangement, an application such as Claude or Cursor performs the agentic work on the client side and invokes MCP servers as tools. Exposing an agent as a server changes that arrangement: the application can invoke a complete agent and coordinate it alongside other services.

The connection can continue through several layers. A client connects to ordinary servers such as GitHub, Slack, or Linear, and also to agent servers. Each agent server can then connect to tools or invoke another agent. In the diagram, agent servers A and B sit alongside a regular MCP server; downstream connections include Fetch, Filesystem, and agent server C. One user command can consequently activate a network of agents. The shared protocol supplies a common invocation interface; planning and coordination still belong to the applications using it.

This separation creates three architectural benefits:

• Composition: Agents and tools can participate in larger systems through the same protocol.
• Reuse: An agent can be invoked from different MCP-compatible applications.
• Independent compute: Dedicated infrastructure executes the agent while the client handles the interaction.

Qadri presents scalability, performance, and durability as benefits of that separation; the talk does not attach benchmark results to those claims.

An agent may need to pause for human feedback, resume later, or retry after a failure. It may also start without a conversation: a webhook can trigger work, or a cron job can schedule it daily or weekly. Modeling execution as an asynchronous workflow accommodates both interactive and scheduled entry points.

In the implementation presented here, Temporal supplies the durable execution backend for mcp-agent. MCP provides the interface through which work can be requested; Temporal handles the workflow execution and orchestration behind that interface.

The demonstration turns this architecture into a concrete task: load a student’s short story from a Markdown file, grade it, and save a report. The requested assessment covers proofreading, factual and logical consistency, and adherence to an APA style guide retrieved from a URL. The output belongs in graded_report.md.

Two MCP servers provide the external capabilities. The Fetch MCP Server retrieves web content, and the Filesystem MCP Server provides file access. The agent reaches both through MCP tools, so web retrieval and disk access do not require separate integration conventions within the agent. A finder agent uses those capabilities to retrieve content from the internet or disk.

The remaining agents divide the task into clear responsibilities:

The orchestrator receives the overall request and chooses how to use the available agents. Defining specialists does not require prescribing the full execution sequence in advance.

Qadri estimates the demonstrated grading workflow at about 100 lines of code. That is an estimate for this example, not a size guarantee for an entire deployed agent system.

Starting the job activates a worker and creates a workflow visible in Temporal’s UI. The agent’s first visible action is to generate a plan for the grading request.

The generated plan breaks the request into a sequence:

1. Load the student’s story with the finder agent, using the filesystem server.
2. Analyze it with the proofreader, fact checker, and style enforcer.
3. Generate the graded report and ask the writer to save graded_report.md.

This makes the orchestrator’s interpretation of the request visible before the final output appears.

The workflow graph then shows execution progressing. Qadri describes retrying a failed step, terminating execution, and waiting for human feedback as supported lifecycle operations. This run proceeds to completion; it does not demonstrate those recovery paths. He opens the generated graded_report.md, inspects its factual-consistency and APA-style feedback, and judges that it fulfilled the request. The visible result establishes report generation, rather than an independent validation of the grading.

The final demonstration exposes the agent as an MCP server and connects it to Claude Desktop. The server makes its workflows available to the client. These are application-defined workflow operations exposed through MCP tools, not standard MCP workflow endpoints; current repository API names should not be assumed to match the version shown in the recording.

Qadri supplies the same story and asks Claude Desktop to grade it with the agent. The client starts the workflow with the story as input, then polls the workflow job’s status. Execution occurs in a separate environment. Qadri explains that he could close Claude Desktop, return later, and retrieve the status and result, although the recording does not show a close-and-reopen test.

When the agent completes, the client presents the report. The chat application remains a useful interface, but it no longer owns the execution lifetime. The same independently running agent can accept work from other MCP-compatible clients, allowing the user to change the entry point without relocating the workflow.