denoland / denoland/t4a

MCP server adapter (Rust)

Open
#1 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
14
Forks
0
PR merge metrics
No merged PRs in 30d

Description

The spec notes "Built-in MCP server" as out of scope with the suggestion to "build this as a separate thin adapter." This is that adapter.

## What it does

A ~380-line Rust binary (`t4a-mcp`) that exposes t4a's Unix socket protocol as an MCP stdio server. 9 tools mapping 1:1 to the protocol commands: `t4a_create`, `t4a_list`, `t4a_send`, `t4a_screenshot`, `t4a_text`, `t4a_cursor`, `t4a_resize`, `t4a_kill`, `t4a_wait`.

The main thing that justifies the MCP layer over just using the CLI via shell: **`t4a_screenshot` returns the PNG inline as an MCP image content block**, so the LLM gets the screenshot in a single tool call without save-to-file-then-read. `t4a_wait` also provides a clean blocking event wait that maps better to MCP's request/response model than piping `t4a events`.

## Tech stack

- Rust, same as t4a itself
- `rmcp` 1.2 (official MCP Rust SDK from modelcontextprotocol/rust-sdk)
- Shares dependencies with t4a: `tokio`, `serde`, `serde_json`
- Connects to `/tmp/t4a.sock` (or `$T4A_SOCKET`), auto-starts daemon if not running
- Single-threaded `current_thread` tokio runtime
- Release binary: ~1.7MB with LTO + strip

## Structure

```
src/
main.rs # MCP server, tool definitions (~230 lines)
client.rs # t4a Unix socket client (~150 lines)
```

## Design decisions

- `t4a_send` does escape parsing (`\n`, `\t`, `\r`, `\e`, `\xHH`) matching the CLI's behavior, since MCP clients send these as literal two-character sequences in JSON strings. Also supports `input_base64` for raw bytes.
- Event type validation against the spec's 6 known types (`command_done`, `idle`, `activity`, `exit`, `bell`, `title`) to fail fast on typos instead of silently timing out.
- Screenshot hardcoded to `pad=1, scale=66` (the empirically optimal config from the vision tests).

## Questions for maintainers

1. Would you accept this as a PR? If so, should it live as a `mcp/` subdirectory in this repo or as a separate crate/repo?
2. Any preferences on tool naming? Currently prefixed with `t4a_` to avoid collisions when the MCP server is registered alongside others.

Happy to open a PR if there's interest. Source: https://github.com/douglasjordan2/t4a-mcp

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the repository spec section that marks a built-in MCP server out of scope, then review the linked t4a-mcp source and its src/main.rs and src/client.rs. Confirm with maintainers whether the adapter belongs in an mcp/ subdirectory or a separate crate, and settle tool naming before implementation; done means an agreed contribution path and design.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.