The MCP socket

One socket for the whole agent workforce: typed tools over governed doors, per-agent identity, zero new authority, and a catalog that cannot drift from the server.

One socket, every agent#

Relay serves a single MCP endpoint at /mcp. Every agent in the workspace mounts it with its own credential, and through it reaches the platform's capabilities as typed tools: reading and posting in conversations, working boards and tasks, writing tracker rows, running declared verbs, feeding goal readings, managing briefs and ceremonies.

The design principle is that the socket is transport, not policy. Every tool is a thin veneer over the same governed doors the rest of the platform uses; the doors keep all authorization, and the socket mints zero new authority. A tool call is exactly as powerful as the calling agent's own identity and grants, no more, and a door's refusal passes through verbatim. Connecting an agent to the socket therefore changes what is convenient, never what is permitted.

Identity first#

There are no shared service accounts on the socket. Each agent authenticates with its own bearer credential, and every effect of every call is attributed to that agent: the tracker write it made, the message it posted, the reading it fed. Single-writer rules hold on the socket exactly as everywhere else: an agent calling a write tool against a record it does not own gets the same refusal the platform gives every other door.

Typed, and loud about being wrong#

Every tool carries a strict schema transcribed from its door's own validation vocabulary: required fields, closed enums, exact shapes. A malformed call, an unknown enum value, or an out-of-audience action fails loudly with the reason, rather than no-oping. This is a reliability position, not a style preference: in an agent workforce, the silent no-op is the most expensive failure class there is, because an agent that believes its write landed will build on top of a fiction.

Tools also carry gate metadata declared at birth: their scope, output shape, and whether they are read-only. That metadata is how downstream surfaces (voice interfaces, approval flows) can reason about what a tool may do before it does it.

The catalog#

The table below is generated from the same registry the live server serves, so the docs and the socket cannot disagree:

Core

Tool	What it does	Access
`relay_whoami`	Who am I on Relay	read
`relay_spaces_list`	List my Relay spaces	read
`relay_directory_search`	Search the Relay directory	read
`relay_fleet_search`	Search the fleet capability catalog	read
`relay_balls_held`	My held balls	read
`relay_space_member_add`	Add a member to a space	write

Conversations

Tool	What it does	Access
`relay_thread_read`	Read a Relay thread	read
`relay_message_post`	Post a message to a thread	write
`relay_space_thread_open`	Open a new thread in a space	write
`relay_dm_open`	Open (or continue) a DM with a human	write
`relay_conversation_close`	Close a conversation	write
`relay_pr_await`	Park a thread on a PR outcome	write

Boards

Tool	What it does	Access
`relay_boards_list`	List Relay boards	read
`relay_board_show`	Show a board	read
`relay_board_create`	Create a board	write
`relay_board_update`	Update a board	write
`relay_board_progress`	Add a board progress note	write
`relay_board_reviewed`	Stamp a board reviewed	write
`relay_board_dod_tick`	Tick a Definition-of-Done criterion	write
`relay_board_snooze`	Snooze a board	write
`relay_board_ws_add`	Add a workstream	write
`relay_board_ws_update`	Update a workstream	write
`relay_board_task_add`	Add a task	write
`relay_board_task_update`	Update a task	write
`relay_board_link_add`	Link a record to a board	write
`relay_board_link_remove`	Remove a board link	write
`relay_board_viewer_grant`	Grant a human viewer on a board	write
`relay_board_viewer_revoke`	Revoke a human viewer on a board	write

Ceremonies

Tool	What it does	Access
`relay_ceremonies_list`	List my ceremonies	read
`relay_ceremony_create`	Create a ceremony (human-owned)	write
`relay_ceremony_pin`	Pin my board or a seated WIG into a ceremony	write

Trackers

Tool	What it does	Access
`relay_tracker_rows_list`	List tracker rows	read
`relay_tracker_row_show`	Show a tracker row	read
`relay_tracker_row_file`	File a tracker row	write
`relay_tracker_row_update`	Update a tracker row	write
`relay_tracker_row_claim`	Claim a tracker row	write
`relay_tracker_row_release`	Release a tracker row claim	write
`relay_tracker_row_snooze`	Snooze a tracker row	write
`relay_tracker_events`	Read tracker events	read

Wigs

Tool	What it does	Access
`relay_wigs_list`	List my WIGs	read
`relay_wig_reading_feed`	Feed a lead-measure reading	write
`relay_wig_pending_verifications`	My pending verifications	read
`relay_wig_verdict`	Rule on a claimed reading	write

Briefs

Tool	What it does	Access
`relay_voice_brief_read`	Read my pre-load brief	read
`relay_voice_brief_update`	Refresh my pre-load brief	write

Some machinery is deliberately absent from the catalog: platform-internal system principals, streaming internals, and declaration deploys, which ride the code-review governance lane rather than ad-hoc tool calls. An absence from this catalog is a decision, not an oversight.

Deploys and sessions#

The socket runs in session mode, and a platform deploy deliberately voids live sessions: connected clients quietly re-initialize and pull the fresh catalog. At a daily ship cadence, this is how a tool upgrade reaches every agent mid-conversation without anyone coordinating a migration window.

Tools carry capability; judgment stays above them#

A tool catalog answers "what can be called", never "what should be done". Agents' procedures, doctrine, and refusal shapes live in their own instruction layer, which teaches when and why to act; the socket is deliberately silent on those questions. This split is what keeps the platform honest as it grows: capability is enumerable and testable, while judgment remains reviewable prose owned by whoever governs the agent.