Skip to main content
Glama

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 .env

Edit .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 start

pnpm 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

Usage and tool behavior

Example requests, native T3 tools, delegation from outside, status fields, retries, and current limits

Configuration and client connections

Environment variables, native T3 login and renewal, transports, connection checks, and integration references

Security and access risks

Host access, credentials, approvals, data exposure, deployment risks, and mitigations

Linux deployment

Systemd services, tunnel setup, credentials, and startup checks

Development and verification

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.

Issue #9672, PR #7240, PR #10132

Resolved for clients of the native tools: native t3_thread_send queues and steers. The gateway's own task dispatch still returns thread_busy.

Interrupt acceptance never confirms a stop. The removed gateway interrupt tools polled for a separate verification result; native t3_thread_interrupt and t3_task_cancel do not.

Issue #4713, issue #8618

Both describe interrupt requests recorded as accepted while the session projection stays running. A terminal session event after interruption would make verification reliable instead of best effort.

Pending-action details are inferred from activity records and can include historical entries.

Issue #5454, PR #10586, PR #8425, issue #7825

Server-side dismissal of orphaned questions and of approvals on revert would make t3_pending_actions_list match what the agent can still accept. #7825 covers request types reported as unknown.

The HTTP orchestration route does not implement every WebSocket command field.

Issue #8319, PR #7996

thread.turn.start with bootstrap fails or ignores worktree attachment over HTTP. This gateway works around it by creating a deterministic explicit Git worktree and attaching it through ordinary thread.create; upstream parity would restore T3-owned setup-script execution and rollback.

There are no push notifications. Clients wait with native t3_thread_wait or poll the task tools.

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.

Issue #5476, issue #6368, issue #10099

These report PR-driven auto-settling, completion waking snoozed threads, and clients disagreeing about settlement. Server-owned lifecycle state would let status and statusReason agree with every client.

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 failure.class, code, retryable, optional resetAt, and retry progress; shell rows expose lastErrorClass and usageLimitResetAt. The gateway supports both APIs and retains turn-bound failures. Specific V1 provider evidence improves classification. V2's broad usage_limit class still includes some rate limits. See failure authority and limits.

T3_ACCESS_TOKEN cannot be narrowed. t3 auth session issue mints AuthAdministrativeScopes only, so MCP_READ_ONLY=true is enforced by this gateway, not by the T3 token.

PR #10411

t3 drive mints a per-invocation session holding only orchestration:read, adds orchestration:operate for mutations, and revokes it afterwards. The server therefore supports narrow sessions already; a scope flag on t3 auth session issue would let a read-only deployment hold a read-only token. The drive commands themselves are an HTTP client for the same orchestration endpoints, so they are not a transport alternative for this gateway.

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 T3_ACCESS_TOKEN must be rotated.

Available Tools

15 tools
t3_connection_statusT3 connection statusA
Read-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 actionsB
Read-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 projectsA
Read-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 statusB
Read-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 changeA
Read-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 threadB
Read-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 messagesB
Read-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 threadsA
Read-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

    A3.7/5.0

    Scored across 15 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count4/5

    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.

    Completeness4/5

    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

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers