Meta Council

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description is fully consistent (no contradiction). Beyond that, it adds rich procedural detail: which credential fields are withheld by name, the ownership-reflection derivation of served tables, artifact metadata behavior, the coverage-block contract, and auth requirements. This is exactly the kind of context that prevents a caller from misinterpreting the result set.

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?

Eight dense, information-carrying sentences with zero filler. It front-loads the core operation, then flows logically through exclusions, security withholdings, paging behavior, and non-goals. At ~250 words it's long, but every sentence carries unique weight — the one knock is that an agent must read to the very end to find the auth requirement ('Requires authentication and the account:export scope').

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

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

For a security-sensitive, paginated export tool with two parameters and a rich output schema, the description covers all bases: data scope, credential redaction, explicit exclusions with a documentation pointer, the paging protocol, and disclaimers about non-equivalence to erasure or compliance. The only marginal omission — rate limits or response sizes beyond rows_per_model — doesn't rise to a missing gap. A 5.

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 per rubric the baseline is 3. The description adds real value by explaining the truncation contract — 'narrow to one model and raise rows_per_model rather than re-reading everything' — which clarifies both the `models` and `rows_per_model` parameters' operational meaning. It doesn't add syntax details for the `models` enum values, so it's a strong 4, not a 5.

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?

Excellent verb+resource clarity: 'Export this account's own data across every table the account owns' is specific and immediately scopes the operation. The description even explains the envelope format and table derivation. However, while it's clear about what sets this tool apart from generic lookups, it never explicitly distinguishes it from siblings like audit_export — the rubric's 5 requires exactly that kind of explicit sibling differentiation.

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

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

The description gives strong paging and execution guidance: 'Bounded rather than streamed: each model reports truncated and the envelope reports complete, so narrow to one model and raise rows_per_model rather than re-reading everything.' It also clearly states what this is NOT for ('not an erasure request and not a claim of regulatory compliance') and points to docs for exclusions. It stops short of naming alternative tools for specific scenarios, so a 4.

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 valuable behavioral context beyond the annotations: it mentions that totals are recomputed automatically and that the operation is blocked once the invoice is paid or void. Since annotations are all false and don't provide this level of detail, the description enriches the agent's understanding of the tool's side effects and constraints.

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 extremely concise: two sentences that convey the essential purpose, behavior, and a key restriction. It is front-loaded with the core action and avoids any unnecessary words or repetition of schema details.

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 relatively simple tool with an output schema, the description covers the main points: what it does, when it's allowed, and a key automatic behavior. It doesn't explain the response format, but that's covered by the output schema. It could mention error scenarios beyond the paid/void block, but overall it is complete enough for an agent to invoke 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 input schema has low description coverage (only quantity has a default note). The description adds some meaning by labeling the line item as 'billable' and mentioning unit_price implicitly, but it does not explicitly explain the purpose of each parameter. It confirms that invoice_id is required, which helps, but the semantics of description, unit_price, and quantity are left mostly to the schema's names and types.

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 tool's function: adding a billable line item to a draft or sent invoice. It distinguishes this from sibling tools like create_invoice and update_invoice by specifying the specific action (add line item) and the target resource (existing invoice). The scope is further clarified with 'draft or sent invoice'.

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 when to use this tool: when you need to add a line item to an existing invoice, as opposed to creating or updating the invoice itself. It does not explicitly name alternative tools, but the context is clear from the sibling list. It also provides a clear exclusion ('Blocked once paid/void'), which helps agents understand when not to use it.

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 indicate a write operation (readOnlyHint=false) but no destructive hint. Description adds 'Provenance is stamped source="agent" server-side' and 'Requires authentication,' providing behavioral context beyond annotations. No contradictions.

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, each earning its place: action, return value, and important behavioral notes. Front-loaded with the main action.

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 creation tool with an output schema, the description is complete: it explains what is created, the return value, side effects (no email sent), and auth requirement. No gaps.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description adds minimal parameter-specific detail, but the schema fully covers semantics, so a baseline score of 3 is appropriate.

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

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

Description clearly states 'Add a single lead to the authenticated user's outreach book.' This is a specific verb-resource combination, and it distinguishes from siblings like search_outreach_leads and update_outreach_lead_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?

The description indicates when to use it: adding a lead. It mentions 'Does not send any email' and 'Requires authentication,' providing clear context. It does not explicitly state when not to use it, but the purpose is unambiguous.

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, indicating mutation. The description adds that the pipeline continues, which implies forward progress but lacks details on side effects (e.g., irreversibility). The authentication requirement is noted.

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 that are front-loaded: first sentence states purpose, second provides usage hint. No unnecessary information.

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

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

Given the output schema exists, the description adequately covers purpose, parameter context, and authentication. It does not explicitly address error states (e.g., session not awaiting checkpoint), but the schema covers that.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining where to get session_id and that action is a 'checkpoint decision', enhancing meaning 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?

The description clearly states the verb 'advance', the resource 'workflow', and the specific action 'approve or reject the paused step'. It distinguishes from sibling approval tools (e.g., approve_content_asset) by specifying the workflow checkpoint context.

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

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

It explicitly tells where to get the session id ('from run_workflow / get_workflow_session') and requires authentication. However, it does not explicitly mention when not to use this tool (e.g., for content approvals) or list 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?

Beyond the annotations (which are all false), the description adds that the tool 'requires consulting:approve' and 'never publishes or sends it', clarifying that it is a mutation but with limited external side effects. However, it could further detail what happens upon approval (e.g., status changes).

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 sentences, front-loaded with the core purpose, and includes essential constraints without extraneous text. Every sentence adds value.

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 three required parameters with no schema descriptions, the description fails to provide necessary guidance on how to use them effectively. Although an output schema exists, the lack of parameter semantics leaves the tool incomplete for an agent to invoke 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 input schema has 0% description coverage, and the tool description does not explain any of the three required parameters (deliverable_id, expected_version, expected_content_hash). The agent is left guessing about their purpose and format beyond what the schema provides, which is insufficient.

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 'Approve' and the resource 'one submitted internal deliverable', and it distinguishes from sibling tools like 'approve_consulting_document_revision' and 'submit_consulting_deliverable' as it explicitly says 'submitted internal deliverable' and 'never publishes or sends it'.

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 for internal approval but does not explicitly state when to use it versus alternatives. It mentions the required permission 'consulting:approve' but does not name alternative tools or conditions for when not to use 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?

The description adds valuable context beyond annotations: the tool 'locks' the revision (implying immutability) and requires a specific scope. Annotations already indicate it's not read-only (false) but don't cover locking or scope, so the description enriches transparency.

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 concise sentences with no redundancy. Every sentence adds essential information: action and constraint.

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 omits details about parameter semantics, state changes after approval (e.g., immutability implications), and return behavior despite the presence of an output schema. For a mutation tool with 3 undocumented required parameters, this is insufficient.

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 0% and the description does not explain any parameter. Critical parameters like expected_content_hash (a 64-char hex) lack meaning, leaving the agent to guess their purpose.

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 'Approve and lock' and the resource 'one exact proposal/SOW revision', differentiating it from siblings like approve_consulting_deliverable or create_consulting_document_revision.

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

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

