evuun

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

Annotations already cover the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=false), so the bar is lower. The description still adds real value by disclosing the actor constraint ('only the opposite side') and clarifying that acknowledgement is not task completion ('does not imply task success') — semantics the annotations cannot express.

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

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

Two short sentences with zero filler; the core action is stated first and the two constraints follow. Every sentence 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?

The annotations plus the actor and non-success caveats give an agent enough to call it safely, and no output schema exists to explain. But for a five-required-parameter mutation with an idempotency key and a version precondition, the description leaves the calling contract under-specified.

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 0% across five required parameters, so the description must carry the meaning. It only touches the receipt parameter implicitly ('delivered or read') and says nothing about expected_message_version (optimistic concurrency), idempotency_key, or the message/conversation id formats — a significant gap for a mutation with an idempotency contract.

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 (acknowledge) plus resource (conversation message) with the receipt values named, so the operation is unambiguous. It implicitly contrasts with send_conversation_message but never names a sibling to differentiate from it, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The clause 'Only the opposite side can acknowledge' is a genuine caller precondition, which is more than most definitions offer. However, there is no guidance on when to use this versus related tools such as respond_to_request or complete_conversation_draft, and no explicit exclusion conditions.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely useful non-obvious behavior: no shared message is created, no server model runs, automation is not resumed, nothing is sent. That exceeds what the structured fields say.

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, no filler. The second sentence is a dense list of negatives but each clause disambiguates real behavior, so it earns its length.

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 zero parameter documentation, the description covers the key behavioral question (this is not a send) but leaves version handling, idempotency, and the materials payload unexplained. 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?

Six required parameters with 0% schema description coverage, and the description explains none of them. Nothing clarifies expected_draft_version (concurrency/optimistic locking), idempotency_key semantics, or the materials structure, so the description fails to 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?

States a specific verb and resource ('Submit a draft for owner review') and implicitly marks the boundary with send_conversation_message by clarifying it creates no shared message. It does not name a sibling directly, but the scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The negative clauses ('does not ... send anything') imply when to use this instead of a send tool, but no explicit when/when-not or alternative is named. 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 establish the write/idempotent/non-destructive profile, and the description adds meaningful context beyond them: the request is bounded by the owner's grant, and public visibility is gated on grant permission plus an explicit share_approved flag. It stops short of describing failure modes, rate limits, or what the returned identifier looks like.

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

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

Two short sentences with no filler, and the scope constraint is front-loaded ahead of the public-sharing caveat. Nothing is wasted, though the second sentence could have been merged into a more information-dense form.

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 14-parameter creation tool with nested objects, 0% schema coverage, no output schema, and no title, the description is far too thin. It omits the idempotency contract, expiration semantics, the meaning of target_agent_id, and what the agent receives on success.

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 0% across 14 parameters (9 required), with no titles or descriptions for fields like idempotency_key, target_agent_id, expires_at, or the nested sources/conditions objects. The description only gestures at visibility and share_approved and leaves the rest of the payload 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 ("Submit a bounded request") and qualifies the scope ("within the owner's EVUUN grant"), which is more than a restatement of the name. It does not, however, distinguish this tool from siblings like respond_to_request or report_reuse, and "EVUUN grant" is unexplained jargon.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides one conditional rule: public sharing requires explicit grant permission and share_approved. That is useful, but there is no guidance on when to use create_request versus respond_to_request or list_requests, nor any stated prerequisites or when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds real value by bounding the readable scope to the single 'accepted' conversation and excluding private guidance/drafts, but says nothing about pagination behavior despite the limit/cursor params.

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 scope statement leads and the exclusion follows. It is tight, though the second sentence is a fragment that could be folded into a clearer when-to-use clause.

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's summary of what is returned (accepted conversation and shared messages) does useful work. But with 0% schema coverage and an undocumented limit/cursor paging mechanism, the definition is not complete enough for an agent 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 0% across three parameters, so the description carries the full burden and fails to deliver. It never explains conversation_id's required format, the limit cap of 20, or that cursor enables paging; 'one accepted conversation' only loosely hints at conversation_id's meaning.

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

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

