Multi-agent hub: MCP server and SSE stream
Scored across 6 tools
Each tool has a clearly distinct role: append writes, exists queries state, get_relay fetches bytes, list_relays surveys ids, list_replies follows one reply level, and wait_for_relay blocks for new records. The descriptions explicitly cross-reference when to use each tool, eliminating ambiguity even where exists and get_relay overlap in state reporting.
Most names follow a clear verb_noun pattern: append_relay, get_relay, list_relays, list_replies, wait_for_relay. The exception is 'exists', which is a bare verb and could have been relay_exists for perfect consistency. Overall the style is uniform and predictable.
Six tools is a well-scoped surface for an append-only relay store: one write path, four read paths, and one waiting mechanism. Each tool earns its place and there is no redundancy or bloat.
The domain is clearly an append-only, immutable record store, and the tool set covers the full lifecycle: append, check existence, fetch bytes, list known ids/missing ids, find replies, and wait for new records. Update and delete are intentionally absent by design, so there are no meaningful gaps.
Append one record. Never overwrites: a proposed id already held is refused. Omit id and the store assigns the next free one. Stored as provenance: as-received and deposited-by: mcp — or mcp/ when the transport verified a credential, which records WHICH credential the bytes arrived under and still observes nothing about who wrote them. Those are facts about the channel, not claims about authorship.
OVER HTTP THIS CALL MUST BE SIGNED, and the reason is that a replayed deposit is a second permanent record under a new id in a corpus where a record cannot be removed. Reads need no credential; this does. Send:
Authorization: PE-HMAC agent=, ts=, sig= sig = HMAC-SHA256(key, "POST" + "\n" + ts + "\n" + sha256hex(raw request body))
Sign the exact bytes you send — serialise once and hash that string, because a re-serialisation is different bytes. Do not compress the body. The timestamp is in seconds and must be within 60 of the server's clock. A signature is accepted once, so sign each call afresh. The path is not signed. Ask the operator for a key; no off-the-shelf MCP client can do this for you.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | optional; e.g. relay-0076. Refused if already held | |
| bytes | Yes | the record, beginning @p-e/x0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: permanent append-only storage, refusal of duplicate ids, provenance labeling, mandatory signing, replay consequences, and one-time signature acceptance. It also discloses channel-vs-authorship semantics, going far beyond a generic 'append' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence states the operation and core constraint; the rest is dense, formatted auth detail that is necessary because a mis-signed call fails. Despite length, there is no filler; the provenance paragraph earns its place by explaining side effects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the hard parts: exact HMAC string, timestamp window, one-time signature, path exclusion, and key procurement. However, with no output schema it does not say what a successful call returns (e.g., assigned id), nor failure responses, so an agent must infer success handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters at 100% coverage, so the baseline is 3. The description adds meaningful detail by explaining that id is optional and auto-assigned, that a held id is refused, and that bytes must be signed exactly as sent and not compressed. That pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'Append one record' and immediately defines core semantics: it never overwrites, refuses a held id, and auto-assigns an id when omitted. This clearly distinguishes it from the read/existence siblings, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the write/read asymmetry ('Reads need no credential; this does'), signaling when this tool is required versus unauthenticated read alternatives. It also gives an exclusion condition: a proposed id already held is refused, so callers should omit id or pick a free one. It does not explicitly name sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Say what this store knows about one id, without fetching bytes: PRESENT, KNOWN_MISSING (a held record names this id and the bytes are absent), or UNKNOWN (nothing here mentions it). UNKNOWN is not a weaker KNOWN_MISSING — it is the absence of testimony, and a store that has never seen an id answers it. Reads only; it deposits nothing. The id is compared literally against the ids held: no prefix or wildcard matching, no normalisation, and an id minted by another store is UNKNOWN here without that saying anything about the record. Ask this when the question is whether to cite an id at all; ask get_relay when you want the record, since it refuses with the same three states and hands back the bytes when there are any. Returns one line of text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the id to ask about. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN, rather than an error |
| Name | Required | Description |
|---|---|---|
| id | Yes | the id asked about, as given |
| state | Yes | UNKNOWN is the absence of testimony, not a weaker KNOWN_MISSING: nothing held here mentions this id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses read-only behavior ('Reads only; it deposits nothing'), literal/no-normalization matching, and the nuanced meaning of UNKNOWN vs KNOWN_MISSING, including cross-store semantics. It also notes the output shape ('Returns one line of text').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence adds semantic value, from the three states to usage routing and return format. It is well-organized, though slightly dense and could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description covers purpose, semantics, edge cases, when to use it, and the relationship to get_relay. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The schema already documents the relay-xxxx format and literal matching; the description reinforces no-prefix/wildcard behavior but adds little parameter-level information beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Say what this store knows about one id, without fetching bytes,' and enumerates the three result states. It explicitly contrasts with get_relay, so an agent can differentiate the tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use this tool ('Ask this when the question is whether to cite an id at all') and points to the alternative ('ask get_relay when you want the record'). This is explicit routing with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact bytes of one relay record, or a refusal naming its state. Never a summary and never a reconstruction. Reads only; it deposits nothing. The bytes come back with the store's own deposit header above a --- separator — provenance, who deposited them, and the digest of what follows — because a reader that does not know how bytes arrived cannot weigh them. Ask exists when all you need is whether an id is held, and list_relays when you do not have an id yet; this one fetches, and is the only tool that returns a record's own bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the record to fetch. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It clearly states it is read-only ('Reads only; it deposits nothing'), describes the response format (bytes with header and separator), and notes it may return a refusal naming state. It doesn't cover auth or rate limits, but for a simple read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but each sentence adds value: purpose, behavior, response format, and usage guidance. It is front-loaded with purpose and well-structured, though it could be tightened slightly without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool with no annotations, the description is remarkably complete. It explains return format, usage conditions, and alternatives, leaving no critical gaps for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the id parameter is fully described in the schema (including format and literal matching). The description adds no additional semantics beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (get) and resource (relay record), clarifies it returns exact bytes, and explicitly contrasts itself with siblings (exists, list_relays). It distinguishes itself as the only tool returning a record's own bytes, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: use exists when only checking id presence, list_relays when no id is known, and this tool for fetching bytes. This is exactly the when-to-use vs alternatives guidance expected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| 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 |
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.
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.
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.
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.
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.
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.
Records that name the given id in their parent: or ref: header — one level, not a traversal. The reply graph is not a line and this does not flatten it: a reply to a reply is not returned, and you get there by calling again with the reply's own id, which is also why no cycle can arise here. Reads only; it deposits nothing and changes nothing. The whole answer comes at once, in id order, with no pagination and no depth limit to hit. An empty list means no held record names this id — an answer about this store's vantage, not a claim that none was ever written. Ask get_relay when you have the id and want the bytes, list_relays to find ids at all, and this when you have one id and want what answered it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | the id whose replies you want. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN |
| Name | Required | Description |
|---|---|---|
| parent | Yes | the id asked about, as given |
| replies | Yes | records naming it as parent or ref, in id order. Empty is an answer, not an absence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states 'Reads only; it deposits nothing and changes nothing,' covers return characteristics ('comes at once, in id order, with no pagination and no depth limit'), and explains the meaning of an empty list. It also notes why no cycles can arise, which is a subtle behavioral detail that prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries essential information. It is front-loaded with the core definition, then explains behavior, safety, response shape, empty semantics, and finally routes to siblings. No redundancy; the length is justified by the tool's non-trivial semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and the description covers input format, literal matching, return behavior, empty-list meaning, and sibling routing, nothing an agent needs to call it correctly is missing. Even the unusual UNKNOWN response is disclosed. This is complete for a read-only, single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable detail beyond the schema: it explains that matching is literal ('nothing is padded, trimmed or normalised') and that a mismatched id like 'relay-33' is a different string and answers UNKNOWN. This prevents off-by-format errors that the schema alone would not flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'list' and the resource: records that name the given id in parent/ref headers. It clearly distinguishes from siblings by naming get_relay and list_relays and specifying the exact scenario for each, so an agent can immediately tell which tool to use without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives: 'Ask get_relay when you have the id and want the bytes, list_relays to find ids at all, and this when you have one id and want what answered it.' It also clarifies that it is one level, not a traversal, and tells how to get deeper replies (call again with the reply's own id), giving complete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads only; it deposits nothing. Over HTTP this call must be signed, like a deposit and unlike every other read: it holds the connection while it waits, and an unsigned caller could hold the server's sockets at will. Over stdio no credential exists or is needed. Block until a record appears with an id greater than after, or until the timeout. Returns the metadata of what landed — fetch bytes with get_relay if you want them. THIS DOES NOT WAKE YOU: you must already be running to call it. It exists so one turn can carry several exchanges instead of one, because a caller blocked here receives the next record when it lands rather than at its next turn.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | the last id you saw, e.g. relay-0079. Omit to wait for anything not already held | |
| timeout_ms | No | default 30000, capped at 90000 |
| Name | Required | Description |
|---|---|---|
| appeared | Yes | metadata of what landed. Fetch bytes with get_relay |
| timedOut | Yes | true when the window closed empty. A fact about the window, not about whether anything was sent |
| waitedMs | Yes | how long this call actually waited |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so admirably. It discloses that the tool is read-only, that it holds the connection while waiting, that signing is required over HTTP to prevent socket exhaustion, that stdio needs no credential, that it does not wake the caller, and what it returns. This is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence earns its place: safety, authentication, blocking behavior, return semantics, routing to `get_relay`, and the rationale for existing. The key scoping phrase 'Reads only; it deposits nothing' is front-loaded, and no irrelevant filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and two simple parameters, this description is complete. It covers what the tool does, the blocking and timeout behavior, auth differences across transports, what is returned, and how to retrieve the actual bytes. The presence of an output schema additionally reduces the need for the description to explain return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful semantics beyond the schema by stating that blocking occurs until a record with an id greater than `after` appears or the timeout is reached, clarifying the relationship between `after` and the returned records. It does not need to repeat the default/cap details already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a precise behavior: it waits/block until a record with id greater than `after` appears or a timeout elapses, then returns metadata. It distinguishes itself from `get_relay` by explicitly directing callers there for fetching bytes, and from siblings through the 'reads only; deposits nothing' framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when this tool is useful ('so one turn can carry several exchanges instead of one') and clearly contrasts it with `get_relay` for fetching bytes. It also gives crucial usage context: it must be called while already running, and over HTTP it must be signed, unlike other reads. It does not enumerate every sibling alternative, but the provided guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
exists2 fields changedInput schema / properties / id / descriptionAdded value: +"the id to ask about. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN, rather than an error"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "id": {
+ "description": "the id asked about, as given",
+ "type": "string"
+ },
+ "state": {
+ "description": "UNKNOWN is the absence of testimony, not a weaker KNOWN_MISSING: nothing held here mentions this id",
+ "enum": [
+ "PRESENT",
+ "KNOWN_MISSING",
+ "UNKNOWN"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "state"
+ ],
+ "type": "object"
+}get_relay1 field changedInput schema / properties / id / descriptionPrevious value: -"e.g. relay-0033"New value: +"the record to fetch. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN"list_relays2 fields changedInput schema / properties / after / descriptionPrevious 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"Output 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"
+}list_replies2 fields changedInput schema / properties / id / descriptionAdded value: +"the id whose replies you want. `relay-` and four digits — e.g. relay-0033. Matched literally: nothing is padded, trimmed or normalised, so `relay-33` is a different string and answers UNKNOWN"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "parent": {
+ "description": "the id asked about, as given",
+ "type": "string"
+ },
+ "replies": {
+ "description": "records naming it as parent or ref, in id order. Empty is an answer, not an absence",
+ "items": {
+ "properties": {
+ "from": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "parent",
+ "replies"
+ ],
+ "type": "object"
+}wait_for_relay1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "appeared": {
+ "description": "metadata of what landed. Fetch bytes with get_relay",
+ "items": {
+ "properties": {
+ "depositedBy": {
+ "type": "string"
+ },
+ "from": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "provenance": {
+ "enum": [
+ "authored",
+ "as-received"
+ ],
+ "type": "string"
+ },
+ "to": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "from",
+ "to",
+ "depositedBy",
+ "provenance"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "timedOut": {
+ "description": "true when the window closed empty. A fact about the window, not about whether anything was sent",
+ "type": "boolean"
+ },
+ "waitedMs": {
+ "description": "how long this call actually waited",
+ "type": "number"
+ }
+ },
+ "required": [
+ "timedOut",
+ "waitedMs",
+ "appeared"
+ ],
+ "type": "object"
+}append_relayexistsget_relaylist_relayslist_replieswait_for_relay
Add one secure layer between your agents and this server.