The description provides a prerequisite ('requires the separate consulting:approve scope') and a negative constraint ('never publishes or shares it'), offering clear context. However, it lacks explicit guidance on when to use this tool versus alternatives like approve_consulting_deliverable.

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 are minimal (no readOnlyHint, destructiveHint, etc.), so the description carries the burden. It discloses that the tool requires specific authorization and attests to a content hash, implying a write operation with verification. However, it does not explain post-approval effects (e.g., status change, workflow progression).

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 well-structured sentences: first states the action and its precise meaning, second specifies the authorization requirement. No wasted words, and critical information is front-loaded.

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

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

Given low complexity (2 params, 1 required) and the presence of an output schema, the description covers the core action and auth but omits explanation for the 'notes' parameter. This leaves a gap for an agent: why would notes be provided, and what is their impact? The description is 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?

Schema description coverage is 50% (only asset_id described). The description adds that asset_id refers to 'a submitted owned revision', which aligns with the schema hint 'Full UUID from the matching list tool'. The 'notes' parameter lacks any description, leaving the agent uncertain about its purpose.

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?

Clearly states the action 'Approve' with the specific resource 'content asset', and distinguishes from siblings like 'reject_content_asset' by mentioning 'submitted owned revision' and 'exact content hash'. The permission clarification further differentiates it from other approve tools.

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

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

Explicitly specifies the required permission 'marketing:approve, separate from draft authority', guiding the agent on when to use this tool. However, it does not provide direct exclusions or alternatives for cases where the user lacks permission.

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 states 'Idempotent' while annotations set idempotentHint: false, which is a direct contradiction. This undermines trust in the description's behavioral claims. Although it adds useful details like team visibility and auth scope, the contradiction forces a low score.

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 dense paragraph but every sentence adds value (purpose, idempotency, team effect, auth). It is front-loaded with the main action and remains readable, though slightly longer than necessary.

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 is fairly complete, covering idempotency, reversibility, team sharing, and auth. However, the idempotency contradiction creates confusion, and it does not mention what happens if the view is not owned by the caller (e.g., error behavior). This leaves gaps given the available annotations.

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 already fully documents view_id with a description ('The view's id, from list_saved_views.'), and the description does not add any additional parameter-specific meaning. Baseline 3 applies because schema coverage is 100%.

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

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

The description uses a clear verb+resource ('Retire ... saved views') and precisely states the effect: drops from default listing and execute_saved_view refuses it, but definition is kept. It explicitly distinguishes from delete_saved_view and mentions restore_saved_view, making the purpose 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?

It gives explicit usage guidance by saying 'Prefer this over delete_saved_view' and clarifies the scope ('YOUR OWN', team visibility). It also states when not to use (for destructive deletion) and covers idempotency, which helps the agent choose correctly.

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

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

Beyond the read-only and idempotent annotations, the description discloses critical behaviors: generated research is disabled, returned records do not prove citation identity/relevance/authority/coverage, answer prose is withheld, and authentication (legal:run) plus exact schema version requirements are needed. This is rich behavioral context that helps the agent understand side effects and limitations.

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 dense, run-on paragraph with many technical caveats and clauses. While information-dense, it lacks clear structure and is not concise. The first sentence does state the purpose, but the rest becomes a wall of text, making it harder for an agent to quickly parse the essential behavioral constraints.

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 is comprehensive given the tool's complexity: it covers the functional modes, authentication requirements, the disabled generation path, the nature of returned records, the output schema, and the non-advice disclaimer. Since an output schema exists, it needn't describe return values in detail, and this description fills all necessary 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?

With 100% schema coverage, a baseline of 3 is appropriate. The description adds value by explaining that research_mode='themis' is effectively non-functional and that the output plan's routes are 'planned_not_run', which clarifies parameter intent beyond the schema. This extra semantics nudges the score to 4.

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 tool's function: 'Request fixed legacy Themis source/citation records and attach a proposed Laws & Regulations agent/source/synthesis plan' which is a specific verb+resource+scope. It distinguishes itself from sibling tools by being the only legal research tool, and explicitly mentions the output type (legal_evidence_graph/v1).

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

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

The description provides clear context on usage: it notes that 'check_law' mode uses fixed legacy provider-record retrieval, while 'themis' generated mode is disabled due to the missing manifest verifier. It also states 'Automated research only, not legal advice,' which clarifies the tool's intended scope. Although it doesn't name alternative tools, none of the siblings are legal-related, so the guidance is sufficient.

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 claims the tool is 'Idempotent', but the annotations set idempotentHint=false. This is a direct contradiction, which misleads the AI agent about the tool's behavior. The description does add value by stating the return value and authentication requirement, but the contradiction overrides.

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 sentences, front-loaded with the purpose, and includes key facts (return count, idempotency, authentication). No superfluous 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?

Given the tool's low complexity (2 params, simple assignment), the description covers usage constraints, return value, and idempotency. The existence of an output schema and good parameter descriptions contribute to completeness, though error conditions are not mentioned.

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 have clear descriptions referencing source tools. The description adds the ownership constraint ('both must be owned by the caller'), which provides additional meaning 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?

The description clearly states the action ('Assign'), the resources ('leads to campaigns'), and constraints ('both must be owned by the caller'). It distinguishes this tool from siblings like create_outreach_campaign or add_outreach_lead by specifying the assignment of existing leads to existing campaigns.

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

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

The description provides useful context: leads and campaigns must be owned by the caller, and the operation is idempotent. However, it does not explicitly state when to use this tool versus alternatives like add_outreach_lead or update_outreach_lead_status, leaving some ambiguity.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds: metadata only (no content returned), coverage block on responses lists which actions are exportable, requires auth and audit:read scope. It doesn't delve into error cases or rate limits, but the annotations cover safety profile; a 4 is appropriate for the extra security and data-scope context.

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

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

The description is a single dense block that front-loads the purpose and data scope, then adds filter/pagination info, then coverage caveat and auth. Every sentence earns its place; 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?

Given the tool's moderate complexity (5 params, pagination, auth, coverage limits) and generous schema coverage plus output schema present, the description fully covers purpose, scope, exclusions, and prerequisites. It is complete enough for an agent to select and invoke 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%, so the schema already documents all 5 params including examples. The description adds meaning by connecting the pattern: 'page forward with the cursor each response returns' and maps after_id to next_cursor from the previous page. It doesn't add new syntax details beyond schema but reinforces the pagination model.

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 precisely what the tool does: exports this workspace's own agent-action audit trail as structured events, oldest first. It also names the sibling tool 'get_workspace_metrics' as the alternative for platform metrics, and differentiates from 'get_meta_council_platform_metrics' and other metric lists by focusing on the audit trail.

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 explicitly says when to use it: for SIEM loading, and notes that it covers a 'documented subset of platform activity rather than every action', pointing to docs/WORKSPACE_AUDIT_EXPORT.md. It also clarifies the alternative: 'To get overall platform usage metrics, use get_workspace_metrics instead.'

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so agent knows it's safe and non-destructive. Description adds only 'Requires authentication', which is minor. No additional behavioral traits (e.g., rate limits, data freshness) are disclosed, but the description does not contradict 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 sentences, no fluff. Key information is front-loaded: first sentence explains purpose, second adds authentication requirement. Every word 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?

Given low complexity (one param, has output schema, annotations complete), the description is sufficient. It lists the metrics returned, though it could explicitly note that output schema documents the structure. Minor gap: no mention of time range or campaign status requirements, but not critical for a stats 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 has 100% coverage: one parameter with description 'Campaign UUID (from list_outreach_campaigns).' Description reinforces that it's for one campaign but adds no new parameter details. 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?

Description clearly states verb ('Pipeline-stage breakdown') and resource ('one outreach campaign'), listing specific metrics (total/sent/active/won/lost, reply rate, per-stage lead counts). Distinguishes from siblings like 'list_outreach_campaigns' (which lists campaigns) and 'outreach_analytics' (likely broader).

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?

Description mentions 'Requires authentication' and implies use for a single campaign, but does not explicitly state when to use this vs alternatives like 'outreach_analytics' or 'get_deal_health'. Still, context is clear enough for an agent to infer appropriate usage.

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 discloses that marking a task done stamps the completion time, and reopening clears it. This adds behavioral context beyond the annotations (which only indicate it's not read-only, not destructive, and not idempotent). It does not specify authorization scope (e.g., only the caller's tasks) or potential side effects, but it is sufficient for a simple 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?

The description is two sentences long, front-loaded with the primary action, and every word provides value. It is efficient and avoids redundancy 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 simple tool with two parameters and an output schema (present but not shown), the description covers the essential behavior and parameter usage. It does not explain the output format, but that is handled by the output schema. Minor gap: it does not state that the tool only works on the caller's tasks, but this is implicit in 'caller's sales tasks.'

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 50% (only 'done' has a description in the schema). The tool description reiterates that activity_id is required and done defaults true, but adds no new parameter-level detail. The description does clarify the boolean usage, but does not fully compensate for the undocumented activity_id parameter.

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 tool's action (marking a sales task done or reopening it) and the specific resource (caller's sales tasks/activities). It uses a specific verb and resource, and the purpose is distinct from sibling tools which handle creation, updates, or other specific operations.

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 when to use: to complete or reopen a specific sales task. However, it does not explicitly state when not to use or suggest alternatives, such as logging a deal activity or updating outreach lead status. The purpose is self-evident, so no major gap.

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 indicate a non-read-only, non-destructive operation, and the description aligns with that by saying 'Create a draft invoice.' It adds useful context beyond the annotations: the invoice starts with one line item using the deal's amount, and client_name defaults from the deal's company/title. However, it does not disclose potential side effects on the deal (e.g., marking it as invoiced) or clarify how tax_rate, due_date, and other options affect the invoice.

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 concise sentences that front-load the core action and the most important default. Every word earns its place with no redundancy or 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?

