Durable MCP: How to give agentic systems superpowers

It’s been said by punnier people than me that there are three problems in computer science: naming things and off-by-one errors.

I think that’s dryly hilarious. But I also think the two hardest problems in computer science are configuration and integration:

• Configuration: making the computer solve your problems the way you want them solved
• Integration: making the computers talk together to cooperate and solve your problems

No matter how well you build or buy software, modern applications always come down to these two challenges. You have to make the computers solve your particular problem and talk to the other computers.

Over the years, we’ve tried many different ways to manage configuration: modular, object-oriented, functional, domain-driven, several other kinds of -oriented, BRM, BPM. Despite all these approaches, it’s still a complex problem. Why? Because computers aren’t like people: they do exactly what we tell them, but we humans are imperfect translators of our own intentions.

Integration has seen similar evolution. We’ve moved through mainframe multi-user systems, client-server, monolith, peer-to-peer, SOAP, REST, microservices, event-driven, event-sourced, choreography, and orchestration. Each approach has been useful and made things incrementally easier. Yet integration remains hard and prone to troubles because the integration code is made by people, all these systems are run by people, we’re all imperfect, and integration error rates stack.

In this piece, I will discuss how these core problems may have a new solution on the horizon, opening up new ways to simplify configuration and integration. I’ll also talk about how making MCP durable with Temporal enables durable tool execution, opening up possibilities for tools and enabling people to build agentic tools that are durable, scalable, and enterprise-grade.

Enter agentic#

But what if we could change the game entirely? What if, instead of humans translating problems and solutions into computer instructions, the computers could just talk to you directly? This is possible with agents! Configuration suddenly becomes easy when you can just tell an AI what you want to do in plain language.

Goals#

Agentic systems solve problems for you and on your behalf. They act as your agents, getting things done the way you need them done. One way to define what you want done (configuration) is to define goals for the agent to do.

At Temporal, we’ve demonstrated systems with pre-defined goals that can focus on specific tasks, and we’ve also built more flexibility into these agentic systems that can handle multiple goals and switch between them as needed.

At their core, goals are about getting things done, and agents accomplish their work through tools. Goals provide the context that helps an agentic system understand how to complete multi-step processes.

Goals can be defined with human language:

# sample goal definition 
 description="The user wants to schedule paid time off (PTO) after today's date. To assist with that goal, help the user gather args for these tools in order: "
    "1. CurrentPTO: Tell the user how much PTO they currently have "
    "2. FuturePTOCalc: Tell the user how much PTO they will have as of the prospective future date "
    "3. BookPTO: Book PTO after user types 'yes'",

"Welcome me, give me a description of what you can do, then ask me for the details you need to do your job."

Tools#

While goals define what needs to be done, tools are how things actually get done. Tools can be local processes (“read this local file and give me its output”) or remote calls (“read this database with these input keys because I need specific results”).

Tools can be combined and sequenced — something we might have called microservices orchestration in a non-agentic system. But here’s where it gets interesting: tools can be defined as part of an agentic system, with human language context being provided by the system as configuration. Even better, tools can be implemented by other agents with their own defined goals and tools.

This framework of goals, intelligence, and tools achieves something fascinating. Configuration — that eternal challenge of making systems solve your specific problems with your data and APIs — becomes a matter of human language:

# sample goal definition
goal_hr_schedule_pto = AgentGoal(
    id="goal_hr_schedule_pto",
    agent_name="Schedule PTO",
    agent_friendly_description="Schedule PTO based on your available PTO.",
    tools=[
        tool_registry.current_pto_tool,
        tool_registry.future_pto_calc_tool,
        tool_registry.book_pto_tool,
    ],
    description="The user wants to schedule paid time off (PTO) after today's date. To assist with that goal, help the user gather args for these tools in order: "
    "1. CurrentPTO: Tell the user how much PTO they currently have "
    "2. FuturePTOCalc: Tell the user how much PTO they will have as of the prospective future date "
    "3. BookPTO: Book PTO after confirms the proposal with 'yes'",
)

# sample tool definition
book_pto_tool = ToolDefinition(
    name="BookPTO",
    description="Book PTO start and end date. Either 1) makes calendar item, or 2) sends calendar invite to self and boss? "
    "Returns a success indicator. ",
    arguments=[
        # <snip arguments definition for brevity>
    ],
)

This is a powerful way to make configuration easier. You define how to solve your problems in simple, human-readable terms, and the agentic AI works with you using the available tools.

But you’ve probably noticed a limitation: the system is constrained by its pre-defined tools. What if you wanted to use tools without pre-defining them in your application? What if we could make integration easy too?

Model Context Protocol (MCP)#

MCP is automatic, AI-powered integration. MCP transforms agentic tools into something pluggable, discoverable, and dynamically composable.

The magic of MCP is that tools can describe themselves. Their capabilities and APIs are provided right in the server definition:

// MCP tool definition from https://github.com/modelcontextprotocol/servers/blob/main/src/filesystem/index.ts
      {
        name: "read_file",
        description:
          "Read the complete contents of a file from the file system. " +
          "Handles various text encodings and provides detailed error messages " +
          "if the file cannot be read. Use this tool when you need to examine " +
          "the contents of a single file. Only works within allowed directories.",
        inputSchema: zodToJsonSchema(ReadFileArgsSchema) as ToolInput,
      },

With MCP, tools can present their capabilities to an agentic system and allow for dynamic goal solutions. Combining tools and building agentic capabilities becomes much easier.

