MCP Integration
How Pulse AI exposes a toolset agents can use to inspect board state, dispatch work, and return evidence through the Pulse AI workflow.
Last reviewed
What is MCP?
The Model Context Protocol is a standard way for AI systems to call tools. In Pulse AI, the important product concept is the Pulse AI toolset: agents can use Pulse AI-provided tools to inspect project state, coordinate board movement, dispatch work, and return evidence through supported workflows.
Pulse AI is not documented here as a generic MCP server host. The user-facing point is that Pulse AI gives agents controlled operational access to Pulse AI surfaces when the workspace and permissions allow it.
The available tools are versioned product capabilities, not a promise that every internal command is stable public API. Use the installed Pulse AI runtime as the source of truth for what the current workspace exposes.
How agents use Pulse AI tools
Agents use the Pulse AI toolset for operational work such as:
- Reading board and Workday state.
- Starting or queuing work.
- Updating review status.
- Finalizing knowledge artifacts.
- Checking operational health.
The exact tool list depends on the installed Pulse AI version and the workspace runtime. Use the app shell, command palette, and board surfaces for normal operation; agents use the toolset to carry out approved workflow actions with evidence.
Common tool families cover board items, deadlines, Workday focus, dispatch, review, Knowledge Items, presentation templates, deliverables, and Pulse Narrate. Agents should use the supported Pulse operation when one exists so the board, review package, and runtime remain connected.
Workspace and permission boundaries
Pulse tools operate inside a selected workspace. A tool that can read or change board state does not automatically grant access to another project, cloud account, or external service. External apps still require their own connection and permission.
Actions also keep their normal approval boundaries. Tool access can prepare a task, package evidence, or move a validated item into review, but it does not convert founder approval into an automated decision. Public posting, paid checkout, account changes, destructive cleanup, and final acceptance remain governed by the specific workflow.
Before an agent changes state, it should resolve the exact target, read the current record, and use the narrowest operation that satisfies the request. Idempotent operations should be preferred when repeated calls are possible.
Why it matters
Pulse AI tool access lets agents do more than write suggestions. It lets them act on the board, produce evidence, and return work to review with context intact.
The important boundary is review: tool access may move work forward, but human approval still controls what becomes done.
Evidence should travel with the state change. A task promoted to review should identify its validation and deliverables; a deadline change should preserve the source tree; a narration claim should include playback validation when voice is enabled.
External tool boundaries
External tool integrations can still matter for a workflow, but they are separate from Pulse AI's own operational toolset. Keep permissions narrow. Only connect tools that match the work you want agents to perform, and avoid granting broad access to systems that contain secrets or customer data.
Do not put API keys or provider secrets into tool arguments unless the product explicitly requests the secret through its secure settings path. Treat external messages, publications, payments, and deletions as consequential actions even when a connector can technically perform them.
Recovery
If an expected Pulse tool is missing, confirm the installed extension version, open the correct workspace, reload the editor, and inspect the runtime health before inventing a shell workaround. A missing tool can mean the installed host is stale, the workspace is not initialized, or the capability is not part of that version.
If a tool returns an ambiguous target or stale state, stop the mutation, re-read the board or deadline record, and retry with the exact identifier. If an external integration fails, keep the Pulse task and evidence intact while fixing the separate connection.