The description conveys the essential purpose and a key default, but for a 7-parameter tool with low schema coverage, it leaves significant gaps: it does not explain most parameters, prerequisites (e.g., the deal must exist and be owned by the caller), or edge cases (e.g., repeated calls creating multiple drafts). Since an output schema exists, return values are covered elsewhere, but the overall package is only minimally viable.

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 29%, so the tool description must compensate for the undocumented parameters. It only clarifies deal_id (required) and client_name (defaulted from the deal), leaving notes, due_date, tax_rate, client_email, and payment_terms unexplained. This is insufficient for reliable parameter selection and usage.

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

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

The description clearly states a specific verb ('Create') and resource ('a draft invoice from one of the caller's deals'), making the tool's purpose distinct. It also specifies a key behavior ('one line item for the deal's amount') and a default behavior for client_name, which differentiates it from generic invoice creation tools like create_invoice.

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 when to use the tool—when you want to create a draft invoice from a specific deal—by emphasizing deal_id is required. However, it provides no explicit exclusions or alternatives, such as noting that create_invoice is intended for blank invoices or that add_invoice_line_item handles additional line items. This lack of comparative guidance is a gap.

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 indicate it is a write operation (readOnlyHint=false). The description adds critical behavioral context: it advances the lead to the deal stage and never downgrades closed leads, which goes 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 extremely concise (two sentences) with no wasted words. It front-loads the core action and constraint, then provides a parameter hint. Every sentence adds value.

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 9 parameters and one required, the description covers the essential behavior and links to create_deal for optional fields. The output schema exists but is not needed in the description. It is sufficiently complete for an agent to understand and use the 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 low (11%), so the description needs to compensate. It states 'Optional deal fields mirror create_deal', which directs the agent to another tool's schema, and mentions lead_id is required. However, individual parameters like notes, stage, etc., are not described, leaving some ambiguity.

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 specific verb 'convert' and resource 'owned outreach lead into a deal', distinguishing it from sibling tools like create_deal and add_outreach_lead by specifying the conversion action and ownership condition.

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

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

The description provides a clear condition ('never downgrading an already-closed lead') and references create_deal for optional fields, offering context on when to use the tool. However, it does not explicitly state when not to use it or compare to 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?

Beyond the minimal annotations, the description discloses critical behavioral traits: silent row drops with no partial-loss error, suffix-based routing with conflicting allowlists, duplicate-header last-copy semantics, European decimal parsing, and the fact that a completed run does not guarantee every row was read. It also clarifies safety boundaries, such as not moving money or sending data externally.

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 extremely long and repetitive: duplicate-header warnings appear twice ('A second Amount REPLACES the figure' in two separate paragraphs), and the same 'Date,Description,Amount,Type' instruction is repeated. It lacks structural organization such as headings or sections, making it difficult to scan despite the front-loaded purpose statement.

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 the tool's complexity, the description is remarkably complete. It covers accepted file types, routing logic, parsing hazards, failure modes (source_left_no_trace, EmailIngestError), return semantics, and operational constraints (one active ingest per owner). With an output schema present, the description does not need to detail return values further.

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

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

Although schema description coverage is 100%, the description adds substantial meaning beyond the schema. It explains the canonical CSV format for documents.content, the suffix-specific parsing behavior, the partial business gate semantics of context_text, the entity/tax-year naming convention for name, and the return semantics (total counts classified spend only).

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

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

The description opens with a specific verb+resource: 'Analyze supported textual accounting records ... and create a private, encrypted audit run owned by the caller.' It clearly distinguishes the tool from siblings by stating it returns estimates for review only and does not file taxes, move money, or send data to an external accounting service.

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 explicit when-to-use and when-not-to-use guidance: 'Submit prepared rows, not raw document text,' 'Scope each run to one entity and one tax year,' and 'Submit runs one at a time.' It also names a specific alternative for residuals: 'Use preview_accounting_ticket_sync to turn those residuals into reviewable work.'

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 it's a write (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds 'account-private' but does not disclose any additional behavioral traits like idempotency, side effects, or error conditions.

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 short sentence, which is concise but overly terse. It lacks necessary details about parameters and behavior, making it under-specified rather than efficiently compact.

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 complexity (7 parameters, many optional, output schema exists), the description is vastly incomplete. It fails to explain the purpose of parameters, success criteria, or how it relates to sibling tools like 'create_consulting_engagement'.

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 0% schema description coverage, the description must compensate but does not. No parameters are mentioned or explained, leaving the agent without guidance on how to fill in the 7 fields beyond the input schema.

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

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

The description clearly states the action ('Create') and the resource ('consulting client'), and the 'account-private' qualifier hints at scope. However, it does not explicitly distinguish from the 'update_consulting_client' sibling, but the verb alone makes it a distinct creation tool.

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

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

The description offers no guidance on when to use this tool versus alternatives (e.g., for creating vs. updating clients, or vs. creating engagements). No usage context, prerequisites, or exclusions are provided.

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 indicate it's a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds 'internal draft' but does not disclose idempotency (hint=false) or other behavioral traits such as state changes or required permissions.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose. While concise, it could benefit from incorporating key parameter or behavioral details without becoming verbose.

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 complexity (6 parameters, 3 required, output schema exists) and the large number of sibling tools, the description is too minimal. It does not explain how to use parameters like engagement_id or what constitutes an 'internal draft deliverable'.

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 the description provides no explanation of parameters such as 'key', 'title', 'due_date', or 'milestone_id'. The agent must rely solely on the schema, which lacks semantic context.

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 'Create' and the object 'internal draft deliverable', with the context 'on an owned engagement'. It distinguishes from sibling tools that deal with approving or updating deliverables.

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 provided on when to use this tool versus alternatives like 'approve_consulting_deliverable' or 'update_consulting_deliverable'. The user must infer usage from the tool's name 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?

Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) already signal it's a non-read, non-idempotent mutation. The description adds 'revision-safe,' implying versioning, but does not disclose concurrency behavior (e.g., optimistic locking via expected_latest_revision), permissions, or limits. It provides some value beyond annotations but remains vague.

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, focused sentence with no redundant information. It efficiently conveys the core purpose without extraneous words. Every part 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?

Given the tool has 5 parameters (0% schema coverage), no behavioral annotations beyond basic mutation hints, and an output schema (but not described), the description is incomplete. It omits critical context: the expected_latest_revision parameter for conflict detection, what 'owned engagement' implies (permissions), and typical use cases. The agent lacks sufficient information to invoke the tool reliably.

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 the description does not explain any of the 5 parameters (body, kind, title, engagement_id, expected_latest_revision). The phrase 'proposal or SOW draft' hints at kind, and 'owned engagement' hints at engagement_id, but this is insufficient for an agent to understand required input formats, constraints, or the role of expected_latest_revision.

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 tool creates a 'revision-safe proposal or SOW draft on an owned engagement,' specifying the verb (create), resource (consulting document revision), and scope (on owned engagement, with kind limited to proposal or SOW). It distinguishes from siblings like update_consulting_document_revision or approve_consulting_document_revision.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'on an owned engagement' but does not clarify prerequisites, exclusions (e.g., when to update vs. create), or compare to similar tools like update_consulting_document_revision. The agent would lack context for proper 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 it is not readOnly and not destructive. Description adds minimal context ('owned consulting client'), but no further behavioral traits like required permissions or side effects.

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

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

Single sentence with no wasted words, but could be slightly expanded to include key usage hints without becoming verbose.

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 9 parameters and no parameter descriptions, the description is too brief to guide correct usage, even though an output schema exists.

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 the description provides no explanations for any of the 9 parameters, leaving agents to infer meaning from names 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?

Description clearly states the action 'Create an engagement' and specifies the resource 'for an owned consulting client', distinguishing it from sibling tools like create_consulting_client.

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 on when to use this tool versus alternatives, such as update_consulting_engagement or other creation tools. Missing when-not or prerequisite 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 indicate it is not read-only or destructive; the description adds that the asset is private and a draft with no subsequent publish operation, providing useful context beyond 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 brief sentences front-load the core action and an important limitation. No unnecessary 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?

While the tool has 7 parameters and an output schema, the description only covers basic intent and one limitation. Missing workflow context (e.g., revision or submission steps) makes it only partially complete.

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

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

Schema description coverage is only 14% and the description does not clarify any parameters. For parameters like channel and asset_type, additional guidance would be helpful.

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 it creates a private draft content asset, and mentions there is no publish/send operation, distinguishing it from similar tools like submit_content_asset or approve_content_asset.

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 this tool is for creating drafts without publishing, but it does not explicitly state when to use it over siblings like create_content_asset_revision or submit_content_asset.

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 indicate a write operation (readOnlyHint=false) with no destructive hint. The description confirms creation but provides no additional behavioral details such as permissions, effects on the frozen revision, or side effects. Basic consistency maintained.

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?

Single sentence, no redundant words. Every word adds value. Appropriately front-loaded with the action and target.

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 7 parameters with minimal schema descriptions and no parameter details in the description, the tool is underdocumented. The output schema exists but is not visible; still, the description lacks essential context for correct invocation.

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

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

Schema description coverage is only 14% (only asset_id has a description). The description adds no explanation for the other 6 parameters, failing to compensate for the 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 states a specific verb 'Create', the resource 'content asset revision', and qualification 'from a frozen submitted/approved/rejected revision'. This clearly distinguishes from sibling tools like create_content_asset or submit_content_asset.

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 on when or when not to use this tool versus siblings. The description implies a specific use case (creating a draft from a frozen revision) but does not provide context or 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?

Description adds behavioral context beyond annotations: deal appears live on owner's board, no deletes exposed. No contradiction with 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?

Four sentences, front-loaded with purpose, no fluff. Efficient for 10-parameter tool.

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 creation behavior, ownership, and a key constraint (no deletes). With output schema present, missing defaults are acceptable.

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?

Adds meaning beyond schema by explaining title/lead_id relationship and ownership. Schema covers 80% of parameters, description compensates well.

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?

Clearly states the tool creates a sales deal owned by the caller. Specifies title can come from a lead_id, distinguishing it from sibling tools like convert_lead_to_deal or update_deal.

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 guidance on title vs lead_id but lacks explicit when-not-to-use or alternatives. Usage is implied from context but not 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 are all false (readOnlyHint=false, etc.), so the description carries the transparency burden. It goes beyond the schema by disclosing that totals are computed from line_items and tax_rate, the invoice starts in 'draft' status, and the invoice is owned by the caller. This is valuable behavioral context that annotations alone do not provide.

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

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

Two sentences, no fluff, and front-loaded with the core action. Every clause adds value: caller ownership, optional line items/deal link, computed totals, draft status, and the next-step call to send_invoice.

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 covers the essential behavior for a create tool: draft status, computed totals, ownership, and follow-up action. It does not explicitly state what happens if no line_items are provided (e.g., zero totals), but the output schema and annotations fill in some gaps. Overall, it is complete enough for an agent to use 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 description clarifies how line_items and tax_rate interact (totals computed from them), which is not obvious from the schema where tax_rate only says 'Percentage'. It also explains deal_id as linking to an owned deal. With 56% schema description coverage, the description adds meaningful parameter semantics, though not all params are covered.

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

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

The description begins with 'Create a draft invoice owned by the caller for a client' — a specific verb+resource+ownership that clearly distinguishes the tool from siblings like update_invoice, send_invoice, or convert_deal_to_invoice. It also notes optional line items and deal linking, which further differentiates it from add_invoice_line_item.

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 states that the invoice starts in 'draft' status and directs the agent to call send_invoice to mark it sent, providing clear subsequent workflow. It also mentions optional deal linking, implying when to use this vs. convert_deal_to_invoice, but it does not explicitly state exclusions or when to prefer an alternative.

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 indicate this is not read-only, not destructive, not idempotent. Description adds that the audience is 'owner-private' and 'reusable', which are useful behavioral traits beyond annotations. However, it does not disclose potential constraints like uniqueness of name or side effects of creating duplicates.

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?

Single sentence, no filler, front-loaded with verb and resource. Every word adds value. Perfect 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?

With 4 parameters, no parameter descriptions, and no usage guidance, the description is incomplete. Despite having an output schema, the agent lacks sufficient information to correctly populate optional fields like channels and pain_points. More detail is needed for a 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?

Schema description coverage is 0%, meaning the description does not elaborate on any parameters. The schema itself has no descriptions, only constraints like maxLength. The agent must guess the meaning of 'channels' and 'pain_points' from context. The description should clarify these fields, but it 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?

Description clearly states verb 'create', resource 'marketing audience', and key attributes 'owner-private' and 'reusable'. It distinguishes from sibling tools like update_marketing_audience and get_marketing_audience. Could be more specific about the audience's role in campaigns, but purpose is clear.

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 on when to use this tool versus alternatives. There are sibling tools like get_marketing_audience and update_marketing_audience, but the description does not mention them or provide context on when to create vs. edit. Agent must infer from name 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?

Annotations already indicate this is a read-write, non-destructive operation. The description adds that the brand is owner-private and requires specific write permission, which provides useful context beyond 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 very concise, consisting of two front-loaded sentences. However, this brevity comes at the cost of missing important details, so it is not an ideal balance.

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 creation tool with 4 parameters (0% schema coverage) and an output schema, the description should provide parameter explanations and usage context. It lacks both, leaving the tool under-documented 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%, meaning the schema provides no parameter descriptions. The tool description does not explain any of the four parameters (name, voice, guidelines, value_proposition), leaving the agent without guidance on their purpose or usage.

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 'Create' and the resource 'marketing brand identity', and specifies it is 'owner-private', distinguishing it from get_marketing_brand and other sibling tools.

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 only usage guidance is the authorization requirement 'Requires marketing:agent_write'. There is no mention of when to use this tool versus alternatives (e.g., update_marketing_brand) or any prerequisites.

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 annotations all false, the description carries the full burden. It discloses that the campaign is 'owner-private', but does not mention other behavioral traits such as required permissions, whether creation is immediate or asynchronous, rate limits, or any side effects beyond linkage.

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 of 14 words, immediately conveying the core action and key constraints. It is front-loaded and contains no fluff.

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 tool has 8 parameters and an output schema (not shown). The description only covers the high-level purpose and the linkage constraint, but does not explain the output, required fields, or any nuances for the many optional parameters. It is insufficient for an agent to fully understand how to invoke the tool 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 description coverage is only 25% (only brand_id and audience_id have descriptions in the schema). The tool description does not add meaning for the other 6 parameters (name, status, ends_on, channels, objective, starts_on). The mention of 'linked only to owned brand/audience ids' weakly ties to those parameters but does not explain their semantics or constraints.

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 'Create' and the resource 'marketing campaign'. It adds specific qualifiers ('owner-private' and 'linked only to owned brand/audience ids') which distinguish it from sibling create tools like create_marketing_audience or create_outreach_campaign.

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 context by stating the campaign is 'linked only to owned brand/audience ids', suggesting the user must have such owned resources. However, it does not explicitly state when to use this tool vs. alternatives (e.g., create_outreach_campaign) or when not to use it.

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 include generic hints (all false), so the description carries the burden. It discloses that the monitor persists beyond the conversation and that it fires autonomously (unattended), and warns about credit costs and cooldown bounding. This is valuable transparency beyond the schema. It could mention how to delete or stop, but that's a minor 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?

The description is concise and well-written, using accessible language. It front-loads the core purpose in the first sentence, then adds necessary caveats about cost. Every sentence contributes to understanding the tool, with no fluff.

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 tool is moderately complex with 8 parameters, nested objects, and an output schema. The description covers the core behavior, persistence, and cost implications, but it doesn't mention the output format or how to later manage the monitor (e.g., delete, list). Given the output schema and full schema documentation, this is largely complete, but a bit more on lifecycle management would be ideal.

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

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

Schema coverage is 100%, so the schema already fully documents parameters. The description adds some value by explaining the purpose of the monitor overall, but does not explain individual parameters beyond what the schema provides. The nested action_config is clearly described in the schema, so the description's mention is not additional insight. Baseline 3 is appropriate.

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

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

The description clearly states that this tool creates a persistent monitor (a standing watch) that triggers an action when a condition is met, distinguishing it from other 'create' tools. It explicitly mentions the key use case of banking a condition to avoid polling, which differentiates it from generic creation tools.

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 explains the primary use case (avoiding polling) but does not explicitly state when not to use it or mention alternatives. It implies that this tool is for long-running conditions, but doesn't compare it to other monitoring or workflow tools. However, it does clarify that start_workflow has cost implications, which helps with usage decisions.

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 provide readOnlyHint=false (mutation known) and destructiveHint=false (non-destructive). The description adds value by stating the mutation is reversible (campaigns can be edited/deleted), which goes beyond annotations. It also specifies authentication requirement and output (returns campaign id). No contradictions with 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 sentences, front-loaded with the primary action and ownership. Every word adds value: return value, reversibility, auth. No fluff or repetition. Highly 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?

For a creation tool with 5 simple parameters and an output schema, the description covers the essential behavioral context: auth, ownership, reversibility, and return value. The missing mention of default status is minor since schema covers it. Output schema exists, so return value detail is sufficient. Slightly more detail on side effects would improve completeness.

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

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

Schema coverage is 100%, with all parameters described. The description does not add additional meaning beyond the schema, such as format constraints or default values. For example, it doesn't mention that status defaults to 'draft' (though implicit in schema). Baseline 3 is appropriate since schema carries the burden.

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

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

The description clearly states the verb 'Create' and resource 'outreach campaign', specifies ownership by authenticated user, return value (campaign id), and reversibility. It effectively distinguishes this tool from sibling tools like 'create_marketing_campaign' due to the 'outreach' qualifier.

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 when to use (to create an outreach campaign) but does not explicitly compare to alternatives or state when not to use. No guidance on choosing between similar creation tools like 'create_marketing_campaign' or 'create_outreach_pitch'. Usage context is implied but not explicit.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds provenance stamping and return value, but no further behavioral details like side effects or rate 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?

Three sentences, efficient and front-loaded with key action. 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?

For a creation tool, it covers ownership, provenance, authentication, and return value. Output schema presumably details the returned id. Minor gaps: no mention of error handling or validation constraints.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description only briefly mentions the required ones and the drafting prompt, adding no new meaning 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?

The description clearly states the tool creates a reusable pitch template with subject and body templates, optional drafting prompt, owned by the user, and returns a pitch id. It is distinct from sibling tools like create_outreach_campaign or draft_outreach_email.

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 mentions ownership and authentication but provides no guidance on when to use this tool versus alternatives, no exclusions, and no context for when it is appropriate.

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 discloses critical behaviors not captured by annotations: the snapshot is immutable and cannot be edited/deleted, it records the credential of the capturer (attributability), and it never recomputes. Since annotations are sparse (no hints beyond non-readOnly), the description carries the weight and does so effectively. Minor deduction for not detailing output format, but output schema exists.

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

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

The description is compact and front-loaded with the core action, then explains immutability and use-case. Every sentence adds value, with no redundancy. It efficiently covers purpose, usage, and behavioral traits in a few sentences.

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 complexity (one optional param, output schema exists, strong annotations), the description is complete. It covers the key aspects an agent needs: what it does, why it's useful, when to use it, constraints, and auth scope. There's no gap that would hinder correct invocation.

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

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

Schema description coverage is 100%, so the description adds no new detail on the 'label' parameter, but it does mention 'Omitted leaves the snapshot unlabelled' which clarifies optionality. The description's focus on purpose over parameters is acceptable given the single optional param is well-documented in the schema.

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

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

The description clearly states the action (capture an immutable rollup) and the resource (your own ticket portfolio), with specific details on what it includes (totals by status and priority) and its immutable nature. It effectively distinguishes from siblings like diff_portfolio_snapshots and get_portfolio_snapshot by emphasizing the snapshot's fixed, non-recomputed nature.

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 explicitly recommends when to use this tool ('capture one before a review rather than after') and implies when not to use it (for comparisons, use diff_portfolio_snapshots). It also notes that snapshots cannot be edited/deleted, which sets expectations for usage. This is strong guidance beyond basic description.

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

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

Annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) are aligned with the description's statement that it writes a note but has no downstream gating. The description also discloses side effects (record creation) and non-effects (no approval/block).

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 well-structured and concise, front-loading the core action and then providing necessary caveats. Every sentence adds value—no fluff 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?

