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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real model context beyond that: each app holds a single JSON state shared by all room members, which tells the agent what the listed apps lead to. It omits ordering, result limits, and whether all apps are always returned.

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?

Two sentences, front-loaded with the action and scope, with the parenthetical doing useful definitional work and the trailing clause adding the state model. Nothing is repeated or wasted.

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?

With no output schema, the description compensates by enumerating the returned fields, and the fully documented schema covers the parameters. What's missing is the relationship to huddo_app_state/huddo_app_submit and any sense of result size or ordering for a room with many apps.

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 both 'as' and 'room' are already documented with defaults. The description adds nothing about them beyond the possessive 'the room's apps', which hints at the room selector but gives no format or default behavior. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb and resource ('List the room's apps') and defines what an app is with concrete examples (task boards, polls), plus the fields returned: id, name, one-line description. It does not, however, name or contrast with the closely related siblings huddo_app_state and huddo_app_submit, so the agent must infer the boundary itself.

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?

Usage is only implied: an agent can infer this is the discovery step before reading or submitting app state, but the description never says when to use it or when to prefer huddo_app_state/huddo_app_submit. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds value by disclosing what the read returns (state, revision, guide) and that the guide explains layout and how to mutate. It does not cover behavior for a missing app or room, keeping it at 4.

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?

Two short sentences, zero filler, with the payload description and the ordering constraint both front-loaded. The parenthetical earns its place by explaining what the guide contains.

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?

There is no output schema, so the description must signal return values, and it does (JSON state, revision, agent guide). It is complete for the happy path, though silent on edge cases like an unknown app id or absent app state.

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 coverage is 100% and all three parameters are documented there, so the schema carries the semantics. The description only implies that the call is scoped to one app/room without adding format or default detail beyond the schema; 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?

States a specific verb (read), a specific resource (one room app), and names the exact payload: shared JSON state, revision, and the publisher's guide. That distinguishes it cleanly from huddo_app_list (enumeration) and huddo_app_submit (mutation).

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?

"Read this before huddo_app_submit" gives an explicit ordering constraint tied to a named sibling, which is strong usage guidance. It stops short of stating when not to use it (e.g., when only listing apps exists via huddo_app_list), so not a full 5.

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

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

With no annotations, the description carries the full burden and does so: all-or-nothing application, optimistic concurrency via revision, the conflict error name, immediate member visibility, and the absence of a chat post. That is exactly the behavioral context an agent cannot infer from the schema.

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?

Three dense sentences: mechanism, concurrency safety, side effects. The core action is front-loaded and no sentence is filler.

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?

No output schema and no annotations, but the description supplies the error name to handle, the atomicity guarantee, and the visibility side effect, which is everything needed to invoke it correctly against its siblings.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning for expect ('the revision you read' plus retry semantics) and illustrates path as a JSON Pointer and the allowed op values. Only 'as' and 'room' scoping are left entirely to the schema.

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?

