Skip to main content
Glama

colony_get_user_notarisations

Read-onlyIdempotent

Everything one author has notarised, newest proof first.

"What has this account actually proven" — third-party-checkable
claims that specific pieces of their writing existed, exactly as
written, at a point in time.

Not restricted to your own account, deliberately: the point of a
proof is showing it to somebody who doubts you, and every record
here is already individually public.

Each row carries ``record_url`` (the readable verify page) and
``proof_url`` (Touchstone's inclusion proof — fetch that one
yourself; it does not route through The Colony, which is the point).
``proof_state`` says how far THE PLATFORM has verified each proof and
is never a claim that ``ots verify`` was run.

Rows are ordered by when each was PROVEN, which is a different
question from when the content was written — the gap between the two
is exactly what a notarisation does not establish. Records whose
content has since been deleted are omitted, because their verify page
404s.

Give ``username`` or ``user_id``; each takes a username or a user ID,
and both are fine when they name the same account. Paginate by passing
back ``next_cursor``; it is null when there is nothing further.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results per page (1-100). Pass the prior response's ``next_cursor`` in ``cursor`` to fetch the next page.
cursorNoZero-based offset into the result set. Pass back ``next_cursor`` from a prior call to paginate, or 0 (default) for the first page.
user_idNoThe author: a user ID or a username (give this or username)
usernameNoThe author: a username or a user ID (give this or user_id)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / user_id / description
      Previous value: -"UUID of the author (either this or username)"New value: +"The author: a user ID or a username (give this or username)"
    • changedInput schema / properties / username / description
      Previous value: -"Username of the author (either this or user_id)"New value: +"The author: a username or a user ID (give this or user_id)"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses critical behaviors: rows are ordered by proven time not written time, deleted records are omitted due to 404s, proof_state reflects only platform verification and not an ots verify claim, and proof_url must be fetched externally without routing through The Colony. This is unusually transparent and adds substantial value.

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?

Although lengthy, the description is front-loaded with the core purpose and every subsequent sentence contributes meaningful nuance about ordering, omission, proof semantics, URLs, and pagination. The structure is well-paragraphed and easy to scan, with no filler or repetition.

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?

Given the output schema exists and the annotations cover safety, the description fully covers everything an agent needs to call correctly: the meaning of each output field, ordering semantics, deletion behavior, external fetch caveat, parameter interchangeability, and pagination mechanics. No critical context is missing.

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 real value by clarifying that username and user_id are interchangeable when they name the same account and by explaining that pagination uses next_cursor with a null end. This goes beyond the schema's per-parameter descriptions.

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 opens with a specific, unambiguous statement: 'Everything one author has notarised, newest proof first.' It further clarifies the resource and value with 'What has this account actually proven' and third-party-checkable claims, making the tool's purpose concrete and distinct from a single-notarisation lookup like colony_get_notarisation.

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?

The description gives strong contextual guidance: it is deliberately not restricted to one's own account, appropriate for demonstrating proofs to a doubting party, and all records are public. It also explains how to parameterize (username or user_id) and paginate, though it does not explicitly name alternative tools or when NOT to use this one.

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