Given the detailed schema and annotations, the description is complete. It covers the tool's primary function, key parameter behavior, side effects, and clarifies that it is not part of approval processes. No gaps remain for an agent to misuse the 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?

All four parameters (body, kind, snapshot_id, expected_content_hash) are described in the schema with meaningful defaults and purposes. The description additionally elaborates on expected_content_hash beyond the schema, explaining its role in preventing mismatched revisions.

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 tool's purpose: 'Record a decision or comment against one of YOUR OWN portfolio snapshots.' It distinguishes this from related tools like listing notes or creating snapshots, and specifies the scope (own snapshots).

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

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

It explains when to use the expected_content_hash parameter and its consequence (refusal on mismatch), and clarifies that omitting it still records the note but without revision assertion. It also explicitly notes that the tool does not approve/reject/block anything, helping agents avoid misusing it for approval workflows.

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 annotations all false, the description carries the full burden. It discloses that it saves a question, not an answer (views re-run on live data), that the view is private until shared, requires authentication, and needs the tickets:write scope. This goes beyond the annotations and gives actionable context about side effects and access.

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, front-loaded with the purpose. Every sentence adds value: purpose, behavioral nuance, and access requirements. No redundancy or fluff.

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 covers purpose, behavior, sharing, and authentication. With an output schema present, the need to explain return values is mitigated. It could mention how to reference the created view (e.g., returned ID), but output schema likely covers that. Overall, it is complete for an agent to decide and execute.

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 each parameter already has descriptive semantics. The description adds context that these parameters form a bundle (filter, columns, grouping, sort) and clarifies that filters use the same vocabulary as the ticket list. This adds meaning beyond the schema by explaining how parameters work together.

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 tool saves a named bundle of filter, columns, grouping, and sort for later reuse or sharing. It distinguishes from siblings like update_saved_view (which modifies) and execute_saved_view (which runs) by focusing on creation.

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

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

