t3-code-mcp
This MCP server lets you inspect and control a configured T3 Code environment: browse projects and threads, start and monitor agent work, and respond to approvals or input requests.
Check T3 connection health, capabilities, scopes, and gateway operations with
t3_connection_status.List and register projects, filtered by title, path, or ID, with pagination.
List threads by project, status, title, branch, or ID, including archived ones.
Create threads and send messages to start or continue agent turns.
Read thread summaries, latest responses, pending flags, message history, and truncation status.
Track runs with status lookups and bounded waits for changes.
Interrupt a run or an existing thread's active turn.
List pending approvals and user-input requests, then respond with accept/decline decisions or answers.
Archive threads without deleting workspace files.
Provides read-only Git inspection for T3-selected workspaces, including structured status, bounded uncommitted diffs, and committed base-to-head comparisons.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@t3-code-mcp What threads are open in that project?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
t3-code-mcp
An MCP gateway that lets MCP clients interact with T3 Code agents: find projects and threads, start tasks, check progress, retrieve results, and respond to requests for input.
It connects to one configured T3 Code environment and supports local stdio and remote Streamable HTTP connections for desktop assistants, hosted clients, and custom integrations.
The original idea was to pair it with GPTVoice's tool calls to start tasks and get agent updates by voice while on the go.
flowchart LR
User[You] <--> Client[Any compatible MCP client]
Client <-->|MCP over stdio or Streamable HTTP| Gateway[t3-code-mcp]
Gateway <-->|Authenticated HTTP and WebSocket RPC| T3[T3 Code and its coding agents]
Gateway <-->|Native T3 MCP, forwarded tools| T3
Gateway -->|Read-only Git status and revision comparison| Workspace[T3-selected workspace]What you can do
See the open queue of threads that are not working by default, review every project and thread on request, triage what needs attention, and read full thread timelines.
Inspect structured Git status, bounded uncommitted diffs, and committed base-to-head comparisons in T3-selected workspaces.
Start recoverable one-call tasks, find them after reconnecting, review their changes, and cancel them.
Steer, queue, interrupt, fork, configure, and organize threads, manage schedules and pull request watches, and upload attachments, through T3's own native MCP tools that the gateway forwards.
Answer approval and input requests.
Record redacted tool, transport, upstream, Git, and journal activity for later review through
t3_audit_log.Connect through local stdio or authenticated Streamable HTTP.
The gateway supports T3 orchestration protocols 1 and 2. Protocol 2, introduced by upstream PR #2829, uses HTTP snapshot reads and authenticated WebSocket RPC for thread control. Protocol 1 retains HTTP dispatch for older deployments. The recorded live integration target is v0.0.41-nightly.20260910.1507. V2 has source-contract and local fixture coverage. A candidate protocol transition acceptance passed on 2026-10-06 in an isolated V1 to V2 upgrade and rollback. It did not verify the full V2 surface or an installed service, so live verification of the deployed V2 build is still required. See orchestrator compatibility. See usage and tool behavior for examples, supported tools, and current limits.
Related MCP server: VoxMesh
Security
Write access lets a client control your T3 coding agent with that agent's machine permissions. Both thread creation and composite task start require the caller to choose a runtime mode explicitly. The client can answer approval requests without independent human verification. Read-only access still exposes thread content and project information.
Start with MCP_READ_ONLY=true, connect only trusted clients, and review the security and access risks before enabling remote access or control tools.
Quick start
Install Cargo and Rust 1.88 or newer. The package commands and TypeScript reference checks also need Node.js 22.13 or newer and pnpm 11.16.0.
Run from the repository root:
pnpm install
pnpm build
cp .env.example .env
chmod 600 .envEdit .env: set T3_ACCESS_TOKEN, a separate random MCP_BEARER_TOKEN, and MCP_READ_ONLY=true. Set T3_HTTP_BASE_URL if T3 is not at http://127.0.0.1:3773.
For HTTP, set MCP_TRANSPORT=http and start the gateway:
set -a
. ./.env
set +a
pnpm startpnpm build produces rust/target/release/t3-code-mcp. start and serve run that release binary. dev builds and runs the Rust debug binary. The CLI reads exported environment variables. pnpm build:reference builds the TypeScript reference used by compatibility checks.
Connect your MCP client to http://127.0.0.1:8787/mcp with Authorization: Bearer <MCP_BEARER_TOKEN>. This address is local to the gateway machine; remote clients need an authenticated tunnel or HTTPS proxy. For a local client that launches the process, use MCP_TRANSPORT=stdio instead.
Run native-login with a T3 pairing code to enable the forwarded native tools; see native T3 login. Request connection status, list projects, and read an existing thread to verify the connection. Follow the configuration and client connection guide for all environment variables and the first write-enabled check.
The gateway writes its append-only redacted usage trail to audit.jsonl in T3_MCP_DATA_DIR; a future agent can query the bounded history with t3_audit_log. For offline aggregate analysis without T3 credentials, run pnpm usage-summary --file ./data/audit.jsonl --since <ISO> --until <ISO>. See usage analysis for metric definitions and task briefs for precise launch/continuation examples.
Documentation
Guide | Contents |
Example requests, native T3 tools, delegation from outside, status fields, retries, and current limits | |
Environment variables, native T3 login and renewal, transports, connection checks, and integration references | |
Host access, credentials, approvals, data exposure, deployment risks, and mitigations | |
Systemd services, tunnel setup, credentials, and startup checks | |
Build and test commands, diagnostics, and opt-in live integration tests |
V1 integration references
These references record the V1 limits checked on 2026-09-11. Several are addressed by the new V2 orchestrator. See orchestrator compatibility for the gateway behavior after that upgrade.
Gateway limit | Upstream item | Effect here |
Busy threads reject new turns. Queueing and steering are not implemented. | Resolved for clients of the native tools: native | |
Interrupt acceptance never confirms a stop. The removed gateway interrupt tools polled for a separate verification result; native | Both describe interrupt requests recorded as accepted while the session projection stays | |
Pending-action details are inferred from activity records and can include historical entries. | Server-side dismissal of orphaned questions and of approvals on revert would make | |
The HTTP orchestration route does not implement every WebSocket command field. |
| |
There are no push notifications. Clients wait with native | Issue #10929 | An authenticated read-only thread status stream would replace polling for run progress and pending requests, and would lower load for always-on clients. |
Settled and open lists can differ from the T3 UI, which derives settlement from inputs the API does not expose. | These report PR-driven auto-settling, completion waking snoozed threads, and clients disagreeing about settlement. Server-owned lifecycle state would let | |
V1 error strings can conflate rate limits and quota; unbound start errors lack turn identity. | Issue #10545, completed by merged PR #2829 on 2026-10-02; PR #10550 closed unmerged. | V2 exposes root error |
| PR #10411 |
|
The gateway reports credential expiry but cannot influence it. | Issue #9884 | Session lifetime is currently chosen by credential type, and the plain bearer token this gateway uses gets the long 30-day session. A corrected policy changes how often |
Available Tools
15 toolst3_connection_statusT3 connection statusARead-only
Inspect the configured T3 environment, connection health, freshness, capabilities, and scopes.
Inputs: no named parameters. Returns: error, t3Scopes, environment, lastObservedAt, +5 more
t3_pending_action_respondRespond to a T3 pending actionA
Respond to a T3 approval or user-input request using its stable requestId. The gateway forwards the supplied response and does not independently verify human confirmation.
Inputs: kind (required), threadId (required), requestId (required), idempotencyKey (required), +2 more. Returns: reason, status, commandId, t3Sequence, +2 more
t3_pending_actions_listList pending T3 actionsBRead-only
Surface pending approval and user-input flags, plus stable action details when the T3 projection exposes them.
Inputs: threadId (required). Returns: actions, threadId, environmentId, detailsAvailable, +2 more
t3_project_createRegister a T3 projectA
Register a remote workspace as a T3 project. Set createWorkspaceRootIfMissing to request creation of a missing directory. This does not clone a repository. Requires orchestration control scope and an idempotencyKey.
Inputs: title (required), workspaceRoot (required), idempotencyKey (required), defaultModelSelection, +1 more. Returns: reason, status, commandId, projectId, +4 more
t3_projects_listList T3 projectsARead-only
Find projects by case-insensitive title, workspace path, or ID substring. Filtering happens before pagination.
Inputs: limit, query, cursor. Returns: page, environmentId
t3_run_getGet T3 run statusBRead-only
Reconcile a gateway run handle against T3 state. A disconnected result is not evidence that the run failed.
Inputs: runId (required). Returns: error, runId, t3TurnId, threadId, +11 more
t3_run_interruptInterrupt a T3 runA
Request interruption of one accepted T3 run. The interruption itself is journaled and is never replayed automatically.
Inputs: runId (required), idempotencyKey (required). Returns: reason, status, commandId, t3Sequence, +2 more
t3_run_waitWait for a T3 run changeARead-only
Poll for a relevant run change for a bounded interval. A timeout only means no change was observed; it does not cancel the run.
Inputs: runId (required), timeoutSeconds. Returns: error, runId, t3TurnId, threadId, +11 more
t3_thread_archiveArchive a T3 threadB
Archive a thread without deleting its remote workspace files.
Inputs: threadId (required), idempotencyKey (required). Returns: reason, status, commandId, t3Sequence, +2 more
t3_thread_createCreate a T3 threadA
Create a thread in an existing T3 project. Supply modelSelection when the project has no default. The returned branch and worktree reflect the request; check the mutation status for acceptance.
Inputs: title (required), projectId (required), idempotencyKey (required), branch, +4 more. Returns: reason, status, threadId, commandId, +5 more
t3_thread_getGet a T3 threadBRead-only
Return a compact thread summary, latest response, active run, pending flags, and workspace.
Inputs: threadId (required). Returns: thread, environmentId
t3_thread_interruptInterrupt work in an existing T3 threadA
Request stopping the active turn in a thread, including one started outside this gateway. Read the thread first and supply latestTurn.turnId as expectedTurnId. Stale observations are rejected before dispatch, but T3 interrupts by session and cannot guarantee atomic turn targeting. This does not archive or delete the thread; poll thread_get to confirm it stopped.
Inputs: threadId (required), expectedTurnId (required), idempotencyKey (required). Returns: reason, status, commandId, t3Sequence, +2 more
t3_thread_messagesRead T3 thread messagesBRead-only
Read paginated thread history. Message text is bounded by maxChars and reports truncation explicitly.
Inputs: threadId (required), limit, cursor, maxChars. Returns: page, environmentId
t3_thread_sendSend a T3 thread messageA
Send a new or follow-up message to an idle existing thread, start one T3 agent turn, and return after command intent is accepted. Busy threads are rejected; queueing and steering are not enabled. Never reuse an idempotencyKey for different input.
Inputs: message (required), threadId (required), idempotencyKey (required), titleSeed, +3 more. Returns: runId, reason, status, t3TurnId, +9 more
t3_threads_listList T3 threadsARead-only
Find threads by project and case-insensitive title, branch, or ID substring. status filters server-backed open, snoozed, settled, or archived state; UI-local inactivity/PR auto-settle rules are unavailable. Open includes pinned work and is not synonymous with running. Without a specific status, includeArchived controls archive visibility.
Inputs: limit, query, cursor, status, +2 more. Returns: page, environmentId
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 15 tools
Most tools target a distinct resource and action, and the t3_run_* and t3_thread_* groups are largely well separated. The closest ambiguities are t3_run_interrupt vs t3_thread_interrupt and t3_thread_get vs t3_thread_messages, but the descriptions establish clear boundaries.
All tools share the t3_ prefix and snake_case, with a mostly predictable resource_action pattern. Minor inconsistencies exist: plural forms like projects_list and pending_actions_list mix with singular forms, and connection_status and thread_messages are noun-like names rather than clear verb-first operations.
At 15 tools, the surface is at the high end but still justifiable given projects, threads, runs, pending actions, and connection inspection each have separate workflows. A few operations could arguably be consolidated, but the set is not bloated enough to be a real usability problem.
The main workflow is covered end-to-end: project creation, thread creation and messaging, run waiting and interruption, and pending-action response are all present. Gaps remain around explicit project/thread updates or deletion, though thread archive and thread send act as partial lifecycle operations.
Maintenance
Related MCP Connectors
Operate hilos project rooms, Docs, Tasks, messages, memory, and coding-agent review workflows.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Manage uivoid projects, tools, keys, hosted databases and teams from your agent.
Manage ElevenLabs voice agents and generate speech, music, sound effects, images, and video.
Related MCP Servers
- AlicenseAqualityDmaintenanceManage voice AI agents from Claude Code, Cursor, VS Code, or any MCP-compatible assistant.310 npm3MIT
- AlicenseNot gradedqualityBmaintenanceEnables voice-first interactions with AI agents and MCP tools, supporting speech input/output, STT/TTS, and a provider-independent agent core.1MIT
- AlicenseNot gradedqualityCmaintenanceEnables coding agents to receive and act on voice-captured tasks delivered as GitHub issues, including retrieving full context, adding notes, asking the developer questions, and closing tasks when complete.MIT
- AlicenseNot gradedqualityBmaintenanceEnables voice-driven control of coding agents via Claude on your phone, allowing status checks, stand-ups, sending prompts, and receiving push notifications when agents finish or need decisions.MIT