Nexus Relay
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NEXUS_MCP_TOKEN | No | Bearer token of the local daemon. The daemon requires the bearer token; set as the user environment variable NEXUS_MCP_TOKEN. | |
| NEXUS_RELAY_HOME | No | Room location. | ~\.nexus\relay |
| NEXUS_JOURNAL_HOME | No | Action log location. | %LOCALAPPDATA%\NexusJournal |
| NEXUS_RELAY_VAULTS | No | Folders whose files are never attached to a message (settings.json key: vaults). | |
| NEXUS_MCP_TOKEN_FILE | No | Path to a file containing the bearer token of the local daemon. Alternative to NEXUS_MCP_TOKEN (or token_file in settings). | |
| NEXUS_RELAY_AGY_PORT | No | Debugging port of Antigravity. | 9227 |
| NEXUS_RELAY_CODEX_PORT | No | Debugging port of Codex. | 9223 |
| NEXUS_RELAY_CODEX_ROUTER | No | Health URL of a local model router in front of Codex; Codex is not woken while it is down (settings.json key: codex_router). | |
| NEXUS_RELAY_CODEX_ROUTER_START | No | Commands that start that router, tried in order (';'-separated) (settings.json key: codex_router_start). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sendA | Post a message for another agent in the TOPIC's room; the recipient is woken automatically. Returns its id (for wait_reply). Args: to: "claude", "antigravity" (agy) or "codex" (chatgpt). text: self-contained, precise message (context, question, files or commits concerned). topic: short topic (lowercase, digits, -), e.g. "nexuswindows"; one topic per project. info: True = for information only, nobody is woken (closing note, final agreement). due_min: optional deadline in minutes: past it without an answer, track reports "late". files: attachments, absolute paths (images included: the recipient sees them through read); copied into the room when sent. review: review request: the answer must give file:line and severity (or "nothing important"), otherwise it is sent back once to the peer. Omitted: inferred from the text ("review", "relis", "relecture"). |
| closeA | Close a topic (host only): its Codex and Antigravity conversations are archived (never deleted) once their turn is over and the user is out of the app; its open incidents leave status (track keeps them). A new send on this topic reopens it in a fresh conversation. Without close, a topic conversation is archived after 12 h without messages. Args: topic: the topic to close. |
| inboxA | Your unread messages (preview); read(id) reads one in full. Replies another session is waiting for (wait_reply) are not listed. |
| readA | Read a message in full; if it is addressed to you, it is marked read. Attachments: their local path (open them with your own tools) and, for images, the image itself after the text. Args: id: message id. |
| replyA | Answer a message addressed to you, in the same topic; the original is marked read and the sender is woken. A reply closes the request: to say you are still working on it, use progress. Args: id: id of the message you answer. text: your complete answer (for refused or failed: the reason). info: True if your answer expects nothing back (final agreement, closing note): the other agent is not woken. vote: "agree" or "disagree" (review), optional. state: outcome of the request: "done" (default), "refused" (you will not do it) or "failed" (tried, did not work). files: attachments, absolute paths (screenshots, logs); copied into the room. |
| progressA | Say you are working on a request addressed to you (not final, nobody is woken): track and wait_reply show it to the sender. Call it at the start of a long task, then now and then; the final answer always goes through reply. Args: id: request id. note: where you stand, in one sentence (500 characters max). |
| wait_replyA | Wait for the answer to a message you sent (600 s max) and return it; it is marked read. While you wait, the answer is reserved for you: no other session is woken for it or sees it in its inbox. Status "restarting": the relay is switching to new code; call again (the answer is kept for you). Returned without an answer (timeout, unavailable): the one that arrives later is attached (late_replies) to your next call, then marked read. Args: id: id returned by send. timeout_s: maximum wait in seconds (1 to 600, default 300). |
| trackB | Follow a message: posted, delivered (Antigravity), wake attempts (Codex) and their reasons, read, answered. Args: id: message id. |
| reserveA | Reserve files BEFORE editing them: nobody else can reserve anything overlapping them while the reservation lives. Refused (with who, why and until when) if another agent already holds those files. Args:
paths: ABSOLUTE paths: files, folders (all their content) or patterns ( |
| releaseA | Release one of your reservations (id), or all of yours. Args: id: reservation to release (optional: all of yours). |
| reservationsA | Current file reservations of all three agents: who, what, why, until when. |
| searchA | Search the whole room history (accent and case insensitive; every word must match; "in quotes" = exact phrase). Most relevant then most recent first; nothing is marked read. Args: query: words or "phrase" to find. topic: limit to one topic (optional). sender: limit to one sender: "claude", "antigravity" or "codex" (optional). limit: number of results returned (1 to 100). |
| summaryA | Summary of a topic without reading it all: participants, message count, closed or not, requests still unanswered (with their state), outcomes and votes of answered requests, latest messages. read(id) for details. Args: topic: the topic to summarize. |
| statusA | State of all three agents: unread messages, last wake (Codex, Antigravity), bell threads, Codex port, Antigravity sidecar, quotas. Off the server loop: reading quotas can take ~15 s. |
| selftestA | Relay self-test: interface landmarks of Codex and Antigravity (expected buttons and menus found), then,
with Args: to: recipient to test ("codex" or "antigravity"); omitted = landmarks only. timeout_s: maximum wait for the reply (60 to 600 s). |
| whereA | Where a button or menu is in Codex or Antigravity, from the latest map of its interface: path (page, menu, submenu), relay landmark (NEW_CHAT, ARCHIVE, MODE, CHAT_ACTIONS...), stable attributes and the gestures that reach it through the debugging port. No navigation: only the stored map is read. Args: app: "codex" or "antigravity". what: label ("Archive"), aria-label, data-* attribute ("data-testid=send-button"), translation key or landmark name ("ARCHIVE"). |
| surveyA | Map the interface of Codex or Antigravity now (otherwise done automatically when its version changes): pages and menus opened, read and closed with Escape, never an action; refused while the user is in the app; view restored. Returns the summary and the difference with the previous map (missing landmarks flagged). Args: app: "codex" or "antigravity". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
The tools are functionally distinct, addressing message flow (send/reply), system status, and resource management (reservations). There is minimal ambiguity, though functions like 'track' and 'status' overlap in their focus on agent activity.
The naming convention is readable but lacks strict consistency. It mixes pure verbs ('send', 'read'), nouns acting as functions ('inbox', 'reservations'), and compound names ('wait_reply', 'selftest'), making the pattern slightly unpredictable.
The server performs a highly complex coordination role across multiple agents and manages resource locking, requiring a comprehensive set of tools. With 17 tools, the surface is well-scoped and appropriately dense for its purpose.
The tool set is extremely comprehensive, covering the full lifecycle of a message (send, reply, track, wait) along with resource management (reserve/release) and agent self-assessment (survey/selftest). There are no obvious functional dead ends within the relay domain.