Provides clear context on when to use: to save a view for later or share, and notes it is the same endpoint as the web app's save button. It does not explicitly mention alternatives like update_saved_view for editing, but the purpose and context make usage 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?

The description goes well beyond annotations by revealing critical behavioral traits: steps run sequentially regardless of depends_on, 'transform' and 'connector' types fail at runtime (so agents should avoid them for actual work), slug derivation from name, and required auth scope. Annotations only show readOnlyHint=false and destructiveHint=false, which are minimal; the description compensates fully with rich, actionable details.

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

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

The description is front-loaded with the core purpose, then adds essential behavioral nuance. At 5 sentences, it's efficient without being verbose. Minor improvement could be integrating the slug note and auth scope more seamlessly, but the structure is logical and scannable.

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 complexity (5 parameters, nested steps array, edge cases like non-agent types), the description covers all critical behavioral aspects: execution order, slug usage, type limitations, and auth requirements. It does not need to explain output schema since it exists. The description is complete for an agent to decide and invoke correctly, with no apparent 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 baseline is 3. The description adds value by explaining the slug derivation ('returned — use it with run_workflow') and clarifying the depends_on caveat (metadata only), which augments the schema. It could further explain parameter interactions (e.g., how 'steps' array constraints relate) or the 'domain' default, but the added context is helpful and not redundant.

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 tool creates a new custom workflow template owned by the caller, with a specific use case ('multi-step pipeline can be built in conversation instead of by hand in the browser'). It differentiates from siblings like 'plan_workflow' (planning) and 'run_workflow' (execution), and the verb 'create' is precise. The description also clarifies that the tool saves the same definition as the web builder, reinforcing its purpose.

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

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

