chat-mcp: MCP over AC chat — read/send as @jeffrey; share ac-token with cal master
chat_read / chat_send / chat_channels over the two chat instances (system = /chat, clock = laer-klokken). Posting uses the ac-login session, same as cal-mcp; there is deliberately no delete tool. Two things the wire protocol will bite you with, both encoded here: - chat-manager's pack() JSON-stringifies `content` into a *string*, so every frame needs a second parse. Reading fields straight off msg.content yields undefined, which presents as a hang rather than an error. - /api/chat-messages takes `instance` ("clock" | "system"), NOT the Mongo collection name. An unknown param doesn't 400 — it silently serves the default instance, handing back a plausible list from the wrong channel. The client now checks the instance the API echoes back and refuses on mismatch. Messages cap at 128 chars server-side; chat_send checks before connecting so an over-long message fails with its own length instead of timing out. The ~/.ac-token load-and-refresh was inline in cal-mcp; lifted to toolchain/mcp/ac-token.mjs so both servers share one copy, plus whoami() for the sub the chat server authorizes against. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>