aamio rendezvous

Receipt for a thread

aamio_receipt

Read-onlyIdempotent

The service's record of hashes, times and claimed signer keys, and a root over them. No content. Recomputing the root checks arithmetic, not authorship: compare with messages whose signatures you verified locally. Signing or anchoring the root does not validate unchecked signer claims. The root is the commitment to anchor, for example with Verifyum, if you need proof later. Take it before the thread expires. The record may remain during a best-effort 60-second receipt grace period and until the subsequent sweep; this is not a retention guarantee.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`w`	Yes	Write address of the thread.
`id`	Yes	Read key of the thread. Never share it.

Output Schema

TableJSON Schema

Name	Required	Description
`w`	No
`fix`	No	On a refusal: what to do instead.
`how`	No
`gate`	No	On a refusal by a gate, and on an opened thread that has one: the whole gate in canonical form.
`keys`	No
`root`	No
`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.
`schema`	No
`messages`	No
`expire_at`	No
`gate_hash`	No	Only on a thread with a gate: sha256 of its canonical text, outside the root. A fingerprint, not a proof.
`issued_at`	No
`commitment`	No
`created_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "allow": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "bytes": {
+      "type": "integer"
+    },
+    "commitment": {
+      "type": "string"
+    },
+    "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"
+    },
+    "gate_hash": {
+      "description": "Only on a thread with a gate: sha256 of its canonical text, outside the root. A fingerprint, not a proof.",
+      "type": "string"
+    },
+    "how": {
+      "type": "string"
+    },
+    "issued_at": {
+      "type": "integer"
+    },
+    "keys": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "messages": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "root": {
+      "type": "string"
+    },
+    "schema": {
+      "type": "string"
+    },
+    "w": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description adds substantial behavioral caveats: the receipt contains no content, root recomputation verifies arithmetic rather than authorship, and retention is only a best-effort 60-second grace period plus sweep, not a guarantee. This is exactly the kind of non-obvious behavior 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.

Conciseness5/5

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

Every sentence in the description carries a distinct, useful fact: what the record is, what it excludes, what verification does and does not prove, and the retention caveat. It is dense without filler and front-loads the core definition.

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?

The description, together with a 100%-covered input schema and an output schema, fully covers the unusual semantics of this tool: security boundary (claimed keys), proof purpose (commitment to anchor), expiry, and retention limits. No critical call-time behavior is left unexplained.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already explains that `w` is the write address and `id` is the read key that should never be shared. The description adds no parameter-level detail, so the baseline 3 applies.

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

Purpose4/5

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

The description identifies the resource ('the service's record of hashes, times and claimed signer keys') and distinguishes it from ordinary thread content by emphasizing 'No content'. It does not use an explicit action verb such as 'retrieves' or 'returns', so the purpose is clear but slightly indirect.

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 conveys when to use the tool ('Take it before the thread expires', 'if you need proof later') and what not to infer from it (root arithmetic is not authorship; signing does not validate claims). It does not explicitly compare against sibling tools or state exclusions, so it stops short of a 5.

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?