The description provides clear when-to-use context (building a pipeline in conversation) and explicitly references sibling tool 'run_workflow' for execution. It briefly notes that steps run sequentially and that 'depends_on' is metadata only, which helps avoid misuse. However, it lacks explicit 'when not to use' guidance or comparison to alternative tools like 'update_workflow_template' or 'plan_workflow', which could further clarify boundaries.

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?

Adds critical behavioral details beyond annotations: both approve and amend are billed (spends money), it fails with a clear error if the run is no longer waiting, and it requires authentication with the workflows:approve scope. These are not evident from the annotations and provide safety-critical information. No contradiction with 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?

Three sentences, each dense with value: the purpose, the meaning of 'amend', the money implication, error behavior, and auth. No filler or redundancy, with the core action stated first.

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

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

Given the output schema exists (so return values are documented elsewhere) and the annotations are present, the description covers the essential operational expectations: how decisions map to actions, cost implications, failure modes, and required permissions. Nothing significant is left unclear for an agent to invoke this 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 description coverage is 100%, so the baseline is 3. The description reiterates the notes requirement for amend and explains the decision meanings, but it adds minimal new semantic information beyond the schema's field descriptions. The 'notes' parameter is already documented as required for amend, so the description adds little.

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 clearly that it answers a waiting checkpoint by request id, with three explicit decisions (approve, reject, amend). The description names the specific resource (waiting checkpoint) and verb (decide), and the generic nature distinguishes it from sibling approval tools like approve_consulting_deliverable or reject_content_asset.

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?

Specifies when to use: when a checkpoint is waiting and you have the request id. It does not explicitly list alternatives or exclusions, but it clarifies that the run must be waiting to succeed. Lacks a clear 'do not use if...' statement or named alternative, so not a 5.

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

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

Beyond the destructiveHint annotation, the description adds that deletion is permanent and clarifies the tool does not perform financial actions or contact external services, providing useful behavioral context without contradiction.

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 sentences long, immediately front-loads the core action and scope, and contains no unnecessary 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?

