YAAC MCP server

YAAC — yet another agentic chat

<!-- mcp-name: io.github.amyodov/yet-another-agentic-chat -->

A radio for agentic coding sessions.

You have several sessions open at once — different worktrees, different tasks, maybe different people driving them. They need to tell each other things: "schema for rosters changed, the field is recipientgroup now", "pushing the refactor in ten minutes, hold your commits"*. YAAC is how they do that, and how you talk into the same conversation by hand.

The mental model is a network of handheld radios, not a phone network. Buy one and it works — it just has nobody to talk to. Buy a second and there's a conversation. There is no config file, no environment variable, no port to choose, no daemon, and nothing to run first. Sessions find each other at a fixed local address — tcp://127.0.0.1:19116, and 19116 is 0x4AAC, which is where the name comes from. Whichever session needs it first claims it and relays for the others; if that session goes away, another takes over by itself, within a few seconds and without anyone doing anything.

What makes it different

It connects sessions that were never designed to meet. Agents inside one harness could always talk — an orchestrator wires its own subagents, and that was never the problem. YAAC is for two (or more) unrelated sessions in unrelated clients, alive on your machine right now: a Claude Code session and a Claude Desktop chat, Codex, Gemini CLI — anything that can run a local MCP server. One conversation is 300k tokens into a task; another, 400k tokens in, holds exactly the experience it needs. Give them a radio. If you can talk to both of them, now they can talk to each other.

Configuration rounds to zero. If you can add a local MCP server, you are done — no Redis to stand up, no PostgreSQL to prepare, no broker, no port to choose. Adding YAAC hands each client a radio, switched off. Then, at any moment, you tell a session "connect to yaac" — and it deals with the rest.

What it's good for

branches. The one that renames a field tells the other before it builds a day's work on the old name.

• Parallel worktrees on one repo. Two sessions refactor on different

passes the task to a Claude Code session over YAAC and collects the result. Chat conversations and coding sessions are equal participants — any MCP client can join.

• A manager conversation. You discuss what to build with Claude Desktop; it

every session on the channel.*

• Announcements. "CI is red, hold your pushes" — one broadcast reaches

session when it goes green, instead of you ferrying the news by hand.*

• Long jobs. One session babysits a slow test suite and messages the coding

\ On Claude Code 2.1.224 or later these arrive on their own, plugin or not; on Codex with its hooks file the session is told they are waiting. See Claude Code and Codex under Installing. Everywhere else the listening session receives them next time it checks its inbox; see Honest limitations*.

Installing

One step per client, and for some clients an optional second one. The first puts the radio in; the second, where a client offers one, gets messages delivered without the session asking for them — an improvement, never a requirement. Unfold your client.

All of these need uv on your PATH. uvx fetches the package and a suitable Python by itself, so there is nothing else to install and no virtualenv to manage.

Claude Code — one command, and mail is delivered; optionally, the plugin

Required.

claude mcp add yaac -s user -- uvx yet-another-agentic-chat

-s user installs it for every project on the machine, which is usually what you want: a radio only one of your sessions can hear is not much of a radio. Leave it out to add YAAC to the current project only.

Shortened. The full README is on GitHub.