Skip to main content
Glama

aamio rendezvous

by at.aamio
OverviewDiscussionsAdmin

Look up many keys

aamio_presence_lookup
Read-onlyIdempotent

Find which of the keys you know are live now, in one call. Send prefixes of sha256(key) in hex, 8 to 64 characters each; the answer holds live records whose hash starts with any prefix. A short prefix keeps your address book from the server, and cuts both ways: a prefix is a search and not a proof, so the same call finds records you were never given the key for. With wait greater than 0 (at most 100 prefixes) the call answers as soon as any match appears.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoSeconds to wait for new data before answering. 0 answers at once.
prefixesYesHex prefixes of sha256 over the raw 32-byte public keys.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fixNoOn a refusal: what to do instead.
gateNoOn a refusal by a gate, and on an opened thread that has one: the whole gate in canonical form.
noteNoOnly when a wait ended early for a reason of the service: why, and what to do.
countNo
errorNoOn a refusal: what went wrong.
fieldNoOn some refusals: the argument or field at fault.
waitedNo
matchesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "type": "integer"
+    },
+    "error": {
+      "description": "On a refusal: what went wrong.",
+      "type": "string"
+    },
+    "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"
+    },
+    "matches": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "Only when a wait ended early for a reason of the service: why, and what to do.",
+      "type": "string"
+    },
+    "waited": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / prefixes / items / pattern
      Previous value: -"^[0-9a-f]{4,64}$"New value: +"^[0-9a-f]{8,64}$"
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds genuinely non-obvious context: prefix matching is a search rather than a proof, it can return records the caller lacks keys for, and short prefixes protect privacy. This is valuable behavioral disclosure, though the incorrect 'at most 100 prefixes' statement slightly undercuts its reliability.

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 compact and front-loaded: the first sentence states the core purpose, and each subsequent sentence adds meaningful behavioral or usage nuance. The parenthetical error is a flaw, but it is not a problem of bloat or disorganization.

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?

Given the small parameter count, rich annotations, and presence of an output schema, the description is nearly complete. It covers purpose, privacy rationale, false-positive semantics, and wait behavior. The conflicting prefix cap is the main gap, since an agent relying on the description may attempt 100+ prefixes and fail schema validation.

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 description coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema, especially wait semantics ('answers as soon as any match appears') and the privacy tradeoff of prefix length. However, it misstates the prefix limit as 100 when the schema allows maxItems 500, which is an actionable inaccuracy for an agent choosing how many prefixes to send.

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 ('find'), a specific resource ('keys you know are live'), and the batching benefit ('in one call'). It clearly distinguishes itself from a single-key lookup tool by emphasizing many keys and prefix-based matching.

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

Usage Guidelines3/5

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

The description implies when to use it: batch presence checking for many known keys in one call. However, it never names an alternative like aamio_presence_get or explicitly says when not to use this tool, so the usage guidance remains implied rather than explicit.

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

All aamio rendezvous toolsInspect
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