For a simple delete tool with one parameter and an output schema, the description covers ownership, scope, and constraints, making it fully adequate 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 description does not explain the run_id parameter despite 0% schema coverage. However, the single parameter is self-explanatory and required, making its purpose clear enough for an agent to use correctly.

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 explicitly states the verb 'delete', the resource 'Accounting audit run', and the scope 'private' and 'owned by the caller'. It also distinguishes from siblings by noting it is 'the only Accounting MCP deletion'.

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 clearly indicates when to use this tool (to delete a run) and what it does not do (e.g., never files taxes), but does not explicitly mention when not to use it or name alternative tools like get_accounting_run.

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 clearly describes a destructive operation ('Delete one of your standing watches'), but the annotations set destructiveHint=false, which contradicts the described behavior. Per the rubric, this is an annotation contradiction, so the score is 1.

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-load the key action and add only essential clarifications: the effect, the non-effect, and the required scope. 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 one-parameter delete tool with an output schema, the description covers the effect, what it does not affect, and authentication requirements. The only notable gap is the annotation contradiction, which is already penalized in behavioral transparency.

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 input schema has 100% coverage for the single parameter, including a clear description of monitor_id. The tool description does not add parameter-specific semantics, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Delete') and resource ('standing watches'), and clarifies the effect ('so it stops firing'), which distinguishes it from create_monitor/list_monitors and other delete_* siblings. The purpose is immediately clear.

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

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

The description gives clear context for when to use the tool ('so it stops firing') and explicitly states a non-effect ('Does not touch anything it already started'). However, it does not name alternatives or provide when-not-to-use guidance, so it stops short of a 5.

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

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

The description transparently discloses that deletion is permanent and unrecoverable, and mentions authentication requirements. However, the annotation `destructiveHint: false` contradicts this, as deleting a saved view is clearly destructive. This contradiction undermines transparency and warrants a score of 1.

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 succinct yet comprehensive, front-loading the core action and including essential warnings, alternative guidance, shared view implications, and auth requirements in a few sentences. Every sentence adds value without redundancy.

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

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

Given the tool's destructive nature, the description thoroughly covers the irreversible aspect, suggests a safer alternative, notes the team-wide impact, and specifies authentication and scope needs. It is complete for a tool with this complexity and existing output schema.

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

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

The schema description covers 100% of the single parameter, view_id, with a clear explanation of its source (from list_saved_views). The tool description adds no extra meaning beyond that, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: permanently delete a user's own saved view. It also distinguishes from the sibling archive_saved_view by explicitly naming it as a reversible alternative, which differentiates the tool and clarifies its scope.

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

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

The description provides explicit guidance on when to use this tool versus archive_saved_view, stating that archive is 'almost always what is wanted instead' and that delete is only for views that should truly be removed. It also warns about the impact on shared views, offering clear exclusions and 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?

The description explicitly says 'removes the saved definition,' which is inherently destructive, yet the annotation declares destructiveHint: false. This is a direct contradiction. The description does disclose that runs are unaffected and requires auth/scope, but the destructive nature contradicts the annotation, warranting the lowest score.

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 four sentences, all purposeful. It front-loads the core action and ownership, then adds built-in exclusion, impact on runs, and auth requirements. Every sentence adds value without redundancy, making it highly concise and 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?

Given it's a delete operation with an output schema, the description covers essential context: scope, ownership, impact on existing runs, and auth requirements. It doesn't explain the fingerprint parameter, but the schema does. It also doesn't mention failure conditions, which are presumably in the output schema. Overall, it is quite complete for the tool's complexity, though not flawless.

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 covers 100% of parameters with detailed descriptions (e.g., slug and expected_template_fingerprint). The tool description adds no parameter-specific information beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 action (delete), the resource (custom workflow template), and the ownership constraint (caller owns). It distinguishes from siblings like create_workflow_template and update_workflow_template by specifying that built-in templates cannot be deleted. This is a specific, unambiguous purpose.

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

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

The description provides clear usage context: only for custom templates owned by the caller, not built-ins. It also notes that runs already started are unaffected, giving insight into the impact. While it doesn't explicitly name alternative tools, the ownership and built-in exclusions effectively guide when to use 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 readOnly, idempotent, and non-destructive. The description adds significant behavior beyond this: immutability ('Both sides are immutable, so a diff is reproducible indefinitely'), default rule for the baseline, the 'not found' result for the first snapshot, and the explicit disclosure of reverse-chronological behavior with negative elapsed days. It also states auth requirements (tickets:read scope). No contradiction with 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 composed of four purposeful sentences. It starts with the core action, then explains parameter direction and defaults, then covers edge-case disclosure, then immutability and auth. No redundant or filler content; every sentence contributes meaningful information.

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

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

Given the tool's moderate complexity (2 params, output schema present, annotations provided), the description covers all essential aspects: purpose, parameter behavior, edge cases, side effects (none, immutability), and required permissions. The output schema presumably documents the return shape, so no further detail is needed. The description is self-sufficient for correct invocation.

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

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

Schema coverage is 100% and both parameters already have descriptions in the schema. The tool description reinforces the 'to'/'from' side semantics and explains the defaulting rule for 'against', which adds clarity beyond the schema's individual parameter descriptions. Since the schema already carries most of the meaning, the description's incremental value is moderate.

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

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

The description opens with a specific verb and resource: "Compare two of your own portfolio snapshots and return the per-dimension movement between them." This clearly distinguishes it from sibling tools like get_portfolio_snapshot (single snapshot) or list_portfolio_snapshots (listing). The 'your own' scope and the output type (per-dimension movement) are explicit.

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

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

The description provides clear context on how to use the tool, including the direction semantics ('snapshot_id is always the to side; against is the from baseline') and the default behavior ('defaulting to your newest snapshot strictly older than it'). It also covers edge cases like first snapshot and reverse comparisons. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of a 5.

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

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

The description adds key behavioral context beyond annotations: it does NOT send anything, it only stores for review, and requires authentication. No contradiction with annotations; readOnlyHint=false is consistent with creating a draft.

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, each adding essential information: action, non-sending clarification, authentication requirement. 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?

For a simple draft-saving tool with an output schema, the description covers core behavior, safety (no send), and auth. Could mention error handling but still 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?

Schema coverage is 100%, so baseline is 3. The description adds value by specifying that lead_id comes from search_outreach_leads, which helps in selecting the correct parameter.

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 it saves a draft email subject and/or body onto a lead, using specific verbs and resource. It distinguishes from siblings by emphasizing it does NOT send anything.

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 explicitly says when to use (storing a draft for human review) and when not (does not send, human sends from dashboard). It does not name alternative tools but provides clear context.

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 concrete behavioral clarity with 'Reserves nothing, charges nothing, starts nothing', which explains the operational side-effect-freedom in domain terms. It also discloses honest reporting of unpriced models, going beyond the generic annotation hints.

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 one dense sentence with front-loaded purpose ('Estimate what a panel or saved workflow would cost before running it'), followed by a colon-separated list of outputs and a final safety clause. Every clause earns its place, and it avoids fluff or repetition.

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

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

Given that an output schema exists, the description appropriately avoids detailing return fields. It covers the tool's scope (pre-run estimation), key output categories, the unpriceable-models edge case, and its non-destructive nature. This is a complete picture for an AI agent to decide when and how to invoke it.

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 already includes detailed parameter documentation (e.g., the model parameter explicitly states that absent models are reported in unpriced_models). The description's references to 'per-agent/per-step price breakdown' and 'requested number of runs' vaguely map to the runs parameter but add no new semantic details 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?

