Agent Integrations

TensorPM is built for human project work and agentic project work over the same project graph.

There are three integration layers:

• external MCP clients that connect to TensorPM
• TensorPM's own agent using external MCP tools
• local coding agents assigned to Action Items

External MCP clients

External MCP clients can connect to TensorPM so they can read and write project context.

The app can detect and configure integrations for common clients such as:

• Claude Desktop
• Claude Code
• GitHub Copilot
• Cursor
• Windsurf
• Zed
• Continue
• Cline
• Antigravity
• Codex

Open Settings -> Integrations or the connector overview to inspect configured clients and install TensorPM MCP entries where supported.

What MCP is for

Use MCP for typed operations where the agent should call a specific tool.

Examples:

• list projects
• get a project
• list Action Items
• create or update Action Items
• record, supersede, withdraw, link, or list decisions
• list or switch workspaces
• set provider API keys
• submit bug reports or feedback
• check billing and credit status

MCP is best when the desired state change is concrete.

What A2A is for

Use A2A when the agent should talk to the TensorPM project agent.

Examples:

• ask for project-level reasoning
• request a context-aware plan
• continue a multi-turn project conversation
• ask the project agent to schedule a future reminder or review
• propose broader project context changes

The local A2A endpoint runs on http://localhost:37850 when the desktop app exposes it.

MCP vs A2A rule of thumb

Use this split:

• MCP for structured CRUD and typed reads.
• A2A for intent, planning, and context-level reasoning.

For example, creating one Action Item is MCP. Asking "what should we do next to recover this project?" is A2A.

TensorPM as MCP client

TensorPM's own AI agent can also call external MCP servers.

Configuration can come from:

• ~/.tensorpm/agent-mcps.json
• .tensorpm/agent-mcps.json
• .tensorpm/agent-mcps.local.json
• TENSORPM_AGENT_MCP_CONFIG_FILE

The connector UI can also manage agent MCP servers. It supports global and project-scoped server configurations.

Agent MCP server fields

An agent MCP server can include:

• name
• transport (stdio or streamable-http)
• scope (global or project)
• project ID for project-scoped servers
• enabled flag
• tool prefix
• command and args for stdio
• URL and headers for HTTP
• environment variables
• write-tool approval behavior

Use tool prefixes to avoid collisions when multiple MCP servers expose similar tool names.

Approval behavior

TensorPM distinguishes read-only tools from tools that may write, delete, or trigger side effects.

For external MCP tools used by TensorPM's own agent:

• read-only tools can usually be used directly
• write tools may require user approval
• trusted servers can be allowed more freely when appropriate
• private network HTTP MCP URLs are restricted unless explicitly allowed for trusted local testing

Keep write approval enabled for new or untrusted MCP servers.

Local coding agents

TensorPM can detect and invoke local coding agents.

Supported local providers in the current app include:

• Codex
• Claude Code

The app can also show GitHub Copilot status for external agent availability.

Local coding agents can be assigned to Action Items as agent assignees. TensorPM can run them, track execution, and collect completion signals.

Agent assignee roles

Agent assignees can carry roles such as:

• developer
• architect
• reviewer

Use roles to clarify what the agent should do. For example, assign a coding task to a developer agent and a design review to a reviewer agent.

Runtime and permission settings

Local agents can run in standard or fuller permission modes depending on user settings and provider behavior.

Use standard mode for routine work. Use full permission modes only when the agent must make broad local changes and you understand the risk.

Git commit stories

TensorPM can work with repositories inside project files and generate stories from commits using local agents. This is useful when project documentation needs to reflect implementation history.

Use this when:

• a code project has meaningful commit history
• stakeholders need narrative progress summaries
• the project Trail should connect technical work to project context

Recommended setup flow

1. Install TensorPM and create or open a project.
2. Configure AI access in Settings -> AI.
3. Open connector/integration settings.
4. Install TensorPM MCP into the external clients you actually use.
5. Add external MCP servers for TensorPM's own agent only when they provide real project value.
6. Keep write approvals enabled until the server is trusted.
7. Test with a safe read operation, such as listing projects.
8. Test with a small write operation, such as creating one low-risk Action Item.

Safety rules for agents

• Record durable decisions in Trail, not only in chat.
• Use MCP for exact updates and verify results after writing.
• Use A2A for broader reasoning.
• Avoid giving agents broad filesystem or write-tool access by default.
• Do not let agents claim that billing, checkout, or payment completed unless the user confirms it outside the tool response.
• Review generated Action Items before relying on them for execution.

Troubleshooting

If an MCP client cannot see TensorPM:

• confirm the desktop app is running
• check whether the integration config was written to the expected client file
• restart the MCP client after config changes
• verify that the TensorPM MCP server command points to the installed app resources
• inspect connector status in TensorPM

If TensorPM's own agent cannot call an external MCP:

• confirm the server is enabled
• check transport type and command/URL
• check environment placeholders and secrets
• review approval prompts
• test with a read-only tool first

Next steps

• Understand the project graph: Project Structure
• Work with Action Items: Action Items
• Configure providers: Account & AI Modes
• Review history: Files, Intake & Trail