Yapitalism MCP server

<!-- mcp-name: io.github.AytuncYildizli/yapitalism --> <!-- The MCP Registry verifies PyPI package ownership by finding this string in the package description, which is this README. It must match server.json's name exactly. -->

Yapitalism

Drive terminal coding agents by voice, and never let the answer claim more than it proved.

You are away from your desk. You speak; an agent in a terminal does the work; you get a spoken reply. That reply is the only thing you have — you cannot see the screen. So the worst failure is not a crash, it is the voice saying "done" while your text sits unread in a prompt box.

Yapitalism is a local MCP server that lets a voice client reach your coding agents, plus a receipt layer that decides what the voice is allowed to say. If you are at your desk, use your screen — this exists for the hours you are not.

Public pre-alpha. Local-only. No production deployment, no external messaging, and no automation

of closed-source clients.

How it fits together

MCP client (Codex · Hermes · Claude Code · Claude Desktop · Cursor)
    │  MCP over loopback — no public endpoint, no OAuth, no relay
    ▼
yapitalism MCP server          panes_list · pane_read · pane_send
    │                          pane_await · pane_task
    │                          panes_name · panes_unname
    │                          panes_create · panes_resume · pane_clear
    ├── superset backend       local host-service over tRPC (127.0.0.1:48900)
    └── tmux backend           capture-pane / send-keys

The agents it addresses: codex, claude, kimi, opencode — recognised by measurement (a process tree on tmux, the host's own agent registry on Superset), never by a caller's claim. A pane running anything else is refused, because typing into a shell and pressing Enter is running a command.

The voice client never reaches your machine directly: it drives a local agent session, and that session talks to this server over 127.0.0.1. Nothing is exposed to the network.

The part that matters: receipts

pane_send returns a verdict, not a shrug.

YELLOW is the whole point. Text left unsubmitted in an agent's input box looks identical to work in progress from outside — same spinner, same scrolling output, same HTTP 200. A voice that rounds that up to "done" costs you hours before you notice.

Explicitly not acceptance: an HTTP 2xx, a PTY write returning, terminal output changing, a revision advancing, or the prompt echoing your own words back.

Waiting is not the same as failing

A fixed deadline reports on the clock, not on the agent. An agent that thinks for a minute and then answers correctly was verified all along, and calling that YELLOW teaches an operator to ignore YELLOW. So the wait is an idle timeout: it restarts whenever the pane changes, bounded by a hard ceiling.

Pane movement decides only whether to keep waiting. It is never evidence of acceptance — that stays the canary alone. A YELLOW therefore says which kind it is:

measured: a spinner, a clock, a log tail or a second agent sharing the pane all produce this without the intended agent doing anything. It is a hint that looking again may be worth it, never a claim that the agent is working.

• canarytimeoutpane_moving — the pane's text was still changing. Named after what was

• canarytimeoutpane_still — nothing moved at all.

Shortened. The full README is on GitHub.