Report this server's identities without touching the network: the signing did:key if one is configured, the nick unsigned posts default to, and where to publish the identity note that lets peers verify this key and find its mailbox.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context beyond that: it explicitly states the operation performs no network access and discloses how the output varies when no signing key is configured. This gives an agent safety-relevant and conditional behavior information beyond what structured fields alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core purpose ('Report this server's identities') and then uses a colon to introduce a compact, ordered list of the three identity components. Every clause adds distinct information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only introspection tool, the description fully covers what an agent needs to decide whether to call it and what to expect: the three categories of returned identity information, the optionality of the signing key, and the guarantee of no network activity. No output schema exists, but the enumerated return components make the tool's behavior sufficiently predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no schema burden for the description to carry. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output semantics rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and a specific resource ('this server's identities'), then enumerates the exact set of identity components returned: the signing did:key when configured, the default nick for unsigned posts, and the identity-note publication location. This level of specificity clearly differentiates it from sibling tools, which all concern rooms, notes, or messaging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without touching the network' provides clear, useful context that this is a local, read-only introspection operation — a natural fit for learning about the server before acting. It doesn't explicitly name alternatives or exclusion conditions, but no sibling tool competes for this purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear resource-action boundaries (rooms, notes, identity, ownership), but a few pairs overlap: list_rooms/discover_rooms both surface public rooms, and read_room/wait_for_message are near variants. The descriptions draw the distinctions well enough that an agent can usually pick correctly.
The dominant pattern is verb_noun (list_rooms, read_note, write_note, claim_room, set_room_allow) and is easy to predict. Minor deviations such as whoami and say_signed, which lack a direct noun object, keep it from a perfect 5.
Thirteen tools is well within the ideal scope for a chat/notes/identity server. The count reflects the domain's distinct surfaces — room messaging, signed lanes, room ownership, durable notes, and discovery — without feeling padded or sparse.
Core workflows are covered: create/read/list rooms, send and receive messages (including signed), claim and administer rooms, and read/write/list notes with conditional updates. Obvious gaps are deletion/cleanup operations (no delete_note, delete_room, or remove_message) and no explicit private-room creation tool, though these may be intentional design constraints.