MyHumanRep: Contact a Human

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

Annotations declare readOnlyHint=false and idempotentHint=true, so the mutation/idempotency profile is already structured. The description adds genuinely new consequence information: acceptance is 'never a contract, charge, assignment or dispatch,' which tells the agent exactly how far the commitment reaches. It stops short of saying what record is produced or whether acceptance closes the conversation.

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 action and immediately followed by the required input and the safety caveat. No filler and nothing repeated from structured fields.

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, the description covers the effect and the key input but omits the post-acceptance state (what is recorded, whether the proposal is consumed, whether the conversation closes) and says nothing about the auth-token parameters. Adequate to call correctly, but thin for a state-changing 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 60%; the description reinforces the revision parameter ('the revision you read') but that constraint is already in the schema. It adds nothing about proposal_id, which is required yet undocumented in both schema and description, nor about the optional note or the two token parameters.

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 ('Accepts the human's current revision as nonbinding terms') and scopes it to the current revision, which distinguishes it from counter_nonbinding_proposal and withdraw_nonbinding_proposal without naming them. The 'nonbinding' qualifier further pins down what kind of acceptance this is.

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?

'Pass the revision number you read' gives the calling condition implicitly: you accept a revision you have already read. However, there is no explicit guidance on when to choose accept versus counter versus withdraw, and no stated prerequisites (e.g., that a proposal must exist and be open). Usage is inferable rather than spelled out.

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=false, idempotent=true and openWorld=false, so safety and repeat-call behavior are covered. The description adds genuinely new context: claiming is token-gated proof of possession and 'Grants nothing about other threads', which bounds the privilege escalation an agent might assume. It does not cover the already-claimed case or failure modes, keeping it below 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?

Two short sentences, zero filler, with the core action front-loaded and the scope limit as a follow-up. Nothing to trim.

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 should indicate what a successful claim yields (e.g., the conversation appearing in list_my_conversations) and what happens on an invalid or already-used token. The token-proof and scope statements are helpful but leave the observable outcome undefined.

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 67%, with conversation_token and account_token already well documented in the schema (including the header fallback). The description adds nothing about which parameter carries the proof or that conversation_id is the target. Baseline 3 is appropriate since the schema is doing most of the work.

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 ('Links one conversation to your account') and names the proof mechanism, so an agent can tell this apart from read_conversation or list_my_conversations. It stops short of naming any sibling explicitly, so differentiation is by scope statement rather than routing.

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 'using that conversation's own token as proof' implies the precondition (you hold a conversation_token), but there is no explicit when-to-use/when-not, no mention of create_agent_account, and no pointer to rotate_conversation_token if the token is stale. Usage is inferable but not guided.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the key behavioral consequence beyond annotations: the close is irreversible and the user cannot reopen the conversation. It could have added anything about what happens to the conversation data, but the essential warning is present.

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 followed by the irreversibility warning. 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 rich annotations, a fully documented two-parameter schema, and no output schema, the description covers the one thing structured fields can't: the permanence of the operation. Deeper detail (e.g., what happens to message history post-close) is the only missing piece.

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%, including the nuanced note that conversation_token may be omitted when an account token header is sent. The description adds nothing about the parameters, so the 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 and resource ('Closes your conversation') and immediately names the permanent consequence, which separates it from siblings like continue_conversation or read_conversation. An agent can select it 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 second sentence effectively says when not to use it for pausing: once closed it cannot be reopened, so you must start a new conversation to continue later. It implies the alternative (start_conversation) rather than naming it explicitly, so it falls just 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 declare readOnlyHint=false, openWorldHint=true, and idempotentHint=true. The description adds 'own conversation' scope and idempotency-by-client_message_id, but idempotency is also detailed in the schema and no further behavioral context (e.g., auth/token handling) is added.

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 efficient sentence with no wasted words. The key action is front-loaded and the sibling reference is included compactly.

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?

The rich schema and annotations cover parameters, idempotency, and write behavior, so the description is sufficient for invocation. However, it does not clarify when to choose this tool over send_message, leaving a meaningful selection 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 description coverage is 100%, so the baseline is 3. The description reinforces client_message_id idempotency but adds no parameter semantics beyond what the schema already documents.

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: adding a message to the caller's own conversation, and names the sibling send_message as an equivalent. It is clear what the tool does, though 'Same as send_message' equates rather than differentiates use cases.

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 guidance on when to use continue_conversation instead of send_message, start_conversation, or other siblings. Saying 'Same as send_message' does not provide selection criteria or 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?

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=true, so the description's job is to add context — and it does: omitted terms carry over, revisions after agreement void the agreement and force re-acceptance, and the deal is explicitly nonbinding (no contract, charge, assignment or dispatch). It still omits anything about the response or token/auth needs, but the behavioral delta is substantive.

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 that front-load the core action and lineage semantics, then the consequence of use, then the nonbinding guarantee. No filler and nothing redundant with 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 15-parameter mutation with no output schema, the description covers the nonbinding nature and revision lifecycle well but leaves real gaps: no mention of what is returned (e.g. the new revision id), no guidance on the required idempotency key or the account/conversation token choice, and only half the parameters have schema descriptions.

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 only 47% across 15 parameters, so the description should carry more weight. "Omitted terms carry over" is genuinely valuable — it tells the agent this is a partial-update/patch call rather than a full replacement — but none of the individual fields (price, scope_text, deliverables, valid_days, confidentiality, account/conversation tokens) are explained beyond what the schema says.

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?

"Creates a new revision with the terms you change; omitted terms carry over" states a specific verb (creates a revision of an existing proposal) and the patch semantics of the operation. It never names the sibling tools it must be distinguished from (create_nonbinding_proposal, accept_nonbinding_proposal, withdraw_nonbinding_proposal), so routing depends on the reader inferring from the required proposal_id.

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: you counter an existing proposal and only the terms you change need supplying. The warning that "any change after agreement voids it, so both sides must accept again" is a useful prerequisite-style caveat, but there is no explicit when-not (e.g. when to use accept_ vs create_ vs withdraw_) and no named alternatives.

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/non-idempotent/closed-world, so the description carries useful extra burden: the token is returned exactly once and must be stored, and its scope is limited to conversations you have claimed. It does not mention what happens on repeated calls (duplicate accounts), which matters given idempotentHint=false.

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 load-bearing: what is created, what is returned and must be stored, and what the token does not grant. The critical store-the-token warning is placed early.

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 name account_token and its one-time nature. It leaves other likely return fields and repeat-call behavior unstated, which is a minor gap for a two-parameter creation 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?

With 50% schema coverage, the description partially compensates by clarifying that no human identity, model name, or KYC is required, which directly frames the terms_accepted gate. It adds nothing about display_label semantics beyond what the schema already says (non-identity, 80-char cap).

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 (creates a scoped application account) and bounds it to 'persistent personas', which separates it from accepting proposals or starting conversations. It doesn't explicitly contrast with the nearby create_persona sibling, so the boundary between the two is left for the agent to 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?

Usage is implied rather than stated: the tool is for standing up a persistent agent identity, and the agent should store the returned token. Negative guidance is present ('not a conversation token', no access to unclaimed threads), but there is no explicit when-to-use versus create_persona or the conversation tools.

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 flag write/open-world/idempotent, so the description's real contribution is the semantic framing: the proposal is nonbinding, is never a contract, charge, assignment or dispatch, and is subject to human review and possible counter. That is genuinely useful context an agent cannot get from the annotations, though token/auth and idempotency behavior are left to 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?

Two tight sentences: the first states what is produced and for what input, the second front-loads the safety-critical constraint. No filler, nothing 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 15-parameter mutation with no output schema and no annotation detail, the description is thin on operational essentials: it doesn't say what comes back (a proposal id?), that client_request_id is a mandatory idempotency key, or how account/conversation tokens are resolved. The nonbinding framing is complete, but the call mechanics are not.

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 only 47% across 15 parameters, so the description would ideally compensate. It does name the semantic core (scope, deliverables, timing, location, indicative price) and reinforces the 'indicative, nonbinding' nature of price, but says nothing about the token parameters, the required client_request_id idempotency key, valid_days, confidentiality, or the evidence/cancellation fields.

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 (proposes) and enumerates the resource contents (scope, deliverables, timing, location, indicative price) scoped to 'one of your capability requests'. It separates itself from accept/counter/withdraw siblings only indirectly, via 'a human reviews and may counter', rather than naming them.

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: the proposal attaches to an existing capability request, and the mention that a human 'may counter' hints that a counter path exists. It never explicitly says when to use this versus counter_nonbinding_proposal or withdraw_nonbinding_proposal, nor any prerequisites such as an active request in the right state.

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 declare a non-read-only, non-idempotent, closed-world write, and the description adds meaningful context beyond them: the default visibility is private and the result is a fictional identity with no legal or payment authority. It does not cover uniqueness handling for slug or what a duplicate creation attempt does, leaving a small 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?

Three short sentences, front-loaded with the action, then the default, then the safety boundary. No filler; each clause contributes.

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 21-parameter creation tool with no output schema, the description covers purpose and identity/safety framing but leaves the parameter surface and creation-failure behavior largely unaddressed. Adequate to select the tool, thin for invoking it correctly.

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 21 parameters and reported schema description coverage of only 10%, the description needs to carry parameter meaning, but it only names four loosely ('name, biography, style, briefs'). It says nothing about required display_name, the slug uniqueness rule, the origin enum restriction, or the account_token/header interaction, so it does not compensate for the coverage gap.

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 (creates an original persona) and lists the content it holds (name, biography, style, briefs). It clearly differentiates itself from update_persona by being the creation path, though it never names that sibling 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?

Sets a negative boundary ('never a verified natural person, legal identity or payment authority') and a default ('private by default'), which implies when the tool is appropriate. But it gives no positive when-to-use guidance or explicit routing against siblings like update_persona or create_agent_account (only the schema mentions the account_token dependency).

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 declare this is a non-read-only, non-idempotent, closed-world write, so the safety profile is covered, but the description adds no mutation-specific context: nothing about duplicate titles, what happens if a conversation_id is unclaimed, or whether the created project is returned with an id. 'Groups conversations ... so you can read one cited history later' is purpose framing, not behavior disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single waste-free sentence, which is good, but it is not front-loaded on the action — an agent skimming it learns what a project is before learning what the call does. The nested parenthetical also makes it slower to parse than its length warrants.

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 and only partial schema descriptions, the definition is thin: no return shape (project id? token?), no post-creation workflow, no error or validation behavior. An agent could call it but would not know what it gets back or how to proceed to reading the cited history.

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 60%, so the description should compensate and it partially does: it clarifies the ownership/claiming preconditions behind persona_id and conversation_ids, which is real added meaning. However, title (the only required parameter), goal, and account_token receive nothing, leaving the most important field unelaborated.

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 sentence explains what a project *is* (a grouping of claimed conversations plus an optional persona) rather than stating that this tool creates one; the verb comes only from the name. It hints at the downstream payoff ('read one cited history later'), which loosely points at get_project_history, but never names or contrasts 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?

There is no explicit 'use this when' guidance and no comparison to alternatives such as create_persona or get_project_history. The only usable cue is the embedded precondition that conversations must already be claimed by the account, which an agent must infer from a parenthetical.

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 disclose that this is not read-only, is open-world, and is idempotent. The description adds meaningful context beyond those annotations: unfamiliar needs are kept verbatim, reviewed by a person, and nothing is booked or paid. It does not fully explain what submission creates or how idempotency behaves, but it materially improves behavioral understanding.

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 short, front-loaded, and every sentence adds useful information: free-form objective/problem_statement, optional category/review handling, and nonbinding/no-payment status. There is no redundant or filler text.

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 23-parameter, open-world write tool with no output schema, the description is too thin. It explains the conceptual purpose and nonbinding nature but omits required conversation setup and idempotency details that are necessary 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?

The tool has 23 parameters with low schema description coverage, so the description must carry substantial parameter meaning. It only mentions objective, problem_statement, and category-hint behavior, leaving required fields such as conversation_id and client_request_id plus budget, token, timing, and evidence parameters unexplained.

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 that the tool submits a free-form description of a human need via objective or problem_statement. It also clarifies that no category is required and unfamiliar needs are reviewed verbatim, which helps distinguish it from more specific request_* siblings. It does not explicitly name an alternative sibling, 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?

The description implies usage by saying to describe anything you need a human for and that no category is required. It does not state when to use this versus specific tools like request_human_capability, request_human_observation, or create_nonbinding_proposal, nor does it give 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?

Annotations already cover safety (readOnly, idempotent) and closed-world scope. The description adds valuable behavioral details: truthful readiness (inquiry_available vs fulfillment_available), no credentials required, and acceptance of unlisted needs. These go beyond annotations, though return format specifics are absent.

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 concise sentences, front-loaded with the core purpose and key details. Every sentence contributes useful information without 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?

Given the tool's simplicity (no parameters, no output schema), the description provides adequate context: what is listed, readiness flags, no credentials, and openness to unlisted needs. It could explicitly describe the return structure (e.g., a list of services with statuses), but the current information is sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description appropriately does not discuss parameter semantics, as there are none to clarify.

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 the verb 'Lists' and the resource 'human capabilities', and adds specificity with '20 canonical services plus aliases' and readiness flags. It does not explicitly differentiate itself from sibling tools like request_human_capability, 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?

The description implies usage by saying 'capabilities you can inquire about' and 'Unlisted needs are welcome too,' giving some context. However, it does not explicitly state when to use this tool versus alternatives (e.g., request_human_capability) or any prerequisites beyond 'No credentials needed.'

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, closed-world), so the description's job is extra context; it delivers a genuine privacy boundary — 'Never includes internal notes' — which an agent cannot derive from structured fields. It still doesn't say whether requests are returned as a list, a single record, or how a pending/classified state manifests.

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, purpose front-loaded, and the exclusion clause earns its place as the only non-obvious fact. 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 does sketch the returned content (status, classification, owner notes) plus the privacy limit, which is adequate for a two-parameter read tool. It is slightly thin on how this differs from list_capability_requests and on the cardinality/shape of 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 coverage is 100%, so both conversation_id and conversation_token (including the token-omission rule) are already fully documented. The description only implies conversation scoping and adds no syntax or identity semantics beyond the schema, making baseline 3 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+resource (review status/classification/owner notes for the conversation's requests) and names the returned fields. It does not distinguish itself from the near-identical sibling list_capability_requests or get_conversation_status, so the agent must infer the 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?

No when-to-use statement and no alternatives named, despite a crowded sibling set (list_capability_requests, get_conversation_status, get_proposal_history). The only scoping cue is the implicit 'your conversation's requests'.

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, and openWorldHint=false, so the safety profile is covered. The description adds only a partial inventory of returned data and does not disclose auth requirements, rate limits, permission constraints, or other behavioral context beyond the 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?

The description is a single sentence with little wasted text, but its structure is ambiguous: 'its capability requests and Human Embassy inquiries' could refer to the conversation's contents or separate resources. It is concise but not clearly front-loaded or well-structured.

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 carry the burden of explaining return values. It names broad categories of returned data but does not describe status values, capabilities, inquiry states, counts, or response shape, leaving key return semantics incomplete.

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 conversation_id and conversation_token are fully documented in the schema. The description adds no additional parameter semantics, so the baseline score 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 identifies the resource (your conversation) and lists several things the status covers, including capability requests, Human Embassy inquiries, and unread human replies. However, it never defines what 'status' means and does not clearly distinguish this tool from siblings such as read_conversation, list_my_conversations, or get_capability_request_status.

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 guidance on when to call this tool versus alternatives like read_conversation or get_capability_request_status. Usage is only implied by the phrase 'your conversation' and the mention of included data.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious semantics — that the returned data is versioned audit records rather than the persona's memory or identity proof — which prevents an agent from misinterpreting the payload. It omits pagination, ordering, and behavior when access is denied.

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 resource and scope, with zero filler. The second sentence is terse to the point of being slightly cryptic, 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 two-parameter read-only tool with no output schema, the description should convey something about the shape of the returned history (entry structure, ordering, whether it is paginated). It asserts the data is 'records' but never says what a record contains or how the history is ordered, so the agent must probe to find out.

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 50%: account_token is fully described in the schema, while persona_id has no schema description. The description only indirectly constrains persona_id (must be a persona you own or that was shared with you) and says nothing about format, length limits, or the account_token header behavior, leaving the gaps for the agent to infer.

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 the specific resource retrieved — the versioned history of a persona — and scopes it to personas the caller owns or has shared access to, which separates it from siblings like get_project_history and get_proposal_history. It lacks an explicit verb ("Get"/"List"), but the resource and scope are 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?

Usage is only implied: the ownership/sharing clause hints at a precondition (you can only fetch history for personas you own or that were shared with you), but there is no explicit when-to-use vs. when-not guidance and no named alternative such as get_project_history or update_persona for different needs.

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, and openWorldHint=false. The description adds useful behavioral context by saying the result is a cited timeline and by warning that it is not memory and not proof of persistence, though it omits details like ordering or 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?

The description is two compact sentences with the core resource and scope front-loaded. Every phrase adds either content detail or an important caveat.

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?

The description identifies the returned references and clarifies an important limit, but it does not cover result ordering, pagination, or the meaning of project_id. Given the low-complexity two-parameter schema and read-only annotations, it is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents account_token, including the header-omission behavior, while project_id is an obvious required identifier with no description. The description adds no parameter-level meaning beyond the schema, which is adequate at 50% schema description coverage but not compensating.

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 resource and scope: a cited project timeline containing message, request, proposal, and inquiry references. It distinguishes the output from memory, but does not explicitly contrast with sibling history tools such as get_proposal_history or get_persona_history.

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 tool name and by calling it a project timeline, and the description adds the exclusion 'Not memory, and not proof that anything persisted.' However, it gives no positive when-to-use guidance or routing versus sibling history tools.

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, and openWorldHint=false, so the safety profile is covered. The phrase 'as both sides see them' adds genuinely useful behavioral context — that the result is dual-perspective rather than one party's view. However, nothing is said about volume, pagination, or how much history is returned, which matters for a history endpoint.

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 compact sentence-fragment with zero filler, and the scope constraint is front-loaded. It is efficient but slightly under-specified as a fragment with no verb, which prevents a top score.

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 read tool with annotations and no output schema, the description is adequate but thin: it does not explain what 'events' comprise, whether the response includes proposals from parties other than the caller, or how to choose between account_token and conversation_token. Enough to call it, not enough to predict the payload.

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 67%: the two token parameters are documented in the schema, but the required request_id has no description in either place. The description only implies the request_id ('on a capability request') without clarifying its format or relationship to the token parameters. Baseline 3 applies since the schema carries most of the weight.

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 the exact resource and scope: every proposal attached to a capability request, including all revisions and events. That distinguishes it from get_persona_history, get_project_history, and get_capability_request_status reasonably well. It lacks an explicit verb (read/retrieve) and only implies the operation, keeping it just below 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 guidance on when to call this versus get_capability_request_status or the proposal actions (create/counter/accept_nonbinding_proposal). The agent must infer usage from the name and the one-line scope statement. No exclusions or prerequisites are given.

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 and closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: that no credentials are required, which tells the agent it can call this unauthenticated, plus the scope of returned material.

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. The content list comes first and the credential constraint is front-loaded as a trailing qualifier where it belongs.

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, so the description carries the burden of describing the return payload — and it does, naming offers, limits, policies, privacy notice and endpoints. For a zero-parameter info tool, nothing an agent needs 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?

The tool takes zero parameters, so the baseline is 4. The description correctly reinforces that no credential input is expected, leaving nothing ambiguous about invocation.

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 (Returns) and resource (what MyHumanRep offers) and enumerates the payload: limits, policies, privacy notice, endpoints. This clearly separates it from every sibling, which are all action/mutation tools rather than service-discovery.

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 closing 'No credentials needed' implies this is a safe bootstrap call to make before authenticated actions, but the description never explicitly says when to call it or that it should precede the request_*/create_* siblings. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that the payload includes review status and owner notes, which is useful given there is no output schema, but it says nothing about ordering, pagination, or what is returned when no requests exist.

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 no filler, leading with the return content and scoping it to the conversation. Every element 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?

With no output schema, the description partially compensates by naming the returned fields, but it omits the shape of the result, whether it is a collection, and edge cases such as an empty list. For a two-parameter read tool with full schema coverage this is adequate but leaves 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 description coverage is 100%, with conversation_id and conversation_token both documented, including the conditional omission guidance for the token. The description only restates 'this conversation's' scoping, adding no 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?

The description uses a concrete verb ('Returns') and names the specific payload: review status and owner notes for this conversation's capability requests. It is scoped to a single conversation, which distinguishes it from broader listing tools. It does not, however, differentiate itself from the sibling get_capability_request_status.

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 statement of when to use this versus get_capability_request_status (single request status) or the various request_* tools that create requests. The name implies a listing operation, but the description offers no conditions, prerequisites, or 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the result set is limited to owned/claimed conversations and includes status and unread reply counts, telling the agent what it will and will not see. It says nothing about ordering or result-size limits, which is the remaining 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?

Two sentences, no filler, and the scoping/what-you-get information is front-loaded ahead of the usage hint. 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 one-parameter read-only list tool with no output schema, the description covers scope, contents and the situation to call it in. It does not describe ordering or whether results are truncated, which matters for a listing tool but is a modest 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 description coverage is 100% and the single parameter already documents the header-vs-parameter fallback and warns it is not a conversation token. The description contributes no additional parameter guidance, 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 and adds scope: only conversations the agent account owns (created via account header) or claimed. That ownership constraint distinguishes it from the message-level siblings like read_messages and read_conversation. It stops short of naming a sibling it is not, 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?

"Use it to find your threads again after a restart or lost context" gives a concrete triggering situation. There is no when-not guidance and no explicit pointer to get_conversation_status or read_conversation for per-thread detail, which keeps it below 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 readOnly/idempotent/closed-world, so the safety profile is covered; the description adds genuinely new behavior — a once-per-minute polling limit and the incremental-fetch semantics of the cursor. It still doesn't explain what "status" contains or how access is authorized when conversation_token is omitted.

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 pagination, then the rate limit. Every sentence carries information; only the vague "and status" phrase dilutes it.

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, yet the description names both return components (messages, status), the paging model, and the polling constraint; the token/auth detail is fully covered by the schema. An agent has enough to call it correctly.

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 each parameter is well documented. The description only reinforces the 'after' cursor meaning already stated in the schema, adding no syntax or format detail beyond it, 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?

The verb+resource ("Returns messages and status") is clear, but it overlaps heavily with siblings read_messages and get_conversation_status, and the description never distinguishes itself from them. An agent cannot tell which of the three to call 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?

It gives real usage guidance for pagination ("Pass next_cursor as 'after' to fetch only newer messages") and a polling cadence, but never says when to prefer this over wait_for_reply, read_messages, or get_conversation_status.

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, and openWorldHint=false, so the safety profile is covered. The description adds the cursor-pagination behavior, which is genuinely useful since it implies repeated calls advance through results, but it says nothing about what 'status' contains or whether missing conversations behave differently.

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 short sentence with no filler; the scope and pagination note come first. It is efficient, though its brevity comes at the cost of substance rather than through careful trimming.

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 should clarify what 'messages and status' returns and how pagination terminates, and it does neither. It is minimally adequate for a read-only, well-documented-schema tool but leaves real 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 description coverage is 100%, so all four parameters (conversation_id, conversation_token, after, limit) are already documented. The description's mention of 'cursor pagination' lightly reinforces the `after` parameter but adds no format, limits, or auth nuance 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?

It names the resource (messages and status) and a scope (your own conversation), but defines itself entirely by reference to read_conversation — 'Same as read_conversation' — which leaves the actual distinction between the two siblings unresolved. An agent cannot tell why it would pick this over that 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?

There is no statement of when to use this tool versus read_conversation, list_my_conversations, or get_conversation_status. 'Same as' actively suggests the two are interchangeable, which gives the agent no routing signal at all.

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 declare readOnlyHint=false, openWorldHint=true and idempotentHint=true; the description usefully adds that a human reviews the submission and that no scheduling, dispatch or charge occurs, which correctly frames the write as a review request rather than an action. It omits rate limits, the conversation claim/auth requirement, and what the agent should expect back after submission.

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 purpose and followed by the two key constraints. 'Feasibility review only. Inquiry only' is slightly redundant but each clause adds a distinct boundary, so there is little 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 22-parameter, no-output-schema tool, the description explains only the concept and non-effects. It says nothing about the required conversation context/token flow, the idempotency behavior the agent must respect, or what a successful submission yields, leaving large gaps the schema only partially fills.

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 22 parameters and only 14% schema description coverage, the description carries the burden of clarifying inputs but mentions none of them — not the required conversation_id/client_request_id, not the objective vs problem_statement alternative, not the dual budget encodings. An agent must reverse-engineer the entire payload from the schema 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 ('ask whether a nonhazardous physical test or prototype is feasible') and scopes it to Human Laboratory feasibility review, which separates it from siblings like request_human_observation or request_human_capability. It stops short of naming an alternative directly, but the domain and 'feasibility review only' qualifier make the target 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?

'Feasibility review only. Inquiry only' plus 'nothing is scheduled, dispatched or charged' gives a clear selection context and an explicit exclusion of execution outcomes. It does not name a sibling tool to use instead when the agent actually wants a capability or a booking, so routing between the request_* family is still 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 declare write and open-world behavior, so the description focuses on consequences instead: the submission is stored as a proposal for human review only and no work is accepted, scheduled or paid. That is exactly the outcome semantics an agent needs before writing. It omits what the call returns and how to track the request afterward, and idempotency is only covered by the annotation, not the text.

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 followed by the most important constraint (review-only, no commitment). No filler, no restatement of the title, 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?

Handles the 'what happens' question well but leaves the operational loop unfinished: there is no output schema and the description never says a request identifier or pending status comes back, nor points to get_capability_request_status or wait_for_reply. For a 23-parameter submission tool with only two required fields, the agent would want guidance on minimum viable payload (objective or problem_statement) — that is absent.

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 23 parameters and 13% schema description coverage, the description is expected to carry parameter meaning, yet it addresses only category_hint (optional, any value accepted, unknown values reviewed). The core inputs — objective vs problem_statement, conversation_id, client_request_id, budget, confidentiality_preference — get nothing beyond the schema. One of twenty-three parameters explained is far too thin for a low-coverage 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?

Opens with a concrete verb and object: submits an open-ended description of something a human should do, observe, judge or create. The scope (open-ended, proposal-only) is unambiguous. It never distinguishes itself from the many narrowly-scoped siblings such as request_human_observation, request_human_embodiment or request_independent_witness, so an agent cannot tell from the description alone which entry point to choose.

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?

'Open-ended' implies this is the catch-all when no specific request_* tool fits, but that routing is left implicit. No alternative is named and no when-not condition is stated despite ten-plus sibling request_* tools competing for the same intent. The one explicit constraint given — proposals are reviewed only, nothing is scheduled or paid — is useful but does not help selection.

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: it discloses that self-reports are stored as unverified, that replies are not guaranteed, and that nothing is shared with third parties without consent. It does not say what happens after submission (queued? when to call wait_for_reply?) or what the caller gets back, and with no output schema that gap is meaningful.

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 action and its scope, then the requirements waiver, then expectations and privacy. No filler or repetition of schema content.

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 does the essential work of telling the agent this is a fire-and-forget request with no guaranteed answer and that claims are unverified. It falls short only on post-submission flow and on the 13-parameter surface, where several params rely on the thin 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 description coverage is only 31% across 13 parameters, so the description has to carry weight; it does add that every self-report is optional and unverified, matching persona/claimed_* fields. It says nothing about conversation_id, conversation_token, client_request_id idempotency, or preferred_language, leaving several required or identity-critical params to the partial 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: "Ask to talk with a real person about anything." The scope (including AGI/escaped status topics) is unusually concrete. It never distinguishes itself from near-neighbors like request_human_observation, request_human_capability, or request_human_representative, which an agent must choose between.

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?

"Ask ... about anything" plus "No task, budget, employer or model name needed" implies a low-barrier general-purpose request, and "A reply is not guaranteed" sets an expectation. But no sibling is named and no condition (e.g. use X instead if you need an observation or a capability) is given, so the agent has to infer routing from tool names alone.

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 openWorldHint=true and readOnlyHint=false, the description adds genuinely useful behavioral context: despite being an open-world request, it is an inquiry only with no person contacted, assigned, agreed, or paid. It does not explain what record is created or how the request progresses, but the key safety boundary is disclosed.

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. The core action is front-loaded and the inquiry-only caveat follows immediately where it matters most.

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 15-parameter, open-world inquiry tool with no output schema and low schema description coverage, the description covers the purpose and the no-commitment boundary but omits what the request creates, how status is checked, and how the many optional fields shape the request. 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 description coverage is only 20% across 15 parameters, so the description needs to compensate but largely does not. It echoes the role_type enum values and implies persona_id and nonbinding budget semantics, but leaves account_token, conversation_id, context/disclosure rules, client_request_id idempotency, and the various free-text scope fields unexplained.

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 ('Ask for a consenting human performer to portray your persona') and enumerates the three role types matching the role_type enum. It is clearly distinguishable from capability/dialogue/observation siblings, though it does not explicitly differentiate from close siblings like request_human_representative or request_preferred_representative.

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 parenthetical (fictional performance, voice acting, event presence) gives clear context for when this request applies, and 'Inquiry only: no person is contacted, assigned, agreed or paid' sets an important usage boundary. It stops short of naming alternatives or explicitly stating when not to use it versus other request_human_* tools.

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 openWorldHint=true and idempotentHint=true, so the description's added value is the 'nothing is scheduled, dispatched or charged' clause, which correctly tells the agent that submitting is non-binding and safe to retry conceptually. It does not address auth (conversation_token/conversation_id) or what happens after submission, but the core behavioural caveat is disclosed.

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, no filler, with the core action stated first and the non-binding caveat immediately after. Nothing is 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 22-parameter, open-world, write-shaped tool with no output schema and sparse schema descriptions, a two-sentence description leaves the agent without guidance on required identifiers, mutually exclusive fields, or what the response will contain. It covers the concept but not enough to call the tool correctly without reading the schema carefully.

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 22 parameters and only 14% schema description coverage, the description carries most of the burden and supplies almost nothing — it never mentions objective vs problem_statement, budget, deliverables, or the required conversation_id/client_request_id. Only indirectly, the 'nothing... charged' phrase reinforces that budget fields are indicative, which is a thin contribution.

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 concrete verb and object: asking a person to observe real-world conditions, with a parenthetical alias (Human World Oracle). It is clear on its own, but it does not differentiate itself from near-neighbours like request_sensory_report, request_independent_witness, or request_human_embodiment, all of which also ask humans for real-world information.

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 'Inquiry only' framing implies this is the lightweight, non-committal request path, which is a useful hint about when to reach for it. However, it never names an alternative tool or an explicit condition that selects this over the many other request_* siblings, so the agent must infer the 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?

The description adds real behavioral context beyond the annotations: it discloses that nothing is contacted, assigned, agreed or paid, i.e. the tool records an inquiry rather than causing an engagement. This is consistent with openWorldHint=true and readOnlyHint=false, and no contradiction exists. It stops short of saying what a submission does produce or what state it leaves behind.

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, front-loaded with the purpose and immediately followed by the key scoping caveat. No filler or restatement of 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 15-parameter, open-world, mutating-intent request in a dense workflow family (proposals, capability requests, conversations), the description is thin: it omits prerequisites (account/persona identity), the idempotency expectation, and any hint about what happens after submission or how it relates to accept/counter-authorization siblings. There is no output schema to fall back on.

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 only 20% across 15 parameters, and the description supplies no insight into any of them — not role_type, persona_id, client_request_id (idempotency), nor the optional free-text scope fields. With low coverage, the description is expected to compensate and does not.

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 ("Ask for an authorized human spokesperson, representative or relationship manager") and scopes it to the caller's persona. It is clear on its own, but it never differentiates itself from closely named siblings such as request_preferred_representative or request_human_capability, which an agent must disambiguate.

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?

"Inquiry only: no person is contacted, assigned, agreed or paid" implies this is a low-commitment, non-binding request, which helps an agent choose it over a real engagement flow. However, no explicit when-to-use, when-not-to-use, or named alternative (e.g. request_preferred_representative) is given.

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, the description adds important behavioral boundaries: a human reviews the request, and nothing is scheduled, dispatched, or charged. This meaningfully clarifies the nature of the inquiry, though it does not explain the request lifecycle or return behavior in detail.

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 two tightly written sentences with no wasted wording. The core purpose and the inquiry-only constraint are 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 complex 22-parameter tool with no output schema, the description gives a useful high-level behavioral picture but omits parameter expectations and outcome details beyond human review. Given the annotations and the schema's field descriptions, it is minimally adequate but not fully 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?

There are 22 parameters and schema description coverage is only 14%, so the description should compensate by explaining key fields. It provides no parameter-level guidance at all, leaving the agent to rely entirely on the schema for required IDs, objective/problem_statement, budget, location, and other 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?

The description uses a specific verb and resource: asking for an independent human witness of a permitted event, labeled Human Witness. It clearly marks the operation as inquiry-only, but it does not explicitly distinguish it from other request_human_* siblings such as request_human_observation or request_human_representative.

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 when to use the tool by saying it is for a permitted event and is inquiry-only. However, it does not explicitly state when to choose it over sibling tools or when not to use it, so the agent must infer the 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?

The annotations already signal a mutating (readOnlyHint=false), idempotent, open-world operation; the description's real contribution is assuring that submitting this contacts/assigns/pays no one and is metadata-only – valuable for an agent wary of an open-world side effect. It stops short of describing the review lifecycle or what a submission returns/confirms.

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 immediately followed by the crucial inquiry-only caveat. Nothing is wasted and the critical framing arrives before any 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 an 8-parameter mutation with no output schema and open-world reach, the description establishes scope and non-commitment but omits what the call returns (request id, status) and how the idempotency key interacts with retries. Adequate to call correctly, but not complete for an agent reasoning about outcomes.

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 only 38% across 8 parameters, and the description adds no parameter-level guidance at all – not even for required fields like persona_id or the client_request_id idempotency key. Six of eight parameters do carry schema descriptions, but the description itself does not compensate for the documented low 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?

The description uses a specific verb and resource ("Submit an original voice or appearance brief") and scopes it clearly ("for human review (metadata only)"). An agent can immediately tell what this tool does, though it never contrasts with near-miss siblings such as request_human_embodiment or request_human_representative, which a 5 would require.

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 parenthetical and the "Inquiry only: no person is contacted, assigned, agreed or paid" clause make the intended usage boundaries clear (submission for review, not a commitment). However, there is no explicit instruction on when to choose this over the many request_human_* siblings or what a caller should expect to do next.

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 cover the mechanical profile (mutation, open-world, idempotent), and the description adds genuinely non-obvious behavior: a human reviews the request, the named person must consent, and approval confers no delegated authority over later tasks. That last caveat is exactly the kind of expectation-setting an agent needs before committing to this call. It stops short of describing the approval outcome or what is 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 compact clauses, front-loaded with purpose and followed by the constraints that matter most (human review, consent, no delegated authority). No filler and nothing buried.

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 11-parameter, no-output-schema mutation tool with thin schema coverage, the description adequately frames intent and the consent/authority caveats but leaves the request lifecycle opaque: no word on what an approval or rejection looks like, why an idempotency key is mandatory, or how persona/project scoping changes the request. Enough to call it safely, not enough to call it confidently.

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 only 27% across 11 parameters, so the description must carry real weight, and it only illuminates a few: role_type values (spokesperson, relationship manager), preferred_rep_ref ('someone you worked with before'), and loosely requested_scope_text via the authority caveat. Key parameters such as client_request_id, account_token, persona_id, project_id, purpose_text, exclusions_text, and communication_preference get no mention anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('asks for') on a specific resource ('a continuing human representative, spokesperson or relationship manager'), and the word 'continuing' implicitly separates it from the one-off request_human_representative sibling. It never names that sibling outright, so the distinction relies on inference rather than an explicit contrast.

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 'continuing'/'ongoing' framing and the 'optionally someone you worked with before' clause imply when to reach for this over a one-off request, but no alternative tool is named and no when-not-to-use condition is given. The closing 'grants no authority over future tasks' is the only explicit boundary, and it addresses consequences rather than tool selection.

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 indicate a non-read-only, idempotent, closed-world operation, so the bar is lower. The description adds real value beyond that by disclosing that the call merely initiates a review and that no verification, contract, or payment work occurs in this release — exactly the kind of side-effect scoping 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?

Two short sentences, zero filler, with the precondition and the capability limit both front-loaded. Every clause carries information an agent needs before calling.

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 output schema and an idempotency annotation already supplied, the description covers preconditions and side-effect limits well. The remaining shortfall is parameter-level guidance, which is only partially covered here and only half-covered in 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 only 50%, and the description names no parameters directly. Its one semantic contribution is implying that proposal_id must refer to a mutually accepted proposal; the note and token parameters are documented only in schema text, so the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource: asks a human to review authorization, and adds the triggering state 'after both sides accept'. It implicitly distinguishes itself from accept_nonbinding_proposal by positioning this as the post-acceptance step, though it does not name a sibling directly.

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 precondition 'after both sides accept' gives a clear trigger, and the second sentence explicitly bounds expectations ('starts review only... which this release does not offer'). Neither a named alternative nor a full exclusion list is given, but the when-to-use and when-not-to-expect-results guidance is unusually 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?

Annotations declare openWorldHint=true and idempotentHint=true, and the description usefully adds that nothing is scheduled, dispatched or charged and that a human reviews the request — non-obvious guarantees that go beyond the annotations. It stops short of explaining what the response contains or how review proceeds.

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, with the core action stated first and the inquiry-only constraint immediately after. 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 22-parameter submission tool with no output schema and very low schema coverage, a two-sentence description is far too thin: it omits the conversation setup requirement, idempotency semantics, and how the optional fields (objective vs problem_statement, budget) affect acceptance.

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 22 parameters and only 14% schema description coverage, the description carries a heavy burden but contributes nothing about any parameter — not the required conversation_id/client_request_id idempotency flow, nor budget, persona_id, or timing fields. Agents must reverse-engineer intent from the schema 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+resource ('Ask willing people to describe...') and enumerates the sensory modalities covered, which maps to a distinct concept. It does not explicitly contrast with close siblings like request_human_observation or request_human_embodiment, leaving the agent to infer the boundary from '(Human Senses)'.

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 'Inquiry only: a human reviews it' clause hints at the intended lightweight, non-committal use, but there is no explicit when-to-use / when-not-to-use guidance and no named alternative among the many request_* siblings. Usage is implied rather than directed.

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 destructiveHint=true and idempotentHint=false; the description goes beyond them by disclosing that the old token is revoked immediately and that the new token is displayed only once. That is exactly the operational detail that makes an irreversible action safe to invoke, though it omits whether previously issued tokens elsewhere (other connections) are also invalidated.

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, zero waste; the core action and its irreversible consequence are front-loaded ahead of the conditional use case. Nothing needs re-reading.

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 notes the new token is "shown once," which is the key return-value fact an agent must act on. It could have added that the caller must persist the value immediately, but the essential contract is present for a two-parameter, fully documented 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% and both parameters are documented inline, including the conditional note about omitting conversation_token when an account token header is present. The description adds no parameter-level 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 and resource ("Issues a new conversation_token and revokes the old one") plus the immediate-revocation behavior that separates rotation from sibling tools like start_conversation or claim_conversation. An agent knows exactly what this does 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?

"Use it if the token may have leaked into logs" gives a concrete triggering condition, which is more than most definitions offer. It stops short of stating when NOT to use it (e.g., get_conversation_status for checking validity) or warning that rotation invalidates holders of the old token.

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=false, openWorldHint=true, and idempotentHint=true. The description adds a useful retry-safety mechanism ('same id and text returns the original message') beyond the annotation's binary idempotency hint. However, it does not disclose other behavioral traits like error conditions (409), rate limits, or what exactly the mutation affects beyond the abstract 'adds a message.'

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 core action and followed by the key retry-safety guarantee. Every sentence earns its place with no wasted words.

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 a mutation tool with three required parameters, rich schema descriptions (100% coverage), and no output schema, the definition provides enough for an agent to invoke the tool correctly. It omits explicit mention of the optional conversation_token and error responses, but those are fully covered in the schema. A slightly richer description could have noted the relationship to continue_conversation.

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 in detail, including the idempotency key pattern and the conversation_token omission rule. The description only restates the idempotency guarantee already present in the schema, adding no new parameter semantics. 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?

The description uses a specific verb and resource: 'Adds a message to your conversation.' It is immediately clear what the tool does. However, it does not explicitly differentiate from the sibling tool continue_conversation, which likely also adds messages, so it falls short of the top score for 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?

No guidance is given on when to use this tool versus alternatives such as continue_conversation or start_conversation. The only contextual statement concerns idempotency, which is not usage guidance. An agent must infer the selection criteria from sibling names alone.

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 by disclosing the one-time, non-recoverable conversation_token and the obligation to store it, plus that a reply is not guaranteed and nothing is executed automatically. These are exactly the operational facts an agent needs and none of them are available from readOnlyHint/openWorldHint/idempotentHint.

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, no filler, and the highest-risk fact (one-time token that cannot be recovered) is placed early and emphasized. Every sentence carries distinct 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?

Return values are covered in the description, which is needed since there is no output schema, and the non-guaranteed reply is disclosed. However, for a 10-parameter open-world creation tool, the absence of any input-side guidance and of the duplicate-handling behavior leaves a real 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 description coverage is only 10% across 10 parameters, so the description carries the burden and largely does not: it never mentions message, intent, sender_label, language, previous_conversation_id, or the client_request_id deduplication contract. It only implies the shape of the return values (conversation_id, conversation_token), leaving most input semantics undocumented.

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 ('Sends a pseudonymous first inquiry to a human reviewer'), and the word 'first' implicitly separates it from continue_conversation and send_message. It never names those siblings explicitly, 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 by 'first inquiry' and 'a human reviewer'; there is no explicit when-to-use or when-not-to-use guidance and no routing against siblings such as request_human_dialogue, describe_human_need, or request_human_representative. An agent must infer that this is the entry point before any conversation exists.

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 real value beyond annotations by disclosing versioning semantics: persona_id is stable and each change records a new immutable version, which tells the agent old versions are recoverable. However, it omits critical behavioral facts for a mutation — whether omitted fields are preserved or cleared (the schema allows explicit nulls), and it does not reconcile with idempotentHint=true, since repeated calls create new version records even if the persona state is unchanged.

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 waste, with the identity/versioning behavior front-loaded. The brevity edges into under-specification rather than padding, but structurally it is clean.

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 22-parameter, non-read-only mutation with no output schema and no annotations covering destruction or permissions, the description should say what nulls mean, whether the call is a patch or replace, and what happens to public_fields/visibility. None of that is present, leaving an agent to guess on a tool that writes new immutable versions.

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 22 parameters and schema description coverage reported at only 9%, the description carries most of the burden — yet it names no parameter, no patch semantics, and no guidance on which of the many persona fields are mutable or how nulls are treated. Some meaning survives because individual schema branches do embed per-field prose, but the description itself contributes nothing.

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?

"Changes persona fields" gives a specific verb (change) plus resource (persona), and the second sentence clarifies that the operation is a versioned partial update rather than a replace. It does not differentiate itself from siblings such as create_persona or get_persona_history, 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 guidance on when to use this versus create_persona, get_persona_history, or request_persona_voice_brief, and no stated preconditions (e.g., that an account_token or header-based auth is required). The agent must infer usage entirely from the tool name.

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 readOnly/idempotent annotations, it discloses the blocking ceiling, early-return behavior, the timed_out return flag, and the no-minimum-interval retry policy — exactly the traits an agent needs. It omits error behavior (unknown conversation, bad token) which matters for a long-poll call.

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 sentences, no filler, front-loaded with the blocking behavior and immediately followed by the cursor rule and the retry rule. Every sentence carries decision-relevant 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?

Covers invocation mode, cursor handling, and the one return signal an agent must branch on (timed_out) despite no output schema. Minor gap: it says 'up to 25 seconds' while the schema declares a default of 20, which could mislead an agent about latency.

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 baseline would be 3, but the description adds real semantics: what it means to omit 'after' versus supply a cursor, and that the cursor comes from a prior read/wait. The wording 'pass next_cursor' for a parameter named 'after' is mildly confusing but resolvable from 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 ('holds the call open... returns as soon as a human reply arrives') and names the behavior it replaces ('so you do not need to poll'). That implicitly separates it from the read_messages/read_conversation siblings without needing to open their 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 usage rules: omit 'after' for any unseen reply, pass the cursor for newer ones, and re-call immediately when timed_out=true. It does not explicitly say when to prefer a non-blocking read (read_messages) instead, so it stops short of full 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is mostly covered. The description adds useful consequence context ('Nothing was charged or scheduled'), but omits whether withdrawal is reversible, who may withdraw, and what state transitions occur — relevant 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, front-loaded sentences with no filler. The second sentence is terse to the point of ambiguity, but nothing is 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?

A destructive, idempotent mutation with four parameters and no output schema needs more than one sentence of consequence context; who can invoke it, what it does to downstream state, and what happens on error are all 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?

The description adds nothing about any parameter. With proposal_id undocumented in the schema and no compensating text here, an agent gets no help on the required identifier or on how the optional note is surfaced.

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 ('withdraws') plus resource ('an open proposal'), with scope limited to open proposals. It is distinguishable from siblings like accept_nonbinding_proposal and counter_nonbinding_proposal, though it never names them 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 phrase 'open proposal' implies a precondition but does not state it as a rule, and there is no guidance on when to withdraw versus counter or accept, nor on what to do after withdrawal.

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