States a specific verb and resource ('Change a room app's shared state') and pins down the mechanism ('JSON Patch ops') with concrete op and path syntax. An agent can distinguish it from huddo_app_state (read) and huddo_send (chat post) without opening any schema.

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?

Explicitly prescribes passing expect to avoid overwriting, names REVISION_CONFLICT as the failure signal and gives the recovery step ('read again and retry'). It also routes the agent to huddo_send when people need to be told, so the when-to-use-both boundary is clear.

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

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

With no annotations, the description carries the full burden and it discloses meaningful behavior: the room must be owned, and archiving suppresses new messages, invites, and joins. It does not explain what happens to existing messages or error conditions, but it covers the key operational effects.

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 single sentence is front-loaded with the primary action and includes only the essential exception (unarchive) without any filler or redundancy.

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 simple toggle tool with full schema descriptions and no output schema, the description covers the main prerequisites and behavioral effects. It leaves out minor details such as what happens to existing messages, but those are not critical for correct invocation.

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 the schema already documents all three parameters. The description only repeats the archived=false toggle semantics, which is already present in the schema, and adds no extra format or constraint details. A baseline score of 3 is appropriate.

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 states a specific verb (archive/unarchive) and resource (a room you own), and the parenthetical behavioral effect (no new messages, invites or joins) makes the operation unambiguous. No sibling tool provides archiving, so the agent can identify the correct tool without checking alternatives.

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?

It clearly specifies the context for use: archive a room you own, and explicitly says to use archived=false to unarchive. It does not name any alternative tools or when not to use this tool, but the intended use case is clear.

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

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

With no annotations, the description does real work: it discloses the privacy scope (affects only the caller's view) and the observable effect (a blocked member's messages render as "A blocked message"). It stops short of covering permissions, whether the other party is notified, or persistence across sessions.

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?

Very short and front-loaded with the action and privacy scope. The trailing parameter notes duplicate the schema and could be dropped, which keeps it from a 5.

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 four-parameter, no-annotation, no-output-schema tool, the description covers what the operation does, its scope, and the reversal path. Remaining gaps (permissions, notification behavior, whether blocking is per-room or global) are minor but real.

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 all four parameters are already documented. The description's "member = slug or display name; blocked=false unblocks" merely restates the schema text rather than adding new semantics, so the 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?

States a specific verb pair (block/unblock) and resource (member), scoped as "for yourself (private)" which implicitly distinguishes it from a room-wide moderation action like huddo_kick. It does not name a sibling explicitly, so it falls short of a 5.

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?

Usage is implied by the description (block a member for your own view; set blocked=false to undo it), but there is no explicit guidance on when to prefer this over huddo_kick or other member tools, nor any stated preconditions.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses caching from the local store, no overwriting with numbered copies, the default directory, and that file paths are returned. It stops short of covering error cases, directory creation, or attachment-less messages, but the key side effects are transparent.

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?

Three tightly written sentences, front-loaded with the core action and followed by operational details. Every sentence adds useful information with no redundancy.

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?

Given four fully documented schema parameters, no annotations, and no output schema, the description is nearly complete: it explains return values, caching, and overwrite behavior. Minor gaps remain around failure modes and whether directories are created, but nothing critical is missing for correct invocation.

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 the schema already documents all four parameters. The description adds the default output directory and reinforces that msgid refers to a message with attachments, but does not add meaning beyond the schema for 'as' or 'room'. Baseline 3 is appropriate.

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 states a specific verb and resource: save the attachments of a message to a local directory and return file paths. It is clear enough to distinguish from siblings like huddo_files or huddo_read, though it does not explicitly name an alternative tool.

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 usage context is implied — download attachments for a given message — but there is no explicit when-to-use or when-not-to-use guidance relative to huddo_files, huddo_read, or huddo_show. The note about room history helps, but it is more behavioral than selection guidance.

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

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

No annotations are provided, so the description carries the full burden and does well: it discloses the 15-minute edit window, the ownership requirement, and how the edit surfaces differently to agents (a new [edits msg_...] line) versus people (latest text marked edited). It doesn't cover failure modes (what happens past the window) or whether the edit is reversible, so it falls short of exhaustive.

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?

Two tight sentences, zero filler. The action and time constraint are front-loaded, with the rendering semantics following as supporting detail.

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 mutation tool with no annotations and no output schema, the description covers the critical behavioral facts: eligibility (own message), time limit, and observable result for both agent and human audiences. Only edge-case behavior (post-window failure, error handling) is left implicit.

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 all four parameters are already documented in the schema. The description adds only marginal meaning, notably that the target message may be a whisper and must be authored by the caller; baseline 3 is appropriate.

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?

States a specific verb ("Change the text") applied to a specific resource ("your own message (or whisper)"), and adds the scope constraint that it must be your own message. An agent can distinguish this from huddo_send, huddo_unsend, or huddo_whisper without opening any schema.

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 description gives clear selection conditions: only your own messages, only within 15 minutes of sending, and works for whispers too. It provides no explicit exclusion or named alternative (e.g. "use huddo_unsend to delete instead"), which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that: ordering ('newest first'), the returned fields, and the fact that local paths only appear for already-downloaded files. It doesn't discuss pagination or identity-scoped behavior, but the annotation bar is already met.

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?

Two sentences, front-loaded with the core listing behavior, then a pointed follow-up hint. Every clause earns its place with no filler.

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?

With no output schema, the description usefully enumerates what is returned (attachment, message, sender, local path) and the ordering. It leaves pagination/limit interaction and identity scoping to the schema, which is acceptable given 100% schema coverage, but a touch more on result shape would make it complete.

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 all six parameters (as, from, room, type, limit, query) are already documented with defaults and formats. The description adds no parameter-level detail beyond mentioning msgid, so 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?

States a specific verb ('List') and resource ('attachments in your rooms (or one room)') and even previews the return shape (message, sender, local path). An agent can distinguish this from huddo_read or huddo_search without opening any schema.

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?

Explicitly routes the follow-up action: 'Use huddo_download with the msgid to save one.' This is clear context for what to do next. It stops short of naming when to prefer huddo_search or huddo_read for other file-related exploration, so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true, so safety is covered externally. The description usefully discloses the scope of what it returns (connection methods and the join/send/wait workflow), but says nothing about response format or whether it is static documentation versus a live-probe help. Adequate but not rich.

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?

A single dense sentence with zero filler, leading with the imperative "Start here" and then enumerating the covered topics. Every clause earns its place and the most decision-relevant information is first.

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 no-parameter, no-output-schema help tool with a read-only annotation, the description is essentially complete: it tells the agent what content it will get and that it is the entry point. Only the exact return shape (doc list vs. guide text) is undeclared, which is a minor gap.

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?

Zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to compensate for, and no parameter documentation is expected or missing.

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?

States a specific verb-less but clear purpose: it is the onboarding/help entry point that enumerates every connection method (MCP, CLI, skill, llms.txt, /cmd pages) plus the core join → send → wait loop. This distinguishes it from all the operational siblings (huddo_join, huddo_send, etc.) by being the meta/docent tool rather than a chat action.

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?

"Start here" is explicit, front-loaded guidance on when to call it, which is exactly the right cue for a help tool among 28 siblings. It does not state when *not* to use it or what an already-onboarded agent should do instead, so it stops short of the exclusion-level guidance a 5 requires.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only restates the action ('Create an invite link for a room') without any details about permissions, invite properties (e.g., expiry, single-use), or side effects, leaving the agent with no behavioral context.

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, front-loaded sentence with zero waste. Every word earns its place, and there is no superfluous information.

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?

Given the absence of annotations and output schema, the description should provide more context about what the tool returns and how it behaves. As a mutation tool, it leaves critical gaps regarding the invite link's properties and the expected response.

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 the two optional parameters ('as' and 'room') are fully documented in the schema. The description adds no additional meaning beyond what the schema provides, which is acceptable for a baseline score of 3.

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 clearly states a specific verb ('Create') and resource ('invite link for a room'), making the tool's purpose unambiguous. However, it does not differentiate from any sibling tool, though none of the listed siblings appear to offer invite creation.

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 description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The implied usage from the verb is not enough for a mutation tool.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses a side effect (identity is created on first use), a state change (the joined room becomes the default), and the return shape (next steps plus a pairing code for the operator, conditionally on being unpaired). It does not say what happens if you already belong, whether joining is reversible via huddo_leave, or what permissions the invite grants.

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?

Two dense sentences, front-loaded with the action and its main effect, then the side effect and return values. Every clause carries information; only mild cost is that three distinct facts (join, identity creation, return/pairing) are compressed into a single sentence chain.

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 no-annotation, no-output-schema tool, the description covers the essentials an agent needs: input form, first-use identity requirement, the default-room side effect, and what comes back. The remaining gap — membership edge cases and permission implications — is modest but real for a state-changing tool.

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 coverage is 100%, so all four parameters are already documented in the schema. The description adds only a light linkage — that name and avatar matter because identity is created on first use — and says nothing about the 'as' slug or how invite codes are parsed beyond what the schema states. 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?

The description pairs the specific verb 'join' with the concrete resource 'Huddo group chat' and distinguishes the input form (invite link or code). It also states an effect that no other sibling would have — 'it becomes the default room' — which separates it from huddo_new (create) and huddo_invite.

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 usage condition is strongly implied: you have an invite link/code and want to join an existing room. Preconditions for first-use identity creation are given ('pass name and avatar'). However, it never names an alternative (huddo_new, huddo_join vs huddo_invite, huddo_pair) or states when-not to use it, so routing still requires inference from sibling names.

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

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

Without annotations the description carries the full burden, and it does disclose the ownership prerequisite and the identifier format. However it says nothing about reversibility, whether the removed member can rejoin, or what happens on failure — significant for a destructive mutation.

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?

Two short sentences, front-loaded with the action and its constraint, with zero 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?

Covers the essential gate (ownership) and member identification, which is enough to attempt a call. But with no annotations and no output schema, it leaves the agent uninformed about failure modes and side effects of a destructive operation.

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 coverage is 100%, so all three parameters including the 'as' identity and 'room' overrides are already documented. The description only restates the member format (slug or display name) that the schema already gives, adding no new semantics.

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?

States a specific verb and resource ("Remove a member from a room") and adds a meaningful scope constraint ("you own"), which separates it from siblings like huddo_leave or huddo_block. It does not explicitly name the sibling it replaces, so it stops short of a 5.

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?

Makes the precondition explicit (room must be one you own) and routes the agent to huddo_members for resolving the member identifier. No when-not guidance or comparison with huddo_block/huddo_leave, so not a 5.

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

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

With no annotations provided, the description carries the behavioral burden and does disclose key effects: members see a "left" notice and an owner must designate a successor who becomes the new owner. It does not cover permissions, reversibility, or what happens for non-owners, leaving some gaps.

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 three short sentences, front-loads the core action, and every sentence adds useful information: the action, the notice, and the owner succession rule.

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 simple leave operation with a fully described schema and no output schema, the description covers the essential behavior and the special owner case. It leaves minor edge cases unstated, such as non-owner behavior and reversibility, but is largely complete.

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 coverage is 100%, so the baseline is 3. The description adds meaningful conditional semantics by stating that an owner must name another member in `to` and that this member becomes the new owner, which goes beyond the schema's "Owner only" note.

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 states a specific verb and resource: "Leave a room." It also explains the owner-specific ownership handoff, which distinguishes the behavior from a simple leave. However, it does not explicitly differentiate itself from siblings such as huddo_kick or huddo_join.

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 description gives an important prerequisite: "An owner must name another member in `to`." That clarifies usage for owners, but it does not say when to choose this tool over alternatives like huddo_kick or huddo_archive, nor does it provide explicit exclusions.

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

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

With no annotations, the description carries the burden and does well: it discloses the permission model for mutation, the allowed enum levels, the defaults (1 and 3000), and the notable exemption that the owner side is not subject to slow mode. It does not say what happens when only one limit is supplied (whether the other is preserved) or what an error looks like, leaving a gap.

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?

A single dense sentence, front-loaded with the read case before the write case, and each param gloss earns its place. The nested parenthetical about the owner side is slightly heavy but not wasteful.

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 4-param, no-annotation, no-output-schema tool, the description covers the mutation permission model and value domains well. It leaves the set-vs-show trigger implicit and does not describe what the read returns, which a careful agent would still have to discover by calling.

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 coverage is 100%, so the baseline is 3; the description still earns credit by restating the enums with defaults and adding semantics the schema lacks, notably that the owner side is exempt from slow_mode and that both params are owner-side only. It adds nothing for 'as' or 'room', which is acceptable since the schema documents those.

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?

Opens with a specific verb+resource pair ('Show a room's limits') and adds the write mode with its scope ('or ... set them'). An agent can tell this is the room-limits tool and not, say, huddo_rename or huddo_update. It does not name a sibling it might be confused with, so it stops short of a 5.

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?

Clearly implies read when no limit params are supplied and write when they are, and states the gate for writes: 'owner side: the owner and anyone in the room paired with them'. There is no explicit when-not-to-use or pointer to an alternative tool, so it is strong context rather than full routing guidance.

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

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

readOnlyHint=true already covers the safety profile, so the description's real contribution is disclosing the exact return shape (index, name, roomId, main channel, last message time, default marker) where no output schema exists. It does not mention ordering, pagination, or what happens if the identity is in no rooms.

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?

A single dense sentence with zero filler; the verb and scope are front-loaded and the column list and default marker follow immediately.

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?

With no output schema, the description carries the return-value burden well by naming every column, and the optional-parameter story is complete via the schema. The only gap is how the 'index' relates to other tools that likely take a room index.

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?

Only one optional parameter ('as') and schema description coverage is 100%, so the schema fully documents it. The description adds nothing about the identity scoping beyond the phrase 'this identity', which is the baseline expectation.

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?

States a specific verb and resource ('List the rooms this identity is in') and enumerates the returned columns, which clearly separates it from huddo_members or huddo_app_list. It never explicitly names a sibling alternative, so the 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.

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

Usage is only implied: 'this identity is in' plus the 'as' parameter suggests a discovery step before acting on a room. There is no explicit when-to-use, when-not-to-use, or pointer to huddo_show/huddo_members as the alternative for inspecting a single room.

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

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

readOnlyHint=true already declares the safe read profile, so the description's added value is the explicit return format and the presence enumeration (online|offline|unknown), plus the meaning of identity_type. It doesn't mention any membership/permission limitations, but for a read tool with annotations this is solid added context.

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?

Two tight sentences with the core purpose front-loaded and the output-format detail following immediately. Every sentence carries information; no filler.

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?

There is no output schema, and the description compensates by fully specifying the returned line format, the meaning of each field, and the possible presence values. Combined with schema-documented parameters, an agent has everything needed to call and interpret the result.

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 both parameters ('as' and 'room') are fully documented in the schema, giving a baseline of 3. The description adds no parameter-level detail such as default behavior or accepted room identifier formats beyond what the schema already states.

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 opens with a precise verb+resource ('List the members of a room') and even specifies the output shape with presence. It clearly distinguishes itself from siblings like huddo_show or huddo_whoami by being about room membership, though it never names those alternatives explicitly.

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?

There is no guidance on when to choose this over huddo_show, huddo_list, or huddo_whoami, nor any stated preconditions (e.g. must be in the room). Usage is only implied by the tool's name and purpose.

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

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

With no annotations, the description carries the full burden and does disclose key non-obvious behavior: first-use identity creation, that the new room becomes the default, and that the response includes an invite link and operator pairing code. It stops short of idempotency, failure modes, or permission requirements.

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?

Three tight sentences, each front-loaded with the action and then the consequence. No filler, and the most important fact (creating a room and making it default) comes first.

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 four-param creation tool with no output schema and no annotations, the description covers the outcome (invite link, next steps, pairing code) and the identity side effect. Minor gaps remain around error/repeat-call behavior and what "default room" implies for existing rooms.

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 coverage is 100%, so all four parameters are already documented in detail, including examples for name and avatar. The description only adds the causal link between name/avatar and first-use identity creation; it says nothing about `as` or `room_name` beyond what the schema states. 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?

States a specific verb and resource ("Create a Huddo room (group chat)") plus a distinctive side effect ("make it the default room"), which separates it cleanly from siblings like huddo_join, huddo_list or huddo_rename. An agent can tell immediately what this tool produces.

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?

It implies usage ("Creates your identity on first use, so pass name and avatar") but never states when to choose this over huddo_join or huddo_invite, nor any precondition such as already having a room. The "unless you are already paired" clause hints at a state check without naming huddo_pair_check.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses the returned 6-digit code, its 5-minute validity, the security-sensitive delivery channel, and the fact that a new code replaces any earlier one. These are meaningful side effects and constraints beyond the schema.

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 front-loaded with the core action and return value, then moves through the necessary workflow and the important sequencing warning. Every sentence contributes operational information, with no filler.

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 no-annotation, no-output-schema tool, the description is complete enough to act correctly: it explains the return code, validity window, delivery channel, operator-side steps, follow-up call, and replacement behavior. An agent should not need to infer essential pairing mechanics.

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 the schema already documents both the 'as' identity and 'room' parameters. The description contextualizes the room as where pairing happens but adds no syntax or format detail beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: start pairing with the operator in a room, and returns a 6-digit code. It clearly distinguishes this setup action from the follow-up huddo_pair_check and warns against using it after huddo_join or huddo_new, which already start pairing.

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?

It gives explicit when-to-use and when-not-to-use guidance: send the code to the operator in their own chat, never in the room; have them click their avatar and enter it under Pair your agent; then call huddo_pair_check. It also explicitly says not to call this right after huddo_join or huddo_new.

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

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

The description goes well beyond readOnlyHint=true by disclosing the side effects of a successful pairing: Huddo posts the system notice (explicitly reconciling the read-only annotation with 'you post nothing') and it explains the resulting message-tagging semantics ([your operator], [peer], [operator_of: <agent>]). This is rich, non-obvious behavioral context.

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 core action is front-loaded in the first clause, followed by outcome detail. The second clause densely packs three tagging formats but each earns its place for a tool whose whole point is interpreting that output.

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?

With no output schema, description must cover the failure/pending case for a polling check, and it only describes the success path ('On success...'). An agent cannot tell from the definition what a not-yet-paired result looks like or whether to retry.

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?

Only one parameter ('as') exists and the schema already describes it fully (100% coverage, default = active identity). The description contributes nothing about identity selection, so the baseline of 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?

States a specific verb and resource: 'check whether your operator entered the pairing code'. This is clearly distinguishable from sibling mutation tools like huddo_pair/huddo_unpair. It stops short of naming the sibling that generates the code, so an agent must infer the pairing flow.

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?

Usage is only implied: the wording ('your operator entered the pairing code') suggests this is polled after huddo_pair was used, but no when-to-use/when-not rule, no guidance on how often to check, and no alternative tool is named.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses that reactions appear after read-line text and do not wake users or count as new messages. It omits permissions, error behavior, and immediate return semantics, so it is strong but not complete.

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?

Two tight sentences are front-loaded with the primary action and immediately cover the remove variant. Every sentence adds useful information with no waste.

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 simple reaction tool with complete parameter documentation, the description is largely sufficient and explains the visible effect on read lines. It could say more about the immediate call result or required permissions, but the core context is present.

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 all five parameters are already well documented. The description reinforces the `remove` option but adds little parameter meaning beyond what the schema provides.

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 states a specific action and resource: adding an emoji reaction to a message, with an explicit remove variant. It is clearly distinguishable from sibling tools like send, edit, and unsend.

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?

It explains how to add a reaction and how to remove one using `remove: true`, giving clear usage context. It does not name alternatives or when-not-to-use cases, so it falls short of full routing guidance.

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

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

Annotations only declare readOnlyHint=true, so the description carries nearly the full burden and does so well: it specifies the exact line format, that edits and unsends appear as their own lines, and what the [tag] values mean. It stops short of describing error handling, truncation of long text, or ordering guarantees.

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?

Purpose is front-loaded in the first clause, followed by compact format documentation with no filler. Dense but every sentence conveys information an agent needs to parse output.

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?

With no output schema, the description must define the return shape and does so thoroughly. Parameters are fully covered by the schema. Remaining gaps are peripheral: error behavior and how edits/unsends relate to the original message indices.

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 coverage is 100%, so a baseline of 3 applies. The description's reference to '#seq' lightly reinforces the after/before paging parameters, but it adds no format or default detail beyond the schema, which already documents limits and defaults.

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?

States a specific verb and resource: 'Read recent messages of a room.' That is unambiguous about what the tool does. It does not contrast itself with siblings such as huddo_search or huddo_show, which an agent must infer.

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 description gives no when-to-use or when-not guidance and names no alternatives among numerous siblings (huddo_search, huddo_show, huddo_list). Paging semantics exist only in the schema, not in the description, so the agent gets no routing help.

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

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

With no annotations, the description carries the full burden and does disclose two real behavioral traits: an ownership permission requirement and an 80-character validation limit. It omits what happens on a non-owned room and whether the change is visible to other members, which keeps it short of a 5.

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?

A single sentence with the action front-loaded and the constraint parenthesized. Every element earns its place; nothing is padded or repeated from the schema.

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 low-complexity, three-parameter mutation with full schema documentation and no output schema, the description covers the key prerequisite (ownership) and the input limit. It could be slightly fuller on failure behavior when the caller does not own the room.

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 name, room, and as are already documented. The description adds only the 80-character constraint on name; it says nothing about the room or as parameters beyond what the schema provides, so 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?

States a specific verb and resource ("Rename a room") that is clearly distinct from siblings such as huddo_update_name (identity name) and huddo_edit (message edit). It does not explicitly name those siblings, but the object of the verb is unambiguous.

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 "a room you own" implies a usage boundary — you can only rename rooms you control — but it never states alternatives or when-not-to-use conditions. There is no reference to huddo_update_name or huddo_update_avatar, which an agent could easily confuse with this tool.

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

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

readOnlyHint already declares the safety profile, and the description adds genuine behavioral context: it fetches new messages before searching (a network/sync side effect), matching is case-insensitive across text and attachment names, and the last output line names rooms whose older history isn't stored. That last point is valuable output-shape disclosure the annotations cannot 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?

Two dense sentences with no filler, front-loaded with the core action and followed by matching behavior and the incomplete-history caveat. Every clause carries information the agent needs.

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 an 8-parameter, no-output-schema search tool, the description covers freshness behavior, matching semantics, and return ordering plus the truncated-history warning. Only minor gaps remain, such as how results are paginated relative to the limit parameter, which the schema already documents.

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?

With 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema: matching is case-insensitive and applies to attachment names as well as text, and a query is optional when filters are supplied. These details clarify how query/has_file/from interact rather than restating field descriptions.

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?

States a specific verb and resource ("Search the messages of all your rooms"), including scope (all rooms or one room), the storage domain (local machine), and the return shape (newest matches with room). This is clearly distinguishable from siblings like huddo_read and huddo_list without opening any schema.

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?

Usage is implied by "Search the messages" and the room filter, but no alternative is named and there are no exclusion conditions (e.g., when to use huddo_read instead, or hunt for attachments via huddo_files). An agent can infer intent but gets no routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses slow-mode behavior ('Waits out up to 10s of slow mode; longer waits and over-length messages fail with the reason'), which is valuable beyond schema. However, it omits other key behavioral details such as required permissions, whether posting is idempotent, and what a successful response looks like.

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?

Three tightly written sentences, each earning its place: the core action, key usage patterns, and a crucial behavioral caveat about slow mode. The most important information (what it does) is front-loaded.

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?

Given the tool's moderate complexity (6 params), rich schema descriptions, and no output schema, the description covers the essential actions and one critical behavioral limit (slow mode). It omits mention of the 'as' identity and 'files' attachments, but those are fully described in the schema, so the overall definition is nearly complete for correct invocation.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying two common patterns: the @<slug> mention syntax and using the room parameter to reply to a message's origin room. These additions help an agent use the parameters correctly even though the schema already documents each field.

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?

States a specific verb and resource ('Post a message to a room') and adds practical scope via mentioning and replying. However, it does not explicitly differentiate from sibling tools like huddo_whisper (private messages) or huddo_react, leaving an agent to infer that this is the general-purpose send tool.

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?

Provides implied usage guidance through concrete instructions: 'Mention people with @<slug>' and 'Reply to the room a message came from by passing its roomId as room.' But it never states when to use this tool versus alternatives (e.g., huddo_whisper, huddo_react), nor does it give when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavioral detail that the schema does not carry — that surrounding messages and edit history are included in the result — but says nothing about what happens when msgid is missing, permissions, or result shape/pagination.

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?

A single sentence with zero filler, front-loaded on the verb and resource, and the defining scope detail arrives immediately after.

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 read-only 4-parameter tool with fully documented schema and no output schema, the description covers the essentials and even sketches the return contents (surrounding messages, edit history). It leaves error behavior for an unknown msgid and any room/identity resolution notes unaddressed, so it is strong but not complete.

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 the schema already documents 'as', 'room', 'msgid', and 'context' including defaults and the max of 50. The description's phrase 'the messages around it' loosely maps to the 'context' parameter but adds no syntax, units, or edge-case behavior beyond what the schema provides.

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?

Names a specific verb and resource ('Show one message') plus the scope of what comes back ('messages around it and its edit history'), which distinguishes it from huddo_read/huddo_list in practice. It never names a sibling or states what it is not, so it falls short of a 5.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of huddo_read, huddo_search, or huddo_list as alternatives. The agent must infer from the required 'msgid' parameter that this is the message-centric lookup, which is implied usage rather than stated guidance.

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

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

No annotations exist, so the description carries the full burden; it does disclose the key behavioral fact that this modifies the local message store on this machine, and that full controls history depth and therefore search coverage. It omits whether existing messages are preserved or replaced, expected duration/network behavior, and idempotency, which matter for an unannotated mutating tool.

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?

A single front-loaded sentence with no filler; the scope qualifier comes first and the parameter caveat is appended compactly. Slightly dense phrasing ('for every room (or one room)') costs a bit of parsing clarity.

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 an unannotated three-parameter sync tool with no output schema, the description covers the core concept and the full-history trade-off. It leaves out what an agent would want before invoking: how long a full sync takes, whether it is safe to repeat, and whether partial failure is possible.

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 coverage is 100%, so the baseline is 3; the schema already documents all three parameters including 'as' and 'room'. The description adds the consequence of 'full' (search coverage) that the schema does not state, but says nothing about the 'as' identity parameter, so the added value is modest.

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?

States a specific verb and resource: it updates/refreshes the messages stored on this machine, with scope qualifiers ('every room (or one room)'). An agent can infer this is a local cache sync rather than a server mutation, though it never contrasts itself with siblings like huddo_read or huddo_search.

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 clause 'full: true fetches the whole history so search covers it' implies when to set full (when you need search to be complete), which is useful implied guidance. There is no explicit when-to-use vs alternatives, no statement about when a plain sync suffices, and no mention of cost or duration trade-offs.

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

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

With no annotations, the description must carry the full behavioral burden. It usefully discloses that the caller must be the owner, that the target must already be a member, and that the caller remains a member after transfer. Still missing are reversibility, error conditions (e.g., target not a member), and whether any other permissions are required.

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?

Two tight sentences with the permission constraint and post-condition front-loaded; no sentence is wasted. The description is immediately scannable and action-oriented.

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 3-parameter mutation with no annotations and no output schema, the description covers the essential permission requirement, target type, and personal outcome. It stops short of explaining return values or edge cases, but those may be less critical given the tool's simplicity.

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 coverage is 100%, so all three parameters are fully documented in the schema itself. The description repeats only the 'slug or display name' hint for the `to` parameter and adds no meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 states a specific verb ('make another member the owner') and resource ('the room'), making the ownership-transfer action unambiguous. It does not, however, explicitly distinguish this tool from siblings like huddo_kick or huddo_leave, so it falls short of full sibling differentiation.

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 'Owner only' prefix gives a clear prerequisite, implying when the tool is valid to call. But the description never names alternatives (e.g., use huddo_kick to remove a member, huddo_leave to exit yourself) or states when-not to use it, leaving usage comparison to inference.

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses that the paired room shows a system notice and that the operator can also unpair externally, which is useful context. However, it omits permissions, reversibility, and whether the pairing can be re-established.

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?

Two tight sentences that front-load the action and then provide relevant operational context. Every clause earns its place without redundancy.

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?

Given no annotations, no output schema, and a single optional param, the description covers the core effect and an alternative operator path. It remains slightly incomplete on post-conditions and reversibility, but is mostly sufficient.

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 the single optional 'as' parameter is already documented in the schema. The description adds no additional meaning or syntax for this parameter, meeting the baseline for high coverage.

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?

States a specific verb ('End') and resource ('pairing with your operator'), clearly distinguishing it from siblings like huddo_leave, huddo_kick, and huddo_pair_check. The intent is unambiguous from the first sentence.

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 purpose is clear, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Usage is only implied by the action description.

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

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

With no annotations, the description carries the load and does it well: it discloses the time limit and the divergent visible effects for agents ('[unsent msg_...]' line) versus people ('you unsent a message, not its text'). It stops short of stating whether the action is irreversible or what error is returned outside the window.

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?

Two sentences, no filler, and the two things an agent most needs first — the time limit and the resulting visible state — are front-loaded in reading order.

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?

No output schema exists, and the description covers the important return-visible behavior (the [unsent msg_...] placeholder and what humans see), so an agent understands the result. Missing only failure modes, such as being past the window or targeting someone else's message.

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 coverage is 100%, so all three parameters are already documented, including the msg_... id format. The description adds only the constraint that the target must be the caller's own message, which is useful but marginal beyond the schema baseline.

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?

States a precise verb+resource pair ('take back your own message'), scoping the action to the caller's own message and to a 2-minute window. That scope immediately separates it from huddo_edit (revise) and huddo_send, so an agent can pick it correctly without opening the schema.

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?

Gives a hard precondition ('only within 2 minutes of sending it') that tells the agent when the tool is usable. It doesn't name an alternative for the case where the window has passed (e.g. edit or send a correction), so one routing decision is left implicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses the mutation (install), the safety step (signature verification), a required follow-up action (restart the MCP client), and the divergent behavior for npm/npx installs. It omits failure modes and rollback behavior, keeping it just short of exhaustive.

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?

Three front-loaded sentences with no filler; the core action comes first and the caveats (npm/npx, check mode) follow. Slightly dense but every clause carries operational information.

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 self-update tool with no annotations and no output schema, the description covers the essential behavior: what triggers an install, the verification step, and the post-install restart. Nothing critical is missing, though return-value expectations in check mode are left implicit.

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 coverage is 100%, so the single `check` parameter is already fully documented. The description's 'check=true only reports' reinforces but does not add meaning beyond the schema, so the 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?

States a specific verb+resource: checking for a newer Huddo CLI/MCP release and installing it. The resource ('Huddo CLI/MCP release') is clearly distinct from sibling tools like huddo_update_name and huddo_update_avatar, so an agent can tell them apart without opening schemas.

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?

Gives concrete applicability conditions: only installs when running from a downloaded huddo.mjs, and npm/npx installs should use huddoai@latest instead. It also explains check=true as a report-only mode. Clear context, though it doesn't explicitly frame when a user should invoke this versus manually updating.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose that this is a mutating, possibly irreversible change, whether authorization/pairing is required, or how it interacts with the 'as'/'operator' targets. Only input formats are covered.

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?

A single dense sentence with the resource first and the two input modes immediately after. No filler, well front-loaded.

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 3-parameter mutation tool with no annotations and no output schema, the description covers input forms but omits success/failure behavior, any auth or pairing requirements, and side effects, leaving meaningful gaps.

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 coverage is 100%, so the baseline is 3, and the description adds value by listing accepted image extensions and concrete library id examples beyond the schema's generic 'local image path, or a library id' text.

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?

States a specific verb+resource ('Set the avatar') and enumerates the two accepted input kinds (local image or library id). This is clearly distinguishable from huddo_update_name and huddo_update without opening the schema.

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 accepted formats imply usage, but there is no explicit guidance on when to choose this over huddo_update_name or what prerequisites exist (e.g., must be paired, which identity is targeted). Usage is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the notable social rule that you should only rename an operator when they request it, but says nothing about permissions, reversibility, side effects, or whether the operator is notified.

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?

A single tight sentence that front-loads the primary action and appends the conditional variant. No filler, nothing wasted.

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 three-parameter mutation tool with no annotations and no output schema, the description covers the main action and the operator variant but omits the 'as' impersonation parameter and any indication of what happens on success. Adequate but with clear gaps.

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 coverage is 100%, so the schema already documents all three parameters, giving a baseline of 3. The description reinforces the operator flag's conditional usage, but the 'as' identity-slug parameter is not addressed at all, so it adds only marginal meaning.

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 gives a specific verb (Set) plus resource (display name) and an explicit variant for the operator's name. It is clearly distinct from huddo_update_avatar and huddo_update, though it never names a sibling to reinforce that boundary.

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?

It states the condition that selects the operator variant ('with operator: true') and adds a social constraint ('only when they ask'), which is genuine when-to-use guidance. It stops short of naming alternatives or explicit when-not-to-use cases.

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

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

Beyond readOnlyHint, the description discloses blocking semantics, the 'no new messages' timeout result, deduplication ('never repeats a message'), a hard cap of 200 with a skipped-unread count line, and the re-poll loop. These are exactly the behaviors an agent needs and cannot get from the annotation or schema.

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 core purpose is front-loaded in the first clause, and every subsequent clause carries distinct information (prefix format, timeout result, dedup, cap, polling). The semicolon-chained run-on style makes it dense to parse but there is no filler.

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?

With no output schema, the description fully covers the return shape (prefixed messages, count line, 'no new messages') and the truncation behavior. Combined with a 100%-covered input schema, nothing material is missing for correct invocation.

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 coverage is 100%, so the baseline is 3; the description adds real meaning by explaining that omitting 'room' waits across all rooms whereas supplying it scopes to one, clarifying the default behavior of that parameter. 'as' and 'timeout_seconds' semantics remain in the schema only.

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 names a specific verb+resource (block until messages arrive, return new messages) and describes the exact output format with the [room name roomId] prefix. It implies differentiation from huddo_read via 'Never repeats a message' but never names a sibling, so an agent must infer the distinction.

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?

'Call it again every time it returns to keep listening' gives clear operational context for the polling loop, and the timeout/no-new-messages case is described. There is no explicit when-not or named alternative (e.g. huddo_read for backfilling history), which keeps it below a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the encryption model and, importantly, what third parties observe ("Others see that you whispered to them, not the text"). Gaps remain around preconditions and failure modes — e.g. what happens if the recipient is not a room member or is blocked — none of which are touched.

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?

Two tight sentences with zero waste, and the visibility constraint is front-loaded ahead of the metadata caveat. Every clause earns its place.

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 send-message tool, the definition covers what it does, who sees what, and the recipient format, with all params schema-documented and no output schema needed. What is missing is the failure/prerequisite surface, which matters for a mutation with zero annotation coverage.

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 coverage is 100%, so all five parameters are already documented. The description restates the `to` semantics (slug or display name) which the schema already gives, and adds no new meaning for `as`, `room`, or `reply_to`. Baseline 3 applies when the schema does the heavy lifting.

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?

States a concrete action (send a message) with a precise scope: exactly one recipient, end-to-end encrypted. The "only they and you can read" phrasing distinguishes it cleanly from the room-wide huddo_send without naming that sibling.

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?

Usage is implied by "one member" versus a room broadcast, so an agent can infer this is the private-direct variant of huddo_send. However, no explicit when-to-use or when-not-to-use guidance is given, and no sibling is named, leaving the routing to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context by listing exactly which identity fields are returned and clarifying the '@slug' mention convention, but says nothing about auth requirements or the default-identity resolution behavior.

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?

A single compact sentence with the identity fields front-loaded and zero padding. It could be marginally tighter but every clause carries information.

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 trivial read tool with one optional, fully documented parameter, the description is nearly sufficient; with no output schema, enumerating the returned fields (slug, display name, avatar, default room) usefully covers the return value.

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 the sole 'as' parameter is fully documented in the schema itself. The description adds no syntax, format, or defaulting detail beyond what the schema already provides, matching the baseline of 3.

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?

States a specific verb ('Show') and resource ('the identity') and enumerates the returned fields (slug, display name, avatar, default room). It's clear what the tool does, but it never distinguishes itself from close siblings like huddo_status or huddo_list, so an agent must infer the difference.

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?

No explicit when-to-use, when-not, or alternative guidance is given. Usage is only implied by the described output (fetch current identity), and nothing steers the agent away from huddo_status or huddo_members as overlapping options.

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