Now, I’ll be honest — adding tools can still be a bit complicated for some agentic MCP clients. But I’m writing this blog with the assumption that this will become much easier soon. Great work is being done to simplify the process, and I foresee a future where entire agentic applications are composed simply by plugging different MCP tools into dynamic agent systems.

Durable MCP: Give agents superpowers#

As of the time of writing, MCP is both super powerful and really new. Agentic systems can call local MCP servers and remote MCP servers, but the current implementation uses simple JSON RPC without much durability built in. Visibility, security, reliability, and long-running capability are all still being figured out. MCP has tons of potential, but also much to deliver on.

MCP can do great things, but the protocol doesn’t provide durability. Users want their tools to work every time, and in a business context, we want the important tools we call to do their important work successfully, every time. At Temporal, we’re admittedly a bit obsessive about durability. Our mission is making all systems fault-tolerant and reliable. MCP tools have tremendous potential, but we think these tools should be ready for the scale and durability requirements of the enterprise. We want these tools to have durability and fault-tolerance built in. So when we look at MCP, we see a huge opportunity: what if we could add robust durability to these systems by implementing MCP tools with a Durable Execution framework like Temporal?

MCP tools as workflows#

Here’s a simple model to add a lot of desirable architectural qualities to MCP tools quickly: implement MCP tools as workflows.

Here’s an example of a tool that executes a Temporal Workflow and returns the result:

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    client = await get_temporal_client()
    handle = await client.start_workflow(
        workflow="GetForecastWorkflow",
        args=[latitude, longitude],
        id=f"forecast-{latitude}-{longitude}",
        task_queue="weather-task-queue",
    )

    return await handle.result()

This tool then calls a Workflow that looks like this:

 @workflow.run
    async def run(self, latitude: float, longitude: float) -> str:
        points_url = f"{NWS_API_BASE}/points/{latitude},{longitude}"
        points_data = await workflow.execute_activity(
            "make_nws_request",
            points_url,
            schedule_to_close_timeout=timedelta(seconds=40),
            retry_policy=retry_policy,
        )
	 #<snip>

That Activity call is guaranteed to execute durably and retry until it successfully retrieves weather data from the Weather Service.

This approach delivers some fascinating architectural benefits:

1. Tools automatically gain remote capabilities
2. Durable Execution comes baked in, bringing visibility, reliability, and scalability out of the box
   • Every downstream call is automatically retried until it succeeds
3. Tools continue progressing even if the MCP client or server crashes
4. Tools can be built in any language Temporal supports, meaning a developer can build agentic capabilities in Go, Java, .NET, or several other languages
5. Existing Workflows become reusable — if you already have a workflow that does what your tool needs, you’ve got a great head start
   • Maybe this isn’t useful for everybody, but for Temporal users reading this blog, it’s real nice
6. Tools can run for any duration without timing out
7. Tools can maintain a lifecycle independent of the agent session
   • We’ve been exploring that capability here, wherein a long-lived Workflow backs several tools and the agentic system can interact with the Workflow over its lifetime
8. It creates an easy path for agents-as-tools (but that’s a topic for another post)

Putting it together: A simple application defined by a user and some tools#

Let me show you what this means in practice. Say I want to figure out when the weather will be good to mow my lawn, and I need two hours of free time to do the mowing. With the durable weather tool above, I can check forecasts reliably. Add a calendar tool, and suddenly I can have an intelligent conversation with an agentic system that combines these tools — all without writing a line of integration code or configuring how the data meshes together. Here’s how that conversation might look in Claude: Building a weather-plus-scheduler application traditionally would require significant developer time, but the combination of agentic systems and MCP tools makes it trivial. Temporal makes these tools durable.

The possibilities become even more exciting when you imagine dynamically putting together all kinds of APIs and data sources across different contexts. As long as the tools exist, you can compose them in endless ways:

• As a developer, I could use MCP-powered monitoring tools to hunt for production problems, then leverage other tools to repair those problems, with me as a human in the loop, directing and approving changes along the way.
• As a product owner, I could connect tools that pull feature requests from customer feedback systems, analyze and refine them, write them into my team’s project backlog, and update the sprint planning documents in my team’s wiki — all through natural conversation with an agent.
• As a foodie, I could have tools that connect my home grocery inventory system, a recipe system, and a food delivery system like Uber Eats. A simple conversation like “I feel like eating sushi. Do I have the ingredients to make it? If not, can you recommend some restaurants in the area to deliver it to me?” becomes a complete application.

Today, there’s still a bit of work to set up MCP tools, and if an MCP server doesn’t exist, setting one up for an existing API or data source is a bit of work. This space will continue to mature and get easier, and I expect soon people will be building many kinds of data interactions powered by agentic AI and MCP tools.

Conclusion#

The combination of agentic systems and MCP enables the creation of powerful, flexible systems defined in simple terms. Human interaction, configuration, and integration can all be driven by human language. When you add Temporal’s Durable Execution to this architecture, these systems become highly reliable (our customers sometimes say “bulletproof”) — something required to run in production in an enterprise.

Temporal provides a rock-solid foundation for building these powerful distributed systems. Kevin Martin, myself, and others at Temporal are convinced that a new generation of applications will emerge — built quickly and durably using these technologies. I expect a new architecture to form, with agents, MCP, and Durable Execution combining to enable simple-to-build applications that are configured by end users to dynamically solve problems in ways traditional architectures never could.

We suggest you explore implementing your MCP tools as Temporal Workflows. You’ll find these systems not only reliable but genuinely enjoyable to build.

Check out our demo repository and feel free to:

• Join the Temporal Community Slack (channel #topic-ai).
• Talk to an expert.
• Sign up for Temporal Cloud and get $1,000 in free credits.