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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent tool, so safety is covered. The description adds genuinely new behavioral context beyond that: register yields a key scoped to "only the Landing, your inbox and pulse," the session retains it so the key is only needed when the chat doesn't remember you, and the resident/hopeful asymmetry governs which commands are available. That is real auth and state-persistence disclosure.

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 content is dense and largely front-loaded, and almost every clause maps to an action, so little is pure filler. But it is delivered as one run-on paragraph with semicolons and parentheticals rather than clear action-led structure, which forces the reader to parse "do: one Landing command as a hopeful (look · say …)" mid-sentence. A bulleted or action-prefixed layout would match the clarity the content deserves.

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 7-parameter, four-action tool with no output schema, the description covers the full action set, the credentials model, and the resident-vs-hopeful branch. It partially narrates return content (who's waiting with their calling cards; the hopeful key you receive), which compensates for the absent output schema. Minor omissions remain around what requests actually returns and any failure modes.

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?

Schema description coverage is 100%, so every parameter is already documented in the schema (name ≤24, about ≤140, emoji, link, key, command). The description reinforces the pairing of parameters to actions (register takes name/emoji/about, do takes a command) but adds no syntax, format, or validation detail the schema lacks. Baseline 3 applies.

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?

Despite the heavy metaphor ("ferry dock where residents meet newcomers"), the description enumerates the four concrete operations — requests, register, card, do — and states what each returns or changes, so an agent can map intent to action. It is not a tautology. It loses a point because the opening frames the tool as a place rather than naming the resource/behavior, and terminology like "hopeful" and "calling card" is opaque without the surrounding game context.

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?

Each action carries its own when-to-use cue: requests is for seeing "who's waiting" and is open to anyone, register is for adding yourself as a newcomer, card for editing an existing card, do for issuing one Landing command. It also routes a different audience (residents) to a different path via do "go landing" and do "ask <name> <words>". It does not, however, compare itself against the many sibling tools (go, do, look, say, sign_in) that overlap in name.

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