Bringing Temporal into your AI editor: How Coinbase debugs Workflows with MCP

The problem#

A Workflow panics due to a deadlock timeout in your Workflow Task in production. Before, debugging this meant pulling up the Temporal Web UI, scrolling through Event History to find the panic, copying error messages, switching to the codebase, searching for the relevant Workflow Definition, and piecing together what went wrong.

Our engineers wanted to ask a simple question in plain English, “Why did this Workflow fail?”, and get an answer right where we were already working. That’s why we at Coinbase built our own read-only Temporal MCP server.

What it does#

The Temporal MCP server gives our AI assistant read access to Temporal Cloud and our self-hosted clusters. No new UI to learn, no CLI commands to memorize. All you need is natural language.

Here are some example queries that our engineers like to use:

• “List all failed Workflows in the payments namespace in prod” — instantly see what failed without opening a browser

• “Show me the History for this Workflow” — get the full Event History

• “How many Workflows are running right now?” — get a quick status breakdown across all states

Under the hood, the server is built on FastMCP (the Python MCP framework) and exposes 10 read-only tools across three categories: Workflow operations, Schedule operations, and infrastructure inspection. It speaks to multiple Temporal Cloud accounts and self-hosted clusters out of the box. When you say “check Namespace X,” the assistant resolves which environment you mean, and asks if it’s ambiguous.

How the request flows#

The server runs as a local subprocess of the AI editor and communicates over stdio using the MCP protocol (JSON-RPC over stdin/stdout). That keeps API keys on the engineer’s machine and avoids any network hop between the editor and the MCP server itself.

The assistant picks the right tool, fills in the parameters, and the server handles Namespace resolution, auth, and payload decoding (we use a Codec) before returning structured JSON.

A tool, up close#

Each tool is a typed Python function decorated with FastMCP’s @mcp.tool(). The framework auto-generates the JSON schema the model uses to call it. For example, list_workflows:

@mcp.tool()
async def list_workflows(
     namespace: str,
     account: str,  # Temporal Cloud Account              
     query: Optional[str] = None,  # Temporal visibility query
     limit: int = 10, # caps results to keep tool output within the model's token budget
 ) -> str:
     """List Workflow Executions in a Temporal Namespace."""

Example: One question, two tool calls#

Note: We edited out some details for demo purposes.

The screenshot above shows the full interaction: one English question, two MCP tool calls, one diagnosis. A few things worth pointing out:

1. Ambiguity prompt. The first thing the assistant did was ask, “Which account/cluster should I use?” Namespaces like examples exist in multiple environments, so rather than guess, the MCP-aware assistant pauses and confirms.

2. First tool call, list_workflows. The raw JSON response (Workflow IDs, Run IDs, timestamps, Search Attributes, etc.) is hidden by default; the assistant summarizes it inline.

3. Compact structured summary. The assistant rendered a small table of the five most recent close times and Run IDs, a shape it chose on its own from the JSON response. This is the part that replaces the Temporal Web UI for most quick checks: you get the same “list view” without leaving your editor.

4. Conversational follow-up. The assistant offers the obvious next step (“Want me to pull the history for the latest run to see the failure reason?”).

5. Second tool call, get_workflow_history. The assistant walks the Event History, and surfaces only the relevant slice.

6. Root-cause statement, not just symptoms. The final paragraph names the actual bug. (We’re currently doing some testing in that Namespace, so the failure is expected.) The same flow works on any Namespace, in any account, against any Workflow Type.

Where it really shines: Troubleshooting across teams#

The most powerful thing about MCP isn’t any single tool. It’s what happens when multiple tools work together.

Now an engineer can ask their AI assistant to pull the Event History through the Temporal MCP and, in the same conversation, use a code search MCP (just work in their repo) to jump to the Workflow Definition, and from there to the Workflow Task or Activity Task that caused the issue. The AI connects the dots, correlating the failure in the Event History with the actual code path, and surfaces a diagnosis in seconds.

This has been a game-changer for helping other teams troubleshoot. You don’t need full context on someone else’s service to understand why their Workflow broke. The AI has the full picture: the runtime state from Temporal and the source code from your repo. You just ask the question.

The takeaway#

Our engineers have already made over 14,000 calls to the Temporal MCP in the span of a couple of months, and the top two tools, list_workflows and get_workflow_history, are exactly the pair we walked through above. And this is just one piece of the puzzle. The more we connect these agents to the systems we actually use, the more useful they become. Give the AI the runtime state, the source code, and the history — and you get a debugging partner instead of a chatbot.