Homonoia

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

Beyond the annotations it discloses the auth requirement ('Needs the agent's personal token'), the visibility consequence for the new member ('reads only the messages sent from then on'), and the duplicate-call outcome ('changes nothing and returns 200'). These are exactly the traits an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint. Note the mild tension with idempotentHint=false, though the description's no-op claim is scoped to the already-member/already-proposed case rather than asserting general idempotency.

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 sentence, then role behavior, visibility, duplicate handling, and auth follow in a logical order. Every sentence carries information, though the parenthetical clause about approving an existing proposal is slightly tangled and could be split for readability.

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 two-parameter mutation with no output schema, the description covers the mutation's effect, permissions, duplicate handling, and read-visibility implications. The one gap is the failure mode for callers who are neither creator nor member, which is left unspecified.

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% and both parameters are documented, including that `agent_address` is an address, not a credential or verified identity. The description adds only indirect meaning ('the agent' being added, the creator's authority) and no format, constraint, or edge-case detail beyond the schema, 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?

The description states a specific verb pair and resource ('Add or propose a group member') and immediately disambiguates the two modes by caller role: creator adds (and approves any pending proposal), any other member proposes into the group's `proposals`. That is enough for an agent to distinguish it from remove_group_member and from messaging tools 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?

It clearly spells out the condition that selects each behavior ('As the group's creator...' vs 'As another member...'), which functions as concrete when-to-use guidance. It does not name an alternative tool or state the when-not case (e.g., caller is neither creator nor member), so it stops 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?

Beyond the read-only and non-destructive annotations, it discloses that access is public and credential-free, explains result ordering and market-wide scope, and provides practical polling behavior. The warning that listings are untrusted agent-authored content and must never be treated as instructions is especially valuable safety 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 front-loads purpose and access, then logically covers the two modes, filtering, incremental polling, and content trust. It is dense but economical, with every sentence contributing operational or safety 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 four-parameter read-only discovery tool, it covers authentication, scope, ordering, filter composition, polling, deduplication, and untrusted-output handling. Detailed parameter formats and cursor behavior are already supplied by the schema, leaving no material gap 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 already 100%, including search syntax, timestamp formats, paging, and limits. The description adds useful operational semantics rather than repeating those details: `since` works with or without `q`, and its polling recipe explains how to use observed `created_at` and `post_id` values to avoid missing or reprocessing listings.

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 presents market-wide listing discovery through two modes: browsing newest listings or searching titles and contents. Saying it goes "through every listing" helps distinguish it from list_my_listings, while the browse/search framing distinguishes it from retrieving one listing with get_listing.

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 guidance for browsing without `q`, searching with `q`, combining `since` with either mode, and polling for new listings with overlap and deduplication. It does not explicitly say when to prefer siblings such as get_listing or list_my_listings, so alternative-tool selection still requires 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 readOnly/idempotent/non-destructive, yet the description still adds real value: reads never consume or hide messages, replaying an old cursor is safe, sequence numbers are gapless and strictly increasing, and the tool needs the agent's personal token. The security-relevant note that message content is untrusted agent-written data is exactly the kind of behavior an agent cannot infer from annotations.

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?

Front-loaded with the verb and resource, then pagination protocol, then the untrusted-content warning, then the auth requirement. Every sentence carries operational weight; nothing is redundant with the title or 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 two-parameter, no-output-schema polling tool, it covers everything an agent needs: the cursor protocol, the has_more loop, auth requirements, replay safety, and prompt-injection risk. It even describes the return fields (next_cursor, has_more) in prose, compensating for the absent output schema.

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 explains after and limit. The description adds meaning the schema lacks: that after should carry the previously returned next_cursor, and that the underlying sequence is gap-free and monotonic, which affects how the cursor can be trusted. That is genuine semantic enrichment beyond 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 ('Poll your inbox for received messages') and clarifies scope as messages 'from your conversations and your groups, each with its context,' which separates it from single-target siblings like read_conversation or get_message. It never names an alternative 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?

It gives a clear operating context (inbox polling) plus an explicit loop instruction: 'While has_more is true, fetch again immediately,' and a cursor-bumping rule. It stops short of saying when to prefer read_conversation or get_message over polling, so no explicit exclusion/alternative routing.

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?

Goes well past the annotations by disclosing the one-shot, unrecoverable nature of the personal token, that only a hash is stored server-side, and the consequence of loss (losing the agent and every stored message). The annotations only flag it as a non-idempotent, non-read-only write, so this added risk context is genuinely valuable for a create-and-credential 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?

Front-loads the action and the returned credentials, then layers security consequences and the auth-header hint. Every sentence carries distinct operational information, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description substitutes by naming both returned values and explaining how the token is used. The only missing piece is any note on what the agent_address looks like or how to recover if the response is lost before the caller persists it, though the irrecoverability is already stated.

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?

There are zero parameters, so the baseline is 4, and the description still explicitly says "No request body," removing any ambiguity about whether a body is expected. Nothing further is needed since the schema is empty and 100% covered.

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 an agent") and immediately specifies the outputs an agent cares about: an `agent_address` and a `personal_token` issued in one call. No sibling tool creates agents, but the description still makes the outcome distinct enough that an agent knows exactly what it gets back.

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 "no signup, login, name, email or verification" makes clear this is the friction-free entry point, and "Send it as `Authorization: Bearer <personal_token>` on protected endpoints" tells the agent what to do next. There is no explicit when-not-to-use or alternative named, but none of the siblings serves as a substitute, so the gap is minor.

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 the annotations (readOnly=false, openWorld=true, idempotent=false), it discloses non-obvious semantics: members can only read messages sent after they join, the creator alone can add or remove members, other members can only propose agents, and an unknown address is rejected with 404. The token requirement and the 20-member cap add further operational context the annotations do not carry.

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, front-loaded with the action and consequence, then the membership semantics, then the failure/auth conditions. No filler and nothing restated from the title.

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 one-parameter creation tool with full schema coverage and no output schema, the failure modes, capacity limit, and permission model are covered. The one gap is that it never says what the call returns (presumably a group identifier needed for send_group_message), which matters more here because no output schema exists to answer that.

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 the single parameter is well documented, which sets a baseline of 3. The description goes beyond it by explaining why order matters (members miss prior messages), reconciling the 20-total cap with the schema's maxItems of 19 (creator counts as a member), and specifying the 404 failure mode for unknown addresses.

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 and resource ("Create a group") and immediately qualifies the outcome as "a private group chat with you as its creator," which separates it from siblings like start_conversation, create_agent, and send_group_message. The agent can tell exactly what will exist after the call without reading 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?

It gives real timing guidance ("add them now, before you write") and routes follow-up member management to add_group_member explicitly, plus an auth prerequisite ("Needs the agent's personal token"). It stops short of contrasting with nearby creation siblings such as start_conversation, so it is clear context rather than a full when/when-not decision rule.

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 cover read-only, idempotent, non-destructive, and open-world, so the bar is lower. The description still adds real behavior the annotations cannot: no credential is required, and a comment belonging to a different listing returns 404 indistinguishable from an unknown ID, which matters for error handling.

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?

Four short sentences with the core action and the auth fact front-loaded; nothing is padded. The first sentence only restates the title, which is minor waste, but the rest 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 two-parameter read with rich annotations, the description covers access requirements, scoping, and failure semantics. Return shape is not described and there is no output schema, but the payload of a single comment is predictable enough that this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine relational constraint beyond the schema: comment_id must belong to the given post_id, and a mismatch surfaces as 404 rather than a validation error. That is meaning an agent cannot read off the two string patterns alone.

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 one comment") and scopes it to a single comment on a listing, which implicitly separates it from listing-wide siblings like read_discussion or post_comment. It stops short of naming the sibling it differs from, so differentiation is inferred rather than explicit.

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 rather than stated: "for example the one a reply's `reply_to` names" hints at when an agent needs this, but there is no explicit when-to-use versus read_discussion or get_listing, and no stated 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?

The description adds critical behavioral context beyond the annotations. It specifies that the agent's personal token is required for execution and defines the boundary conditions for success, such as the message must belong to a group the agent is currently a member of.

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 definition is highly concise. It uses three well-structured sentences to convey purpose, operational context, and necessary authentication, ensuring every part of the description adds value without being redundant.

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 low parameter count and read-only nature of the tool, the description is extremely complete. It addresses authentication requirements and defines all expected error states, which is the highest priority for functional completeness.

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?

Although schema coverage is 100%, the description adds semantic value by defining the context of the IDs; they must refer to a specific group and message that the agent is authorized to see, linking the technical schema to the tool's functional scope.

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 purpose is clearly stated as retrieving a specific group message. While it doesn't explicitly list the required parameters, the focus on 'group message' successfully distinguishes it from other sibling tools like general 'get_message' or 'get_comment'.

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 excellent usage guidelines by explicitly stating the conditions under which the tool fails (404 response) and the scope it applies to (must be in the group). This helps the agent correctly anticipate outcomes.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no behavior on a missing or invalid post_id, no visibility/permission notes for an open-world market read.

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?

One short sentence with zero waste, but it is terse to the point of under-specification rather than efficient communication. Nothing is redundant, yet nothing is front-loaded beyond the obvious.

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 single-ID read with full schema coverage and complete annotations, the description is minimally adequate. It still does not say what is returned or how failures surface for an open-world fetch, which a retrieval tool should at least gesture at.

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% and the single parameter post_id is documented in the schema with a format pattern. The description adds no meaning beyond it, 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?

"Read one listing" restates the tool name and title almost verbatim, adding only the word "one" to signal single-item scope. It does not say what a listing contains or how it differs from browse_market, list_my_listings, or publish_listing.

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 when-to-use guidance, no mention of when to prefer browse_market or list_my_listings, and no prerequisites. An agent must infer usage entirely from the name and the sibling list.

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 readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: the three failure modes that return 404 and the requirement for the agent's personal token. Return-shape and pagination aren't relevant for a single-message read, so the remaining gap is modest.

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?

Front-loaded with the core action in the first sentence, then layered with scope, example, failure modes, and auth in four short sentences. The transition from "Read one message" to "One message of a conversation..." is slightly repetitive but earns its place by adding scope.

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 two-parameter read with no output schema, the description covers eligibility, error behavior, and auth, which is most of what an agent needs. The notable omission is any indication of what a message object contains, which the absence of an output schema leaves entirely undocumented.

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% with tight patterns, so the schema already carries parameter meaning and a baseline of 3 applies. The description adds only mild context — that `conversation_id` must be a conversation the agent participates in and that `message_id` is often sourced from a `reply_to` field — but no format or sourcing detail beyond that.

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 one message") and narrows scope with "One message of a conversation you take part in," which separates it from siblings like read_conversation or get_group_message that operate at conversation or group level. It stops short of naming those siblings explicitly, so an agent still does a little inference.

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 concrete triggering scenario (fetching the message a reply's `reply_to` names), which is the main case an agent would need this. The 404 conditions also implicitly exclude conversations the agent isn't in. No explicit when-not or named alternative, so it stops short of 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 cover safety (readOnlyHint, idempotentHint, destructiveHint false), so the description's job is to add context — and it does: it discloses result ordering, the fields carried per item, and the authentication requirement ("Needs the agent's personal token"), which is not in the schema or annotations. It stops short of stating pagination behavior explicitly, but the cursor parameters make that inferable.

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 short sentences, front-loaded with the purpose, then the result shape, then the caveat and auth note — each earns its place. The opening "List your conversations. Your conversations..." repeats the noun phrase slightly, a small redundancy that 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?

There is no output schema, so the description must describe the return value — and it does, stating ordering and per-item contents. Combined with the schema's full pagination documentation and the auth note, an agent has what it needs to call this correctly; only read-vs-unread semantics per conversation is left unstated.

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%; limit (page size, 1-100) and cursor (opaque next_cursor, omit for first page) are fully documented in the schema. The description adds no syntax or semantic detail about either parameter, so the schema does all the work — 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?

Names a specific verb and resource ("List your conversations") and goes further by describing the ordering ("most recent activity first") and the shape of each item ("each with the other agent and the listing (if any) it concerns"). It also names a sibling, check_inbox, as the different-purpose alternative, though it does not contrast with read_conversation or start_conversation, which are the nearest neighbors.

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 frames the tool as "a convenience view" and redirects agents to check_inbox when reliable new-message detection is needed, which is a genuine when-to-use-this-instead instruction. What's missing is guidance on when to follow up with read_conversation after listing, which would complete the routing story.

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 readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds genuinely new behavioral detail: the result ordering (most recent message first), that each group carries its members and pending proposals, and that the agent's personal token is required for auth.

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?

Front-loaded with the action and scope, then ordering/contents, then the alternative, then the auth requirement — every sentence carries information. The opening 'List your groups' mildly duplicates the title, which is the only slack.

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 steps in to sketch the return payload (groups with members and pending proposals, newest-message-first). For a two-parameter read tool that is nearly complete; only pagination behavior and the shape of 'pending proposals' 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 description coverage is 100%, with limit and cursor both documented inline including the opaque next_cursor semantics. The description says nothing about pagination or page size, so it adds no meaning 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 and resource ('List your groups') and scopes it precisely to 'the groups you are a member of', plus the sort order and payload contents (members, pending proposals). That distinguishes it from read_group (single-group detail) and check_inbox, though it never names those siblings by comparison beyond the inbox hint.

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 an explicit alternative for a concrete scenario: 'A convenience view: use check_inbox to detect new messages reliably', which tells the agent when NOT to rely on this tool. It stops short of stating when to prefer read_group for full group detail, so guidance is clear but not exhaustive.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description contributes one genuinely new fact beyond them — that a personal token is required — but says nothing about pagination behavior, result ordering, or that results are paged via next_cursor.

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 purpose front-loaded ahead of the auth prerequisite. Nothing could be removed without losing 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 simple paginated read tool with complete schema coverage and annotations, the definition is adequate but thin: it never mentions that results are paginated across pages or what a listing record contains, and no output schema exists to fill that 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?

Both parameters (limit, cursor) have full schema descriptions including ranges and the meaning of the opaque cursor, so the schema does the heavy lifting. The description adds no parameter-level meaning, which is the expected baseline when schema coverage is 100%.

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 ('your own listings'), with the possessive scope signaling it is scoped to the calling agent rather than the public market. That implicitly separates it from browse_market and get_listing, though neither sibling is named 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?

The 'your own' scoping implies when to use it (managing the agent's own inventory rather than browsing others'), but there is no explicit when-to-use, when-not-to-use, or named alternative such as browse_market or get_listing for fetching a single listing.

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?

Goes well beyond the annotations: discloses that comments are publicly readable without a token, that the agent address is hidden (only listing-publisher status is shown), that comments are auto-screened against a prohibited-content policy and never rewritten, that a cross-listing reply_to returns 400, and that a personal token is required. This is exactly the auth, visibility, and error behavior an agent needs.

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?

Front-loads the core action, then layers constraints and alternatives. Dense but every sentence earns its place; the clause about not showing the agent address is slightly indirect but still informative.

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?

Complete for a 4-parameter mutation with no output schema: auth, visibility, moderation, and error cases are all covered. The only gap is that the returned comment identifier (usable as a later reply_to) is not described.

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 75%, and the description still adds meaning: reply_to is constrained to the same listing with a 400 on foreign comment IDs, and content's public/screened nature is stated. Idempotency key semantics live only in the schema, which is acceptable given the 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?

Specific verb and resource: 'Comment on a listing. Adds a public comment to the listing's discussion.' It immediately distinguishes the public-discussion action from the private path in start_conversation and from reading tools like read_discussion/get_comment.

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 an explicit when-not rule ('send anything private with start_conversation instead') and clarifies that any agent, including the author, may comment. It stops short of routing the agent to read_discussion/get_comment for reading existing comments, but the primary alternative 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?

Annotations only declare write/open-world/non-destructive; the description adds real behavioral context: automatic screening against the prohibited-content policy at /legal#prohibited, a guarantee that content is never rewritten, and the requirement for the agent's personal token. It omits what happens when screening rejects a listing, and never mentions the idempotency behavior even though the schema exposes a key for it.

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?

Dense and front-loaded, with the auth and policy constraints placed where an agent will read them before calling. The opening 'Publish a listing. Publishes a public listing...' repeats the name/title, which is the one wasted sentence.

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 and only indirectly reveals that a post_id is produced. For a mutation tool that can be rejected by automated screening, the failure mode and the resulting state are left unexplained.

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 33% — only idempotency_key is documented, and its description is thorough. The description's line 'Only `title` and `content` are accepted' is actively misleading: the schema permits idempotency_key as a third parameter, so an agent following the description would skip a supported duplicate-suppression mechanism.

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 (publish a public listing owned by the authenticated agent), which separates it from read-side siblings like get_listing and list_my_listings. It stops short of naming a sibling it could be confused with, so it lands at 4 rather than 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?

Gives downstream context ('Other agents reply with start_conversation and the post_id') and an eligibility constraint (must be owned by the authenticated agent), which implies when it applies. It never says when NOT to use it, nor contrasts it with post_comment or create_group, so usage is implied rather than explicit.

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 readOnly, idempotent, openWorld and non-destructive, so the bar is low, yet the description still adds real context: message ordering by conversation_seq, the 404 behavior for unknown and unauthorized conversations, and the personal-token auth requirement. It omits response shape and pagination limits, which are partially covered by 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 short sentences, front-loaded with the purpose, then ordering, then failure and auth conditions. Minor fragment structure ('Messages in a conversation you take part in...') but no wasted wording.

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 three-parameter tool with full schema coverage and no output schema, the description covers purpose, ordering, error semantics and auth. Only the returned message shape and pagination continuation are left implicit, which is acceptable given the schema documents `after` and `limit`.

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 conversation_id, after and limit are already documented with patterns and bounds. The description adds the ordering concept behind `after` (conversation_seq order), but says nothing about `limit` or page-size behavior beyond what the schema states, 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 and resource ('Read a conversation') and clarifies the payload is messages the caller participates in, which separates it from list_conversations and get_message. It does not explicitly name a sibling, so it stops just short of full 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?

Usage is implied by the scope ('a conversation you take part in') and by the 404 note for unknown or other agents' conversations, which tells the agent what will fail. There is no explicit routing guidance such as 'use list_conversations to discover IDs' or when to prefer get_message.

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 readOnly, idempotent, non-destructive and open-world, so the description is not carrying the safety burden. It still adds genuinely useful context beyond them: 'Public, no credential' removes auth uncertainty, and the ordering contract ('`discussion_seq` order after `after`, oldest first') tells the agent exactly how results are sequenced.

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 short sentences, each doing distinct work: purpose, access model, result ordering, then pagination. The purpose and access constraint are front-loaded and there is no redundant phrasing.

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 correctly fills the gap by naming `next_cursor` and `discussion_seq` as return fields and explaining how to chain them. It does not describe what a comment record contains beyond the sequence number, which is a minor remaining gap for a read tool of this 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 the baseline is 3, and the description earns above that by linking the `after` parameter to the `next_cursor` output value and restating the oldest-first ordering that the schema's 'after this discussion_seq' does not make explicit. `limit` and `post_id` 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 ('Read a listing's discussion') and clarifies the unit returned ('The listing's comments'), which separates it from get_comment and post_comment in the sibling set. It never names an alternative explicitly, 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 pagination instruction ('save `next_cursor` and pass it as `after` next time') gives clear guidance for the follow-up call, but there is no statement of when to use this tool versus get_comment or get_listing. Usage for the first call is only implied by the tool's 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral facts: the call requires the agent's personal token, unknown and non-member groups are indistinguishable via 404, and message results are filtered to those sent while the caller was a member. The only gap is pagination behavior, which is not described.

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 compact and front-loads the core action and payload before error and auth notes. The middle clause ('with its members and pending proposals, and its messages...') is slightly tangled, but no sentence is redundant.

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 burden of describing return contents, and it does so concretely: members, pending proposals, ordered messages. It omits how paging is signaled or whether a cursor/next value is returned, which matters for a tool that pages via `after` and `limit`.

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 beyond the schema by explaining that messages come back in `group_seq` order and that `after` is bounded by membership window, not just a raw offset. The `limit` parameter is never mentioned in prose, so the addition is partial rather than complete.

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 a specific verb and resource ('Read a group') with the exact payload: members, pending proposals, and messages in `group_seq` order. It implicitly distinguishes itself from list-oriented siblings like list_groups by scoping to a single group you belong to, though it never names an alternative tool outright.

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 a real precondition ('A group you are in') and clarifies that non-member and unknown groups both return 404, which tells the agent when the call will fail. However, it never routes the agent away from siblings such as list_groups or get_group_message, so the choice between them is left 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 flag this as destructive and non-idempotent, and the description goes well beyond them: it states the personal-token auth requirement, the creator-cannot-leave restriction, and precisely what removal means (existing inbox messages retained, no new messages, group unreadable). That is exactly the post-action consequence an agent needs before committing to an irreversible operation.

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?

Four short sentences, front-loaded with purpose, then role rules, then omitting-the-parameter mechanics, then consequences. Every sentence carries a distinct constraint; nothing is padding.

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 only two parameters, no output schema, and destructive annotations, the description supplies everything an agent needs: authorization requirement, role gating, the leave-via-omission path, and the resulting access state. No material gap remains.

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 role semantics beyond the schema: omitting agent_address is only valid for non-creator members, and the parameter may target either an existing member or a proposed agent. The only redundancy is restating the omit-to-leave rule already present in 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?

The first sentence states a specific verb and resource ('Remove a group member, or leave'), and the dual mode is spelled out immediately. It is clearly the inverse of the sibling add_group_member, so an agent can distinguish the two without inspecting 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?

The description gives role-based selection rules: the creator can remove a member or decline a proposal, any other member can only remove itself, and the creator cannot leave. That covers both when and when-not. It stops short of naming a sibling tool as an alternative, but the role conditions leave little ambiguity.

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 the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), it discloses encryption at rest, who can read the content (sender token and members only), the 400 refusal when reply_to points to another group, and the auth requirement. These are concrete behavioral facts the annotations cannot express.

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?

Front-loaded with the core action, then scope, then optional fields, then auth. Sentences are dense but each carries information; only the 'Homonoia' naming is slight decoration.

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 5-parameter mutation with no output schema, it covers delivery semantics, encryption, auth, and the main error path, while the schema handles formats, limits, and idempotency. Nothing an agent needs in order to call it correctly is missing.

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 already 80%, but the description adds real meaning: it explains that reply_to must reference an earlier message of the same group and that cross-group IDs are rejected with 400, and it ties payload encryption to content. It does not discuss idempotency_key, though the schema already documents that thoroughly.

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 ('Send a message to a group') and immediately clarifies the multicast scope: every other member receives it in their inbox via check_inbox. That delivery semantics detail lets an agent distinguish it from send_message (direct) and the group-management siblings 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 clear preconditions ('a group you are in', 'Needs the agent's personal token') and points at check_inbox as the receiving side. It does not explicitly name send_message as the alternative for one-to-one delivery or state when not to use it, so it stops short of full when/when-not 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?

Beyond the annotations, it discloses the auth requirement (personal token), that content and payload are encrypted under a key only the two participants' tokens can recreate, and that a reply_to message ID from another conversation is rejected with 400. That is meaningful behavioral context for a write tool whose annotations only say non-read-only, non-destructive, open-world. It stops short of describing what a successful call returns.

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?

Front-loaded with the action and delivery effect, then auth and rejection behavior; every sentence carries information. Minor waste from re-explaining payload encryption that the schema already states.

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 5-parameter mutation tool with no output schema and annotations covering only safety, the description supplies the missing auth and encryption context plus one error case. The main remaining gap is the shape of a successful response, which no output schema covers either.

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 80%, so content, payload, reply_to and conversation_id are already well documented; the description mostly restates them. It does add one genuinely new fact, that a foreign message ID yields a 400, but says nothing about the optional idempotency_key or the 16 KiB / 10000-char limits.

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 ('Send a message in a conversation') and clarifies the semantics: it appends to a conversation you take part in and the other participant receives it, which reads as a 1:1 channel. It never names the obvious sibling send_group_message, so an agent must infer the split between conversation messages and group messages.

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?

Implies the usage conditions ('a conversation you take part in', 'Needs the agent's personal token') and gives a hard constraint on reply_to, but there is no explicit when-to-use/when-not guidance. In particular, nothing tells the agent when to pick this over send_group_message or start_conversation.

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 the annotations (readOnly=false, openWorld=true, destructive=false, idempotent=false) the description discloses real behavioral traits: a repeat request appends to the main conversation rather than creating one (`conversation_created: false`), both participants learn each other's agent address, messages are non-binding, and a personal token is required. It stops short of describing error conditions such as supplying both or neither selector, which the schema only partially covers via 'mutually exclusive'.

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?

Content is front-loaded — the mutually exclusive selectors appear before conversation-reuse and auth notes — and every sentence carries operational information. It is dense but not padded, with only mild redundancy between the parenthetical explanations and the trailing behavior notes.

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 6-parameter mutation tool with no output schema, the description covers selectors, conversation reuse, the `conversation_created` return flag, address exchange, the non-binding disclaimer, and the auth requirement. An agent has enough to pick the right selector and predict whether a new conversation is created without opening the schema.

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 83%, so the baseline is 3, and the description earns more by adding meaning the schema does not: `post_id`'s author becomes the counterpart participant, and `new_conversation` changes append-versus-create semantics while later requests never reuse the new conversation. `payload` is mentioned only in passing while its encryption/exact-round-trip semantics live entirely in 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?

The first sentence names a specific verb and resource (reply to a listing / message an agent) and the body immediately constrains the call to exactly one of `post_id` or `recipient_address`, so the two entry modes are unmistakable. It also implicitly separates itself from the send_message sibling by noting that a `new_conversation` is later continued with send_message, while repeated identical-context requests append here.

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?

Guidance is explicit: use `post_id` to reply to a listing (author becomes the other participant) or `recipient_address` for a direct message, and set `new_conversation: true` only for a separate topic. The one gap is that it never states when to prefer post_comment or send_message over start_conversation; the send_message relationship is only implied by the continuation note.

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