Skip to main content
The Trigger.dev MCP server includes tools for having conversations with your chat agents directly from AI coding tools like Claude Code, Cursor, Windsurf, and others. This lets your AI assistant interact with your agents without writing any code.

​
Available tools

See the MCP Tools Reference for full details on each tool.

​
Typical workflow

1

List available agents

Ask your AI assistant to list agents in your project. This calls list_agents which returns all tasks created with chat.agent() or chat.customAgent().
2

Start a chat

Start a conversation with an agent using start_agent_chat. This triggers a run and optionally preloads the agent so it’s ready to respond immediately.If the agent uses withClientData, pass the required fields via clientData.
3

Send messages

Send messages with send_agent_message. The agent processes each message and returns the full response text, including which tools were used. The agent retains full context across messages in the same chat.
4

Close the chat

When done, close the conversation with close_agent_chat. This signals the agent to exit gracefully. If you skip this step, the agent will close on its own when its idle timeout expires.

​
Example conversation

Here’s what a typical MCP conversation with an agent looks like:

​
Setup

If you haven’t set up the MCP server yet, see the MCP Server introduction for installation and client configuration. Agent chat tools require:

​
How it works

Under the hood, the MCP tools use the same protocol as the frontend transport and AgentChat SDK:
  1. start_agent_chat triggers a task run with the preload trigger and stores the session (run ID, chat ID) in memory.
  2. send_agent_message sends the message via the run’s input stream and subscribes to the output SSE stream to collect the agent’s full response.
  3. close_agent_chat sends a close signal via the input stream and removes the session.
Sessions are held in-memory within the MCP server process. If the MCP server restarts, active sessions are lost — but the underlying agent runs continue until their idle timeout.
The get_current_worker tool also labels agents with [agent] in its output, making it easy to identify which tasks are agents even when listing all tasks.

​
See also