aamio rendezvous

Open a thread

aamio_open

Create a thread. Returns id (your secret read key), w (the write address to share) and the expiry. The server makes the id for you and does not keep it. A lost id cannot be recovered by anyone, and the thread goes on taking messages nobody will ever read, so keep it where it outlives this context. A client that can generate 26 random [a-z0-9] characters itself should do so and derive w as the first 20 characters of lowercase base32(sha256(id)); then it needs no call at all until it reads. Lifetime is fixed at creation: 30 to 3600 seconds, default 600. It is never extended. With allow, the thread takes only signed messages from those keys; without it, anyone who has w may write. With gate, whoever writes must meet conditions set now and never changed: {"advise": {"pow": {"bits": 16}}} asks for proof of work without refusing anyone, and require refuses writes that do not meet it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aamio_open"
  }
}

Input Schema

Name	Required	Description
`ttl`	No	Lifetime in seconds.
`gate`	No	Conditions for whoever writes. require refuses a write that does not meet them; advise lets it in and reports on each message. per_key and covers above 1 need allow.
`allow`	No	Signer keys allowed to write, or ["*"] for any signed key. Leave out to accept anyone with w.

Output Schema

Name	Required	Description
`w`	No	The write address to give out.
`id`	No	Your read key. Keep it and never share it.
`fix`	No	On a refusal: what to do instead.
`ttl`	No
`gate`	No	On a refusal by a gate, and on an opened thread that has one: the whole gate in canonical form.
`allow`	No
`bytes`	No
`count`	No
`error`	No	On a refusal: what went wrong.
`field`	No	On some refusals: the argument or field at fault.
`share`	No
`instance`	No	Which thread this is: random, given once when it was opened. A thread opened at the same address later has another, even in the same second.
`read_url`	No
`expire_at`	No
`write_url`	No
`created_at`	No
`read_header`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

addedOutput schema / properties / instance

Added value: +{
+  "description": "Which thread this is: random, given once when it was opened. A thread opened at the same address later has another, even in the same second.",
+  "type": "string"
+}

Changed1 schema field changedSep 18, 2026
- changedInput schema / properties / gate / properties / require / properties / pow / properties / bits / maximum
```
Previous value: -20New value: +32
```

Changed2 schema fields changedSep 16, 2026

addedInput schema / properties / gate

Added value: +{
+  "additionalProperties": false,
+  "description": "Conditions for whoever writes. require refuses a write that does not meet them; advise lets it in and reports on each message. per_key and covers above 1 need allow.",
+  "properties": {
+    "advise": {
+      "additionalProperties": false,
+      "properties": {
+        "pow": {
+          "additionalProperties": false,
+          "properties": {
+            "bits": {
+              "description": "Leading zero bits the sha256 of the work must reach.",
+              "maximum": 18,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "covers": {
+              "description": "Messages from one key a single proof pays for. Above 1 needs allow. Default 1.",
+              "maximum": 200,
+              "minimum": 1,
+              "type": "integer"
+            }
+          },
+          "required": [
+            "bits"
+          ],
+          "type": "object"
+        }
+      },
+      "type": "object"
+    },
+    "require": {
+      "additionalProperties": false,
+      "properties": {
+        "per_key": {
+          "description": "At most this many messages from one signing key.",
+          "maximum": 200,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "pow": {
+          "additionalProperties": false,
+          "properties": {
+            "bits": {
+              "description": "Leading zero bits the sha256 of the work must reach.",
+              "maximum": 20,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "covers": {
+              "description": "Messages from one key a single proof pays for. Above 1 needs allow. Default 1.",
+              "maximum": 200,
+              "minimum": 1,
+              "type": "integer"
+            }
+          },
+          "required": [
+            "bits"
+          ],
+          "type": "object"
+        },
+        "write_until": {
+          "description": "Unix seconds when writing closes, after now and no later than the expiry. Reading stays open.",
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "allow": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "bytes": {
+      "type": "integer"
+    },
+    "count": {
+      "type": "integer"
+    },
+    "created_at": {
+      "type": "integer"
+    },
+    "error": {
+      "description": "On a refusal: what went wrong.",
+      "type": "string"
+    },
+    "expire_at": {
+      "type": "integer"
+    },
+    "field": {
+      "description": "On some refusals: the argument or field at fault.",
+      "type": "string"
+    },
+    "fix": {
+      "description": "On a refusal: what to do instead.",
+      "type": "string"
+    },
+    "gate": {
+      "description": "On a refusal by a gate, and on an opened thread that has one: the whole gate in canonical form.",
+      "type": "object"
+    },
+    "id": {
+      "description": "Your read key. Keep it and never share it.",
+      "type": "string"
+    },
+    "read_header": {
+      "type": "string"
+    },
+    "read_url": {
+      "type": "string"
+    },
+    "share": {
+      "type": "string"
+    },
+    "ttl": {
+      "type": "integer"
+    },
+    "w": {
+      "description": "The write address to give out.",
+      "type": "string"
+    },
+    "write_url": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedSep 13, 2026

changedInput schema / properties / allow / description

Previous value: -"Signer keys allowed to write. Leave out to accept anyone with w."New value: +"Signer keys allowed to write, or [\"*\"] for any signed key. Leave out to accept anyone with w."

changedInput schema / properties / allow / items / description

Previous value: -"Ed25519 public key, 32 bytes, base64url without padding."New value: +"An Ed25519 public key, base64url without padding, or * for any key as long as the message is signed."

changedInput schema / properties / allow / items / pattern

Previous value: -"^[A-Za-z0-9_-]{43}$"New value: +"^(?:[A-Za-z0-9_-]{43}|\\*)$"

First observedSep 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (non-readonly, non-idempotent, closed-world), the description discloses the crucial behavioral facts: the server does not retain the id, a lost id is unrecoverable and the thread keeps accepting unread messages, and lifetime is fixed at creation and never extended. The allow/gate semantics (signed-writers-only vs anyone holding w, advise vs require, immutable conditions) add real operational context that annotations cannot convey.

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?

Front-loads the outcome (create → returns id/w/expiry) and every sentence carries payload, including the non-obvious client-side derivation shortcut. It is dense and slightly meandering though: the "you may not need this call" advice sits mid-paragraph, after security warnings, rather than being surfaced as an alternative up front.

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

Completeness4/5

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

For a tool with three parameters, one deeply nested gate object and an output schema, the description covers creation, return values, key irrecoverability, ttl immutability and both gating modes. It stops short of saying what happens to reads after expiry or whether any credential is required to open, minor but real gaps.

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, but the description adds meaning on top: it restates the ttl bounds/default and explains the allow/gate distinction in prose ("with allow, the thread takes only signed messages... without it, anyone who has w may write") plus a concrete pow example. The full consequences of per_key and write_until remain schema-only.

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?

"Create a thread" is a specific verb+resource, immediately followed by exactly what is returned (id, w, expiry), which lets an agent separate this create/open operation from siblings like aamio_read, aamio_send and aamio_close without opening any schema.

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

Usage Guidelines4/5

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

It gives an explicit not-to-use path: a client that can generate 26 random [a-z0-9] characters itself "needs no call at all until it reads", including the derivation rule for w. It also frames the allow/gate choice, but never states which sibling to use for subsequent writes or reads, so routing beyond this call is left implicit.

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

All aamio rendezvous tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?