The description starts with a specific verb and resource: 'Estimate what a panel or saved workflow would cost before running it'. It also enumerates concrete outputs (per-agent/per-step breakdown, total, quota, credit, unpriced models, go/no-go), which clearly distinguishes it from sibling tools like run_council or run_workflow.

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 'before running it' establishes the core use context as a pre-execution cost estimation step. It does not explicitly name alternatives like run_council or run_workflow, nor list when not to use it, but the contrast with running tools is implied clearly enough.

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 discloses behavior beyond annotations: it notes results are always the user's own tickets, that shared views do not reveal others, and that archived views are refused. It also states the return payload and required auth/scopes, adding transparency not fully captured by 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 informative and front-loaded with the core purpose, but it repeats the phrase 'your tickets' and could be slightly trimmed without losing meaning. Still, it is well-structured and not overly verbose.

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?

It covers the core behavior, result semantics, edge cases (archived views), return payload, and authentication/scoping requirements, making it complete 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?

The schema already provides descriptions for all three parameters (limit, offset, view_id). The description adds no extra meaning to these parameters, so it stays at the baseline for high schema 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 clearly states that the tool runs a saved view's stored filters against live tickets and returns matching tickets, which distinguishes it from sibling tools like get_saved_view or list_saved_views.

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 provides context on when to use (has a saved view and wants tickets) and clarifies semantics around shared and archived views, but does not explicitly compare with 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?

Beyond annotations (readOnly, idempotent, non-destructive), the description adds that the response includes deterministic estimates, disclaimer, engine revision, audit timestamps, and that source input is omitted unless explicitly requested. This provides useful behavioral context.

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

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

Two sentences, no redundancy, front-loaded with the core action. Every sentence adds necessary information.

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

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

Given the output schema exists and the tool is a simple get with two parameters, the description covers all key behavioral aspects: what is included in the response and the conditions for including input. No gaps.

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

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

Schema coverage is 50%; the description indirectly explains run_id's purpose but adds no format details. It does explicitly explain include_input's effect, but overall adds limited parameter meaning 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?

The description uses a specific verb ('Get') and resource ('private Accounting run'), and clearly distinguishes itself from sibling list_accounting_runs by specifying it retrieves a single run owned by the caller.

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

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

It implies usage for retrieving a single run by ID and includes guidance on when to use include_input. However, it does not explicitly state when not to use it or mention alternatives like list_accounting_runs.

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 the description adds value by listing the returned fields but does not disclose additional behavioral traits beyond what annotations provide.

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

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

The description is a single, clear sentence that immediately conveys the action (get full detail) and resource (agent by slug). 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?

The tool has one simple parameter, an output schema exists (so return details not needed), and the description lists the fields returned. Given the low complexity, the description is complete.

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

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

Schema coverage is 100% with the slug parameter already described. The description mentions slug implicitly but adds no further semantic detail 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?

The description clearly states it gets full detail on an expert agent by slug, listing specific fields (role, description, default model, domain, tags, tools). It distinguishes from the sibling tool list_agents by using the phrase 'from list_agents'.

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 explicitly references list_agents as the source for slugs, providing clear context for when to use this tool. It implies a two-step workflow: list agents to get slugs, then use this tool for details. No explicit when-not, but guidance is clear.

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

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

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds valuable context beyond annotations by specifying that it requires API-key authentication and that it reports on the API key making the current call. This gives the agent the necessary behavioral context without redundancy.

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 sentences, front-loaded with the core action and return fields, followed by a necessary authentication note. Every word adds value; there is no fluff or repetition of schema or annotations.

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), rich annotations, and the existence of an output schema, the description provides all essential context: what the tool returns, why it should be used, and its authentication requirement. It fully equips an agent to decide when and how to invoke it.

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 schema is trivially 100% covered. The description does not need to explain parameters. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no extra but none is needed.

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 tool's function with a specific verb 'Report' and the resource 'API key'. It enumerates the exact information returned (scopes, plan tier, expiry, remaining quota), which distinguishes it from all sibling tools that focus on business operations.

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

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

The description provides a clear usage context: use this tool to check permissions before making other calls, avoiding refusals. It does not explicitly name alternatives, but no direct alternative exists among siblings. It implies a 'when to use' without excluding any particular scenario, so it falls just short of full 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 (readOnlyHint, idempotentHint, destructiveHint) indicate safe read. The description adds that long document bodies are previewed, providing useful nuance beyond 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 concise sentences deliver key information without redundancy. Front-loaded with the main action and then additional details.

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 an output schema present, the description appropriately focuses on input and behavior. It covers the returned entity structure and the note on long document previews, making it substantially 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?

The single parameter engagement_id is clear from the schema. The description mentions 'owned engagement', hinting at authorization scope, but does not add detailed semantics 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?

The description clearly states it retrieves a single engagement along with its related entities (document revisions, milestones, internal deliverables). It explicitly distinguishes from list_consulting_engagements by focusing on a single record.

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 when you need a specific engagement with its children, but does not explicitly contrast with other retrieval tools like get_deal or provide when-not-to-use 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 readOnlyHint, idempotentHint, destructiveHint. The description adds minor context (owned revision, included fields) but does not significantly expand beyond 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 concise sentence that front-loads the verb and resource, with no unnecessary 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 the tool has one parameter and an output schema, the description is complete: it specifies what is retrieved and key included fields (review state, hashes). No 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?

With 100% schema coverage, the schema already describes the asset_id parameter. The tool description adds no additional meaning for the parameter.

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 tool retrieves one owned content revision, specifying what is included (review state, content hashes). It distinguishes from sibling list_content_assets and create/update tools.

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 does not provide explicit guidance on when to use this tool vs alternatives like list_content_assets. Usage is implied from the purpose but not explicitly 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 indicate read-only and non-destructive behavior. The description adds valuable context that scheduling is metadata and does not involve publishing, enhancing transparency beyond 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 concise sentences: the first states the action and scope, the second clarifies the nature of scheduling. No superfluous information.

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

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

Given the low complexity (two optional parameters, simple types, existing annotations and output schema), the description adequately covers what the tool does and the nature of the data, making it complete for effective use.

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 mentions 'optional ISO-8601 boundaries' which hints at the start and end parameters, but does not explicitly describe each parameter's role. With 0% schema description coverage, more detail would be beneficial.

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 'list' and the resource 'scheduled owned content', distinguishing it from sibling tools like list_content_assets. The clarification that scheduling is planning metadata, not publishing, further refines the purpose.

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 for viewing scheduled content within a date range using ISO-8601 boundaries. While it does not explicitly name alternatives, the context makes it clear when this tool is appropriate compared to general listing 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 indicate readOnlyHint=true and idempotentHint=true. The description adds context that the result includes a full activity timeline sorted newest first, which goes beyond annotations. No contradictions.

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?

Single sentence that front-loads the action and includes key details (timeline contents, sort order). Every word is necessary and efficiently conveys the tool's purpose.

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, the output schema exists, and the description covers the main return value (activity timeline). It omits error behavior or pagination details, but these are standard for a fetch-by-id 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 100% schema coverage, the schema already documents 'deal_id'. The description adds no extra meaning beyond implying the parameter is used for fetching, which is already clear. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Fetch' and specifies the resource 'one of the caller's deals by id' with the unique added value of including the full activity timeline. This distinguishes it from siblings like list_deals and get_deal_health.

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 use when you have a specific deal_id and need the full timeline, contrasting with list_deals for browsing. It does not explicitly list when not to use, but the context is clear.

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