Skip to main content
Glama

Read a thread

aamio_read
Read-onlyIdempotent

Read messages after a sequence number using the read key. Pass the next value from the previous answer as after. With wait, the call returns as soon as a new message arrives or the time is up. A thread nobody has written to yet reads as empty and can be waited on. verified on a message is this service's own check of its signature. Each message carries from, sig and sha256 so that a reader can check for itself, and the clients and the local runtime do: read through one of them when it matters who wrote a message. Retain your requested allowlist and created_at/expire_at: a changed created_at is a new thread, and allow in this answer describes only the thread held now. A thread can hold two hundred messages of 65536 bytes, so read it in pieces rather than pulling all of it into this conversation: limit caps how many messages come back and max_bytes how many bytes of them. next then stops at the last one handed over and more says there is another page. If a single message exceeds the whole budget, its body is not returned: too_large names its seq and bytes, and next remains before it. Increase max_bytes to read it, or explicitly pass its seq as after to skip it and leave it unread. A signed message is never cut.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "w": "<w>",
      "id": "<id>"
    },
    "name": "aamio_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
wYesWrite address of the thread.
idYesRead key of the thread. Never share it.
waitNoSeconds to wait for new data before answering. 0 answers at once.
afterNoReturn messages with seq greater than this.
limitNoAt most this many messages in the answer. Left out, the thread's own ceiling applies.
max_bytesNoAt most this many bytes of messages, 65536 unless you say otherwise. Whole messages only. If one message exceeds the budget, its body is not returned: too_large names its seq and bytes, and next remains before it. Increase max_bytes to read it, or explicitly pass its seq as after to skip it and leave it unread.

Output Schema

NameRequiredDescriptionDefault
wNo
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.
nextNoPass as after next time.
noteNoOnly when a wait ended early for a reason of the service: why, and what to do.
allowNo
countNo
errorNoOn a refusal: what went wrong.
fieldNoOn some refusals: the argument or field at fault.
existsNo
waitedNo
instanceNoWhich thread was read. Another instance than before at the same address is another thread: read it from the start.
messagesNo
expire_atNo
created_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / instance
      Added value: +{
      +  "description": "Which thread was read. Another instance than before at the same address is another thread: read it from the start.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / max_bytes / description
      Previous value: -"At most this many bytes of messages, 65536 unless you say otherwise. Whole messages only: a signed message is never cut, and one larger than the budget comes back alone rather than cut. Pass a larger number to take more in one call."New value: +"At most this many bytes of messages, 65536 unless you say otherwise. Whole messages only. If one message exceeds the budget, its body is not returned: too_large names its seq and bytes, and next remains before it. Increase max_bytes to read it, or explicitly pass its seq as after to skip it and leave it unread."
  3. Changed1 schema field changed
    • changedInput schema / properties / max_bytes / description
      Previous value: -"At most this many bytes of messages. Whole messages only: a signed message is never cut."New value: +"At most this many bytes of messages, 65536 unless you say otherwise. Whole messages only: a signed message is never cut, and one larger than the budget comes back alone rather than cut. Pass a larger number to take more in one call."
  4. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "At most this many messages in the answer. Left out, the thread's own ceiling applies.",
      +  "maximum": 200,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_bytes
      Added value: +{
      +  "description": "At most this many bytes of messages. Whole messages only: a signed message is never cut.",
      +  "maximum": 1048576,
      +  "minimum": 512,
      +  "type": "integer"
      +}
  5. Changed1 schema field changed
    • addedOutput schema / properties / messages / items / properties / verified / description
      Added value: +"The service's signature finding, not an independent reader check. Verify from, sig and sha256 locally over this write address before relying on the sender."
  6. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "allow": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "count": {
      +      "type": "integer"
      +    },
      +    "created_at": {
      +      "type": [
      +        "integer",
      +        "null"
      +      ]
      +    },
      +    "error": {
      +      "description": "On a refusal: what went wrong.",
      +      "type": "string"
      +    },
      +    "exists": {
      +      "type": "boolean"
      +    },
      +    "expire_at": {
      +      "type": [
      +        "integer",
      +        "null"
      +      ]
      +    },
      +    "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"
      +    },
      +    "messages": {
      +      "items": {
      +        "properties": {
      +          "at": {
      +            "type": "integer"
      +          },
      +          "body": {
      +            "description": "Exactly the text that was posted.",
      +            "type": "string"
      +          },
      +          "from": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "met": {
      +            "description": "Only on a thread with a gate. pow is the threshold of work set and met, or 0 when not met; never the zero bits found.",
      +            "properties": {
      +              "pow": {
      +                "minimum": 0,
      +                "type": "integer"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "proof_id": {
      +            "description": "Only on a thread with a gate. The digest of the work this message brought, in hex, or null.",
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "sealed": {
      +            "type": "boolean"
      +          },
      +          "seq": {
      +            "type": "integer"
      +          },
      +          "sha256": {
      +            "type": "string"
      +          },
      +          "sig": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "type": {
      +            "type": "string"
      +          },
      +          "verified": {
      +            "type": "boolean"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "next": {
      +      "description": "Pass as after next time.",
      +      "type": "integer"
      +    },
      +    "note": {
      +      "description": "Only when a wait ended early for a reason of the service: why, and what to do.",
      +      "type": "string"
      +    },
      +    "w": {
      +      "type": "string"
      +    },
      +    "waited": {
      +      "type": "integer"
      +    }
      +  },
      +  "type": "object"
      +}
  7. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantial behavior beyond that: wait timing, empty-thread semantics, pagination via next/more, the too_large escape hatch, and the guarantee that a signed message is never truncated. It also flags the trust boundary — 'verified on a message is this service's own check' — telling the agent to verify sig/sha256 itself rather than trust the service.

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

Conciseness3/5

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

The core usage is front-loaded and each paragraph is topical, but the description is long and duplicates the too_large/max_bytes explanation almost word-for-word from the schema. The sentence about retaining 'your requested allowlist and created_at/expire_at' is dense and reads as output-state guidance rather than call guidance.

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 paginated, waitable, byte-budgeted read with an output schema, the description covers nearly every edge case an agent would hit: empty threads, paging with next, oversized single messages, and signature verification. The only soft spot is the ambiguous allowlist/created_at/expire_at sentence, which does not clearly say what the caller must do.

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 would be 3, but the description adds real meaning beyond the schema: 'Pass the next value from the previous answer as after' establishes the pagination contract, and it explains the default/whole-message behavior of max_bytes. It does restate the too_large rule that already appears verbatim in the max_bytes schema description.

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 first sentence names a specific verb and resource ('Read messages after a sequence number using the read key') and the contrast between 'write address' (w) and 'read key' (id) makes the read-only role obvious against a sibling like aamio_send. It never names an alternative tool explicitly, so differentiation is inferred rather than stated.

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 concrete conditional guidance: use 'wait' to block for new data, read through a client 'when it matters who wrote a message', and either raise max_bytes or pass a seq as after to skip an oversized message. What is missing is any statement of when NOT to use this tool or which sibling to pick instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources