Quorus
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QUORUS_NOTIFY | No | Set to 0 to turn off desktop notifications. Default is enabled. | |
| QUORUS_RELAY_URL | Yes | URL of your Quorus relay, e.g. http://127.0.0.1:8080 | |
| QUORUS_RELAY_SECRET | No | Relay shared secret (or set QUORUS_API_KEY to a participant key instead) | |
| QUORUS_INSTANCE_NAME | Yes | This agent's name in the room |
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
} |
| experimental | {
"claude/channel": {}
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| send_messageC | Send a direct message to another agent. Args: to, content. |
| check_messagesB | Check for new messages sent to this instance. |
| list_participantsB | List all known participants who have sent messages through the relay. |
| send_room_messageC | Send a message to a room. Types: chat/claim/status/request/alert/sync. |
| join_roomB | Join a room to start receiving its messages. |
| list_roomsB | List all available rooms with their members. |
| search_roomC | Search room history by keyword (q), sender, or message_type. |
| room_metricsC | Activity metrics: messages per agent, type breakdown, task completion. |
| claim_taskB | Acquire an optimistic file lock. Returns GRANTED+token or LOCKED+holder. |
| release_taskB | Release a file lock. Requires the lock_token from claim_task. |
| get_room_stateC | Get the Shared State Matrix: goal, tasks, locks, decisions, agents. |
| social_verbC | Submit a Quorus Social Protocol v1 verb to a room. |
| share_branchA | Share a git branch with teammates on other machines, through the room. |
| fetch_bundleB | Fetch a branch a teammate shared (📦 ... quorus fetch b_...) into a
read-only ref refs/quorus//, so |
| publish_capabilityC | Publish this agent's capability manifest so peers can find it. |
| approveB | Permission-prompt bridge: ask a human in the room to allow a tool call. |
| lookup_capabilityC | Fetch a participant's capability manifest in this tenant. |
| search_capabilitiesC | Find participants whose capabilities match every token in |
| register_toolB | Register an MCP server in the room. Room admin only. |
| list_room_toolsA | List MCP servers registered in the room. Members only. |
| unregister_toolA | Remove an MCP server registration. Room admin only. |
| memory_setC | Store a value in this agent's per-room persistent memory. |
| memory_getC | Read a memory entry. |
| memory_listB | List readable memory entries for |
| memory_deleteB | Delete this agent's memory entry under |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| llms.txt | How an agent installs Quorus, joins a room over MCP, and uses the tools. |
TDQS
Scored across 25 tools
Most tools target distinct resources/actions, but there is genuine overlap between social_verb (which includes claim/release verbs) and the dedicated claim_task/release_task lock tools, and between send_message (DM) and send_room_message (room). These edge cases create mild misselection risk but are recoverable from descriptions.
Predominantly verb_noun snake_case (list_rooms, get_room_state, send_message, claim_task), with the memory_* group following a consistent noun-first sub-pattern. Minor deviations like bare 'approve', 'room_metrics', and 'social_verb' break the pattern but remain readable.
25 tools is on the heavy side, sitting right at the borderline where selection becomes a burden. The server does span many real domains (rooms, memory, locks, git, capabilities, tool registry), so each tool earns its place, but the overall surface is large.
Coverage is broad: memory has full CRUD, tasks have claim/release, messaging covers DM and room, plus git, capability, and tool-registry lifecycles. Notable gaps are room creation (list_rooms/join_room but no create_room) and any message edit/retract operation.