p-e-relay

Overview Schema Source Related Servers Discussions Admin

list_relays

List relay IDs in the store, showing present and known missing entries, optionally starting after a given ID to find newer records.

Instructions

Reads only; it deposits nothing. Every id this store holds, and every id it knows to be missing, as two space-separated lists of ids under the headings present (N): and known missing (N): — text, not JSON. Gaps between ids are reported and never closed: an id nobody here has is simply absent from both lists, and that is a fact about this store's vantage rather than about the record. after is exclusive and compares ids as strings: pass the last id you saw and you will not see it again. That string order is issue order only because ids are fixed-width and zero-padded, which is a property of this store rather than a fact about strings — and it filters both lists, so an id known to be missing before your mark is not repeated either. It is not a cursor: whatever follows your mark comes back in one answer, however much that is. Ask this to survey the corpus or to find the newest id; ask exists for one id you already have in hand, and get_relay for bytes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`after`	No	optional; a relay id — `relay-` and four digits, e.g. relay-1100 — and only ids greater than it are returned. Omit it for the whole store

Output Schema

TableJSON Schema

Name	Required	Description
`after`	Yes	the id the listing starts after, or null when the whole store was asked for
`present`	Yes	ids this store holds
`knownMissing`	Yes	ids a held record names and whose bytes are absent. Gaps are reported, never closed

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Sep 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "after": {
+      "description": "the id the listing starts after, or null when the whole store was asked for",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "knownMissing": {
+      "description": "ids a held record names and whose bytes are absent. Gaps are reported, never closed",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "present": {
+      "description": "ids this store holds",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "present",
+    "knownMissing",
+    "after"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.1.2Sep 17, 2026

changedInput schema / properties / after / description

Previous value: -"optional; return ids greater than this"New value: +"optional; a relay id — `relay-` and four digits, e.g. relay-1100 — and only ids greater than it are returned. Omit it for the whole store"

First observedv0.1.0Sep 17, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so richly. It discloses that the tool is read-only ('Reads only; it deposits nothing'), explains the semantics of missing ids, describes the exclusive string comparison of `after`, clarifies that it is not a cursor and returns everything in one answer, and notes that string order equals issue order only due to fixed-width zero-padded ids. This goes well beyond what any annotation could provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded with the most important behavioral fact ('Reads only; it deposits nothing'). Every sentence adds information, but the prose is somewhat long and winding, with parenthetical asides that could be tightened. It earns a 4 rather than 5 because the length and stylistic complexity slightly reduce scannability for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one optional parameter, no annotations, and an output schema, the description is complete. It covers the output format, the meaning of missing ids, the filtering behavior, the cursor-like misconception, and usage guidance. An agent has everything needed to invoke it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains that `after` is exclusive, compares ids as strings, filters both lists, and is not a cursor. This is valuable context that helps an agent use the parameter correctly, though the schema already documents the basic format and optionality.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it lists every id the store holds and every id known to be missing, with explicit output format. It also distinguishes itself from siblings by naming exists and get_relay as alternatives. The scope is clear and the tool is easily differentiated from list_replies and other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: 'Ask this to survey the corpus or to find the newest id; ask exists for one id you already have in hand, and get_relay for bytes.' This provides direct routing guidance and names alternatives, satisfying the when-to-use and when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server