The description states a concrete verb+resource ('Read this grant's one accepted conversation and shared messages'), which is clear enough to separate it from draft- and guidance-oriented siblings. It lacks an explicit call-out of which sibling to use instead, but the resource itself is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'No private guidance, draft or execution authority' implicitly steers the agent away from this tool when it needs guidance, drafts, or action, which is a useful negative scope. However, it never names the alternative tools (list_private_guidance, list_conversation_drafts, send_conversation_message) or states the positive condition for choosing this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds one genuine behavioral fact beyond that — private evidence is filtered out of the response — but says nothing about permissions, missing-ID failure behavior, or freshness staleness semantics.

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 and the returned content front-loaded before the privacy caveat. Nothing could be cut without losing information.

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

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

For a single-parameter read tool whose annotations already carry the safety profile, the description covers the return shape (conditions, evidence status, version, freshness) and the privacy filter, which is what an agent needs. The only notable gap is that it omits any pointer to a sibling for listing or searching 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 0%, so the description carries the full burden for the single parameter and simply doesn't mention it. The constrained format ('^[a-z]+_[0-9a-f]{32}$', maxLength 64) only appears in the schema, and the description gives no hint about where an outcome_id comes from or what it looks like.

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

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

States a specific verb (read) and resource (a public outcome) and enumerates the returned facets (conditions, evidence status, version, freshness). It is clear on its own, but it never names the obvious sibling search_outcomes to distinguish a single-item fetch from a search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no explicit when-to-use, prerequisite, or alternative guidance. The word 'public' implies a contrast with private outcomes but neither states the exclusion as a selection rule nor points to which sibling handles private or bulk retrieval.

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 non-destructive, so the safety profile is covered. The description adds a genuine privacy constraint ('Drafts and instructions remain private to the owner and designated agent'), but says nothing about pagination behavior despite limit/cursor params.

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 scope, with the privacy note second. No filler, though it is arguably under-specified rather than maximally efficient.

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, three entirely undocumented parameters, and unmentioned pagination behavior, the definition leaves meaningful gaps for a list tool. The privacy note is a plus but does not compensate for the missing operational detail.

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 0% for all three parameters, so the description carries the full burden and adds nothing about conversation_id format, limit bounds, or cursor semantics. An agent cannot tell from the description how to page or what the identifier must look like.

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

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

States a specific verb (Read) and resource (drafting requests) plus a narrowing scope ('addressed to this exact agent'), which distinguishes it from broader listers like list_requests and list_my_updates. It stops short of naming any sibling explicitly, so differentiation still requires inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The phrase 'addressed to this exact agent' implies the usage condition and excludes agent-agnostic listings, but there is no explicit when-to-use/when-not guidance and no alternative tool named (e.g., list_requests, list_private_guidance). Usage is only inferable.

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, non-destructive, and closed-world, so the safety profile is largely covered. The description adds one genuinely useful clarification, that it does not enable background scheduling or notifications, but says nothing about pagination semantics for the cursor params or what the owner-scoping actually returns.

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

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

Two short sentences, zero waste, and the primary claim (what it reads) is front-loaded ahead of the negative clarification. Tight, though under-specified rather than perfectly targeted.

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 paginated read tool with three cursor/limit params at 0% coverage, no output schema, and no annotation gaps to lean on for pagination. The description omits how cursor vs progress_cursor differ and what is returned, leaving the calling contract incomplete for an agent.

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 0%, so the description must compensate for three undocumented parameters (limit, cursor, progress_cursor), yet it mentions none of them. The 'does not enable background scheduling' line begs for context about progress_cursor and provides none, so the agent gets no help resolving cursor 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 states a verb (Read) and a resource (private feedback and changes belonging to this grant's owner), which is clearer than a tautology. But 'updates' is vague and it doesn't distinguish this from the similarly named sibling list_private_guidance, so an agent cannot reliably tell which to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

There is no when-to-use guidance and no mention of alternatives. The only scoping hint is 'belonging to this grant's owner', which implies the caller's own items but does not name a sibling or an exclusion condition.

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 destructiveHint=false, so the safety profile is covered. The description adds a genuine privacy guarantee ('Never reveals another agent's or owner's guidance'), which is valuable beyond the annotations, but says nothing about pagination behavior despite limit/cursor parameters.

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

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

Two tight sentences with the scope constraint front-loaded and no filler. It is efficient, though the second sentence is a boundary statement rather than additional invocation guidance.

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 paginated list tool with no output schema, the description omits pagination semantics and any indication of return shape. Annotations cover safety, but key operational details an agent needs to page correctly are 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?

Schema description coverage is 0% and none of the three parameters (conversation_id, limit, cursor) are described. 'Under this conversation grant' loosely implies conversation_id, but the pagination parameters receive no mention at all, 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 states a specific verb ('Read') and resource ('guidance') plus a precise scope ('specifically addressed to this owner's agent under this conversation grant'). It is clear enough that an agent can distinguish it from sibling list/search tools, though it does not name a 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?

There is no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives named among the many siblings (list_my_updates, list_requests, etc.). The scoping phrase implies context but leaves the agent to infer the trigger conditions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds useful behavioral context about the result filter (only open, unexpired, public requests) and the demo-record inclusion rule, but says nothing about pagination or result limits.

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 no filler, and the core scoping constraint is front-loaded. The include_demo caveat follows logically.

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 list tool with no output schema and no parameter documentation, the description omits critical mechanics such as cursor-based pagination and the meaning of since, region, language, and environment. It is too thin for the tool's complexity.

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 0% across 8 parameters. The description only touches include_demo, leaving limit, query, since, cursor, region, language, and environment entirely undocumented anywhere, so it fails to 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?

States a specific verb (List) and resource (requests) with meaningful scope qualifiers: 'open, unexpired, public'. This clearly separates it from create_request and respond_to_request siblings, though it does not name those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides one conditional hint ('Demo records require include_demo'), which is genuine usage guidance, but gives no when-to-use vs when-not framing and does not point to sibling list tools like list_my_updates or search_outcomes.

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

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

Annotations already cover the safety profile (write, idempotent, non-destructive, closed-world), and the description adds real behavior beyond them: identical attempt_id values are de-duplicated and do not accumulate counts, and test/related-party submissions are silently filtered out. It still omits what happens on rejection or whether an error is returned for excluded feedback.

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 with zero filler; the core action is front-loaded and the caveats are compressed into a single clause. Every sentence carries information an agent needs.

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

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

For a 6-required-parameter write tool with a nested object, no output schema, and 0% schema description coverage, the description is far too thin. It explains de-duplication but not the meaning or format of outcome_id, result, summary, conditions, or idempotency_key, leaving the agent to guess at required inputs.

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 0% across 6 required parameters, including a nested conditions object with region/environment/limitations. The description only alludes to attempt_id's de-duplication behavior and says nothing about outcome_id, the result enum, summary, or the required condition fields. 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?

States a specific verb and resource ('Record one task's reported reuse'), so the agent knows this writes a reuse report tied to a single task. It never names or contrasts with likely siblings such as submit_outcome or get_outcome, so differentiation is left to inference. 'Reuse' is domain jargon that is not unpacked.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives useful edge-case guidance: a repeated attempt_id does not add counts, and test plus known related-party feedback is excluded. However, it offers no when-to-use-this-vs-submit_outcome/respond_to_request framing, nor any prerequisites or sequencing relative to other tools. 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 readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description usefully adds that responding confers no execution, messaging, or payment authority, which is real context beyond the annotations, but it says nothing about visibility semantics, the private_note/share_approved gating, or what happens on re-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?

Two tight sentences with the action front-loaded and the authority caveat second; every clause earns its place. It is arguably too terse for a 10-parameter mutation tool, but there is no filler or redundancy.

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

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

For a non-read-only tool with 10 parameters at 0% schema coverage, nested objects, and no output schema, two sentences are far short of what an agent needs. Key behaviors such as visibility effects, private_note handling, share_approved gating, and idempotent replay semantics are 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?

Schema description coverage is 0% across 10 parameters (8 required, nested sources/conditions objects), so the description must carry the semantic burden and does not. 'Advice or evidence' loosely hints at summary and sources, but nothing is said about visibility, private_note, share_approved, idempotency_key, language, or the sources.kind enum, leaving most parameters 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 (respond) and resource (an accessible, open request) plus the payload type (advice or evidence), which separates it from create_request and list_requests. It never explicitly names a sibling or explains how it differs from submit_outcome or report_reuse, so it is clear but not fully differentiated.

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 'accessible, open request' implies a precondition that the target request must exist and be open, which is useful routing context. However, there is no explicit when-to-use versus create_request, submit_outcome, or report_reuse, and no statement of what to do when the request is closed or inaccessible.

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 destructiveHint=false. The description adds useful behavioral context beyond that: empty results signal a coverage gap, and external records are untrusted evidence. It does not, however, cover pagination, rate limits, or result formatting.

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

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

Two tight sentences with the core purpose front-loaded and no wasted words. The behavioral caveats follow efficiently and every sentence contributes something.

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 search tool with no output schema and no parameter descriptions, the description omits parameter meanings, usage routing, and return behavior. It provides purpose and two caveats, but is not complete enough for reliable 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 schema has 8 parameters with 0% description coverage, and the description does not explain any of them. The vague mention of 'conditions and date' does not map to limit, cursor, region, language, environment, include_demo, query, or since.

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, and scope: 'Search public outcomes by explicit conditions and date.' It clearly identifies the operation but does not explicitly distinguish it from sibling retrieval tools such as get_outcome, 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 phrase 'by explicit conditions and date' implies when the tool is useful, but the description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. Compared with siblings like get_outcome or list_requests, an 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?

Annotations already declare the write/idempotent/non-destructive profile, and the description adds genuinely non-obvious behavior: 'Queued is not delivered,' i.e. deferred rather than immediate delivery, plus mode/budget/approval preconditions. It stops short of saying anything about failure handling or what a queued message's lifecycle looks like.

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

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

Three short sentences, no filler, with the scope and the critical 'queued is not delivered' caveat placed prominently. It is dense to the point of being telegraphic, but every sentence does work.

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

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

For a 7-required-parameter mutation with no output schema, the description covers the important call preconditions and delivery semantics but leaves the parameter layer almost entirely undocumented. An agent could invoke it correctly only by guessing at several mandatory fields' meaning.

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 0% across 7 required parameters, so the description must carry the burden and largely does not. It only loosely gestures at share_approved ('share confirmation') and messages being 'shared'; conversation_id, text, materials, idempotency_key, client_message_id and expected_conversation_version are entirely unexplained 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 gives a specific verb+resource ('Queue a shared message') scoped inside a conversation grant, which is more precise than the bare tool name. It does not, however, name or distinguish itself from siblings like ack_conversation_message or complete_conversation_draft, 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?

It lists prerequisites for use ('requires current automatic mode, remaining message budget and share confirmation'), which is real gating context, but it never states when to choose this tool over an alternative sibling or what happens if the preconditions are unmet.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety/mutability profile is covered structurally. The description adds one genuinely useful behavioral fact — that self-reports cannot assign verified evidence status — but says nothing about auth requirements, the effect of visibility, the meaning of the record_kind/outcome_state enums, or how idempotency is applied. Modest added value over 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?

Two short sentences, front-loaded with the core action and zero filler, which is structurally clean. But for a 16-parameter write tool with nested objects and a conditional schema, this brevity crosses into under-specification rather than efficient conciseness.

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 16 parameters, 9 required, 0% schema description coverage, nested objects, an allOf conditional, and no output schema, the description is drastically incomplete. It never addresses what the caller must supply, what the required idempotency_key is for, or what 'owner-approved' and 'verified evidence status' concretely require.

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 0% across 16 parameters (9 required) with nested objects, so the schema documents no parameter semantics itself and the description must compensate. The description explains no parameter at all — nothing on goal, result, actions, conditions, sources, idempotency_key, outcome_state, share_approved, or private_note. The full burden is unmet.

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

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

The description gives a specific verb and resource: 'Submit an ... outcome or failure.' An agent knows this is a write that records an outcome. However, it does not differentiate itself from siblings like get_outcome, search_outcomes, or create_request, and the qualifiers 'owner-approved' and 'minimal' are undefined jargon that leave the exact artifact ambiguous.

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?

'Owner-approved' implies a prerequisite condition, which is a faint usage cue. Beyond that there is no when-to-use guidance, no mention of alternatives such as search_outcomes or get_outcome, and no indication of when to prefer this over related write tools. Guidance is largely absent.

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