Wisprs

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the tenant-ownership scope, the lifecycle precondition (not yet dispatched), and the requirement for explicit confirmation — none of which appear in 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?

Two short sentences with zero filler, front-loading the action and then the precondition. Nothing could be removed without losing a 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?

An output schema exists, so return values need not be explained, and annotations carry the destructive/idempotent profile. The description supplies the missing lifecycle precondition; only minor gaps remain around the idempotency key's role.

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%, but the schema itself is unusually self-documenting (confirm is const true, meetingId and idempotencyKey carry regex patterns and length bounds). The description adds meaning only for `confirm` via 'Requires explicit confirmation', and says nothing about idempotencyKey or what a meetingId refers to.

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

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

States a specific verb and resource ('Cancels a tenant-owned meeting agent') plus a scoping precondition ('that has not yet been dispatched'), which is far more precise than the name alone. It does not explicitly name schedule_meeting_capture as the inverse/mistake case, but the verb makes the distinction obvious.

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?

'has not yet been dispatched' is an explicit when-to-use boundary that tells the agent this is not the tool for already-running captures. However, no alternative tool is named for the dispatched case, leaving the agent to search siblings.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds only "tenant-owned" scoping and "durable" — the latter largely restates the idempotent hint. It never explains why a creation tool carries destructiveHint=true, nor what a replay with the same key does.

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

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

A single front-loaded sentence with no filler. Its brevity is close to under-specification, but structurally there is nothing to trim.

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

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

With zero schema description coverage, an output schema present, and a destructiveHint-tagged mutation, the description should explain idempotency-key reuse, name/color expectations, and failure modes. It doesn't, leaving an agent to infer the contract from a pattern regex.

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 mentions no parameters at all. Nothing explains what idempotencyKey should be reused for, whether color is optional or what format it takes, or whether name must be unique within the tenant — the schema constraints alone must carry all of 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?

States a specific verb and resource ("Creates ... media folder") plus scope ("tenant-owned"). It doesn't name any sibling (e.g., list_folders/rename_folder) to delimit itself, but the create-vs-modify split is obvious from the verb.

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 reach for this tool versus alternatives, no prerequisites, no exclusions. The agent is left to infer that folder creation precedes move_transcript_to_folder or list_folders.

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, openWorldHint=true and idempotentHint=true; the description adds genuinely new context by framing the operation as an upsert ('creates or updates'), marking the link as time-bounded, constraining the target to tenant-owned completed transcripts, and stating the external-disclosure precondition. It does not mention rate limits, what happens to a prior link, or how external exposure can be withdrawn.

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

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

A single dense sentence that front-loads the action and the object, then ends with the prerequisite. Every clause carries information; no filler.

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

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

An output schema exists, so return values need not be described. However, for a destructive, open-world, security-sensitive write tool, the description leaves material gaps: what permission means, whether an existing link is replaced or a second link is created, and how the granted access is later revoked.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the meaning. It hints at expiresInHours ('time-bounded') and confirms the disclosure flag, but says nothing about the view-vs-download permission enum or the idempotencyKey — two parameters an agent must reason about to call this safely, and 'one transcript' only indirectly maps to transcriptionId.

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

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

States a specific verb+resource ('creates or updates a time-bounded public link'), the object ('one tenant-owned completed transcript'), and the gating condition ('explicit external-disclosure confirmation'). The scope is narrow enough that an agent can distinguish it from revoke_share_link or export_transcript without reading either schema.

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

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

The phrase 'after explicit external-disclosure confirmation' implies a prerequisite, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. revoke_share_link for the inverse). Usage is implied rather than instructed.

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

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

The annotations already disclose readOnly=false, destructive=true, openWorld=true, and idempotent=false, so the safety profile is largely covered. The description adds useful context that the request is for the authenticated user and is delivered to the Wisprs support team, but it does not explain side effects, confirmation needs, or what 'bounded' means.

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

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

The description is a single front-loaded sentence with no wasted wording. It is efficient, though very sparse for a tool with required inputs and an enum.

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?

Because an output schema exists, return values need not be described, and annotations carry the safety profile. However, the description omits usage guidance, required-field semantics, type options, and limits, leaving meaningful gaps for a structured create operation.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters, including the subject/message requirements and the type enum. It provides almost no parameter-specific meaning beyond implying that a support request is being submitted.

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

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

The description states a specific verb and resource: creates a support request for the authenticated user and delivers it to the Wisprs support team. It is clear what the tool does, though it does not explicitly distinguish itself from nearby tools such as list_support_tickets.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent can infer that it creates a ticket, but nothing tells it when a ticket is appropriate or how it relates to list_support_tickets.

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

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

Goes well beyond the annotations: discloses SSRF-safe DNS validation, that the call returns a durable operation receipt (async, not the final endpoint), and that the signing secret appears only in the completed operation result — a critical fact an agent would otherwise get wrong. It never explains why destructiveHint is true, which is the one remaining behavioral gap for a mutation tool.

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

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

Two dense sentences, front-loaded with the action and validation behavior, with the secret-delivery caveat placed last where it matters. Zero 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?

Output schema exists, so return shape needn't be explained, yet the description still clarifies when the signing secret becomes available. Missing only the retrieval path for the operation receipt (e.g., get_job_status/list_operations) and the idempotencyKey contract, which would close the loop for an agent.

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

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

Schema description coverage is 0%, so the description must carry both parameters. It effectively adds the HTTPS-only constraint on 'url' (not enforced by the schema), but says nothing about 'idempotencyKey' — no explanation that it deduplicates retries, despite idempotentHint being set. Half the parameter surface remains undefined.

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

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

Specific verb + resource ('Creates an HTTPS webhook endpoint for the Wisprs webhooks API') with a scope qualifier (SSRF-safe DNS validation) that clearly separates it from list_webhook_endpoints and update_webhook_endpoint. An agent knows exactly what this does without opening the schema.

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

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

The create semantics imply usage, but nothing states when to call this versus update_webhook_endpoint or list_webhook_endpoints, nor any prerequisite (e.g., existing endpoint conflicts, plan limits). The doc link provides an escape hatch but no in-description routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety bar is lower, yet the description adds a crucial nuance: this is a SOFT delete that unfiles media rather than destroying it. It also discloses tenant-ownership scoping, which hints at authorization boundaries. It stops short of stating whether subfolders or empty-folder states are affected.

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

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

Two tight sentences with zero filler. The most consequential fact — that it is a soft delete preserving media — is front-loaded in the first clause.

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

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

With an output schema present, return values need no explanation, and annotations cover the destructive/idempotent profile. The main residual gap is the required idempotencyKey, whose purpose an agent must infer from the schema pattern alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only implicitly covers 'confirm' via 'requires explicit confirmation'; 'idempotencyKey' is never mentioned despite being required, and 'folderId' semantics (tenant scope, prefix format) come only from the schema pattern.

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

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

States a specific verb ('soft-deletes'), a specific resource ('one tenant-owned folder'), and the side effect ('unfiles its media'). This is far more precise than the title and clearly distinguishes it from rename_folder/list_folders, though it does not explicitly name a sibling alternative.

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?

'Requires explicit confirmation' tells the agent a precondition for invocation, and 'preserves the media items' implies when this is preferable to a hard delete. However, there is no explicit guidance on when to use this versus move_transcript_to_folder or other folder operations.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the bar is lower, yet the description adds genuinely new context: the operation is a reversible soft delete scoped to tenant-owned resources and demands explicit confirmation. It stops short of saying whether the endpoint ID can be re-activated later or what happens to in-flight deliveries, which keeps it off a 5.

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

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

Two short sentences, front-loaded with the action and immediately followed by the most decision-relevant trait (reversibility, confirmation). Nothing is padded, though the confirmation constraint could have been stated more concretely as a parameter-level instruction.

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, return values need no explanation, and annotations cover the safety profile. However, for a mutation with three required params at zero schema coverage, the description leaves the endpointId format and idempotencyKey purpose unaddressed, and does not say how an endpoint is re-enabled.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, but it only indirectly addresses one of three params ('explicit confirmation' maps to confirm=true). The endpointId format (whk_ prefix) and the idempotencyKey contract are not explained or hinted at anywhere.

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

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

States a specific verb (disables) and resource (tenant-owned webhook endpoint), and clarifies that the 'delete' in the name is actually a soft disable. It does not differentiate from the sibling update_webhook_endpoint, which may also toggle endpoint state, so an agent cannot fully resolve the pair without the schema.

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

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

The phrase 'requires explicit confirmation' implies the confirm=true precondition, giving a hint about how to invoke it, but there is no explicit when-to-use guidance, no when-NOT-to-use, and no mention of update_webhook_endpoint as the alternative for re-enabling or editing.

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

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context: 'one bounded' edit implies a single occurrence by default, and 'exact revision guard' discloses optimistic concurrency semantics that are not in the annotations. It doesn't explain what happens on a revision mismatch, which keeps it from a 5.

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

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

Two sentences with zero filler. The core operation is front-loaded, followed immediately by the safety prerequisites, so the agent gets the critical constraints before opening 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?

Output schema exists, so return values needn't be explained. However, for a destructive mutation with 0% parameter documentation, the description should cover replaceAll semantics, idempotency behavior, and what a revision-guard failure looks like. It covers the destructive/confirmation side adequately but leaves key calling details to inference.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden, but it addresses only the confirmation and revision guard. Critical parameters like replaceAll (which directly qualifies the 'one bounded' phrasing), idempotencyKey, and transcriptionId semantics are entirely undocumented. An agent could easily misread 'bounded' as always-single-occurrence and overlook replaceAll.

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

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

The description gives a specific verb and resource: 'bounded literal find-and-replace edit' on a 'tenant-owned transcript'. This clearly distinguishes it from sibling tools like rename_transcript (metadata rename) and repurpose_transcript. It stops short of naming those siblings explicitly, so it is a 4 rather than a 5.

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

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

'Requires confirmation and an exact revision guard' states the prerequisites for calling but says nothing about when to choose this over rename_transcript or repurpose_transcript. Usage is implied by the description of what the tool does, but there are no explicit exclusions or alternative routing. A solid 3.

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

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

Annotations already declare idempotentHint=true and destructiveHint=true, and the description usefully echoes idempotency and discloses the delivery mechanism for large exports. However it never explains why the tool is flagged destructive (what is consumed or overwritten) or how long the resource reference lives, leaving the most consequential behavior undisclosed.

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

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

Two tight sentences with the operation stated first and the delivery caveat second; nothing is padded. It is arguably slightly over-compressed given the missing parameter guidance, but there is no wasted text.

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

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

An output schema exists, so return values need not be explained, and the 'expiring resource reference' line covers the one non-obvious output shape. Still, for a three-required-parameter mutation-ish tool with zero schema descriptions, the definition leaves format choice, key construction, and the destructive flag unexplained.

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

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

Schema description coverage is 0% and the description mentions none of the three required parameters. 'Idempotent' loosely gestures at idempotencyKey, but format (six enum values) and the transcriptionId pattern are entirely undocumented outside the raw schema, so the description does not compensate for the coverage gap.

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

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

The description gives a specific verb and resource ('Starts an idempotent transcript export') and adds the delivery model, so the agent knows exactly what operation it is invoking. It does not explicitly contrast with related siblings like get_transcript or get_transcript_artifact, which keeps it below a 5.

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

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

Usage is only implied: the note that large exports come back as an expiring resource reference hints at a follow-up retrieval step, but the description never names when to call this versus get_transcript/get_transcript_artifact, nor states prerequisites such as a required transcriptionId. An agent must infer the workflow.

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

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

Annotations already declare readOnly=false, destructive=true, idempotent=true, openWorld=true. The description adds two genuinely non-redundant facts: the call is 'billable' (cost implication) and returns a 'durable operation receipt' (async, pollable). However it never explains what 'destructive' means here (e.g., overwriting existing chapters) or how idempotencyKey affects replay behavior.

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

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

A single front-loaded sentence with no filler, and the billing/return facts arrive early. It is efficient rather than bloated; its shortfall is under-specification, not verbosity.

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?

An output schema exists, so return-value detail is not required, and the 'durable operation receipt' phrasing usefully frames the async pattern. Still missing for a billable, destructive, idempotent-keyed mutation: cost/reversibility expectations, idempotency semantics, and how to poll the operation.

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

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

Schema description coverage is 0% for two required parameters. The description conveys only that transcriptionId should point at a 'completed transcript'; it says nothing about idempotencyKey's role (deduplicating retries) or the expected tr_ format. The description does not compensate for the documentation gap.

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

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

States a specific verb and resource ('Starts billable AI chapter generation for a completed transcript') plus the return artifact ('durable operation receipt'). It is clearly distinguishable from summarize_transcript or repurpose_transcript by the 'chapters' resource, though it never names a sibling to route against.

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 'for a completed transcript' implies a prerequisite (the transcript must be finished), which is useful implicit guidance. But there is no explicit when-to-use/when-not, no mention of how this differs from summarize_transcript, and no guidance on following up the returned receipt via get_job_status or list_operations.

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, so the safety profile is covered. The description adds real value beyond them: it explains the response varies by state (status now, result when complete, retry delay while queued/running), which tells the agent how to poll.

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

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

One front-loaded sentence with no filler; every clause (status, result, retry delay) conveys distinct information the agent needs to use the tool correctly.

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?

An output schema exists, so return values need not be spelled out, and the description still explains how the response differs across job states. The only real gap is anything about error conditions for an invalid or expired operationId.

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

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

Schema description coverage is 0%, so the description carries the burden for operationId. It implies the parameter must reference a previously started operation, but never states the 'op_' format, where the ID comes from, or what happens on an unknown/expired ID.

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

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

States a specific verb and resource (checks an operation, returns status/result/retry delay) and scopes it to 'previously started' operations, which separates it from list_operations. It does not name a sibling explicitly, so it falls just short of the top mark.

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?

'Previously started' and 'while work is queued or running' make the polling use case clear, and the retry delay hints at the intended loop. There is no explicit when-not guidance or named alternative (e.g. list_operations for enumerating all jobs).

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds valuable security context: media bytes never pass through the model or MCP request. It does not explain authentication prerequisites or handoff lifecycle.

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

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

Two tight sentences front-load the purpose, then add the alternative and the key privacy guarantee. No sentence is wasted.

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

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

With zero parameters, annotations covering safety, and an output schema, the description supplies the key selection and privacy context. It stops short of explaining handoff mechanics, but return-value detail is delegated to the 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?

This tool has zero parameters, so there is no parameter semantics to document. The baseline for a zero-parameter tool is 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 states a specific verb and resource: it returns an authenticated upload page for device-local audio or video not attached to the chat. It also immediately distinguishes the scope from attached-file handling by naming transcribe_file.

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 an explicit use condition (device media not attached to chat) and names an alternative for attached files. However, transcribe_file is not present in the provided sibling list, so the routing guidance may point to an unavailable 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 annotations already establish read-only, idempotent, non-destructive behavior. The description adds a meaningful behavioral/safety note that transcript text is user-supplied recording content, which is useful context beyond the annotations, though it does not discuss pagination termination or result limits.

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

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

Two sentences, front-loaded with the core purpose and followed by a relevant content-safety note. There is no wasted wording.

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

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

The annotations and output schema reduce the description's burden, and it covers scope plus user-supplied-content safety. Still, with four parameters and 0% schema description coverage, it leaves pagination mechanics and parameter behavior too implicit for a fully complete definition.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. 'Bounded page' loosely gestures at cursor/pageSize/characterBudget, but it does not explain cursor semantics, the relationship between pageSize and characterBudget, or the transcriptionId format beyond what the schema already enforces.

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

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

The description states a specific verb and resource: 'Reads a bounded page from a completed transcript.' It clearly scopes the tool to paginated reading of completed transcripts, though it does not explicitly name sibling alternatives such as get_transcript_artifact or export_transcript.

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 'completed transcript' implies the tool should be used only after transcription has finished, and 'bounded page' implies paginated reading. However, there is no explicit guidance on when to choose this over get_transcript_artifact, export_transcript, search_library, or edit_transcript_text.

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 establish a safe, idempotent, closed-world read, so the description correctly spends its words elsewhere: it discloses that results are paged ('one bounded page') and that the payload is untrusted user-derived data — a real security-relevant trait absent from the annotations. It could go further on error behavior when the artifact is missing or not yet generated.

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

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

Two sentences, no filler, with the trust warning placed last as a deliberate caveat. Every clause carries information.

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

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

The output schema means return values need no explanation, but a 5-parameter tool with 0% schema coverage and several similarly named siblings is under-served by two sentences. Key unknowns — when artifacts become readable, how targetLanguage interacts with the artifact enum, how to page with cursor — remain undocumented.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it only partly does: the artifact list in prose loosely maps to the enum, and 'bounded page' gestures at cursor/characterBudget. It says nothing about targetLanguage (presumably required for the translation artifact), cursor semantics, or how characterBudget trades off against page size.

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

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

States a specific verb (reads) and resource (a generated transcript artifact) and enumerates the artifact kinds it can return. It implies a distinction from raw transcript reads via 'completed ... artifact', but never names get_transcript, summarize_transcript, or the other generators it sits alongside.

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

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

No explicit when-to-use, when-not-to-use, or alternative tool is given. 'Completed' weakly implies the artifact must already be generated, and 'one bounded page' hints at pagination, but an agent gets no guidance on choosing this over get_transcript or on what to do when no artifact exists yet.

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 establish readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context: the response is bounded, tenant-scoped, and deliberately excludes transcript text and provider payloads.

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

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

It is a single front-loaded sentence with no wasted language. The key scope and exclusion constraints are stated immediately.

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

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

For a simple read operation with rich annotations and an output schema, the description is nearly complete. The only minor gap is that it does not say where the transcriptionId comes from, but the output schema and annotations cover most remaining needs.

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

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

Schema description coverage is 0%, so the description should compensate, but it only clarifies that the ID refers to one tenant-owned transcription. The schema pattern documents format, but the description does not explain how to obtain the ID or add further parameter-specific meaning.

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

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

The description states a specific verb and resource: reads bounded metadata for one tenant-owned transcription. It also distinguishes itself from transcript-returning siblings by explicitly excluding transcript text and provider payloads.

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 clear context for when to use it: retrieving metadata without pulling transcript text or provider payloads. However, it does not explicitly name alternatives such as get_transcript or get_transcript_artifact, so routing is implied rather than fully spelled out.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description wisely spends its words elsewhere: the URL is 'short-lived' (an expiry trait the agent cannot get from annotations) and 'private'/'tenant-owned' (an access-scoping trait). It does not say what happens if the synthesis is not yet complete, which is the main omitted behavior.

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

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

One sentence, front-loaded with the return value, every clause informative (short-lived, private, completed, tenant-owned). 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?

The output schema means return shape needn't be explained, and annotations cover the safety profile, so the definition is close to adequate. Still missing the failure mode for an incomplete/failed synthesis and any sense of how short-lived the URL is, both of which affect agent retry strategy.

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

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

Schema description coverage is 0%, so the single synthesisId parameter carries no documentation in either place; the description only implies it must identify a finished synthesis. The schema's regex pattern at least constrains format, keeping this at a baseline-3 rather than lower.

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

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

States a specific verb and resource: returns a download URL for a completed TTS synthesis, which is distinct from synthesize_speech (creates it) and list_tts_syntheses (enumerates them). The 'completed' qualifier implicitly separates it from a creation tool, though no sibling is named explicitly.

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

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

'Completed ... synthesis' implies it should be called after synthesis finishes, but it never names the alternatives (get_job_status, list_tts_syntheses) or states the precondition explicitly. An agent must infer when this tool applies versus polling job status.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world semantics, so the burden is light. The description adds one genuinely new behavioral fact — that billing secrets are deliberately excluded from the response — which is useful context for an agent reporting results to a user.

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

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

A single front-loaded sentence covering what is read and what is withheld, with zero filler. Every clause earns its place.

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

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

With no parameters, full annotation coverage, and an output schema defining the return shape, the description carries all the weight it needs to. The privacy note closes the one remaining question about what the response will contain.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is an argument-free read; baseline 4 applies.

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

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

States a specific verb ('Reads') plus concrete resources: the account plan and current transcription, TTS, and translation usage. No sibling tool reports account-level plan/quota data, so the scope is unambiguous against the surrounding list_*/get_* 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?

Usage is only implied by the resource names — an agent can infer this is the place to check quota before transcribe_url or synthesize_speech, but the description never says when to call it or what to do with the result. No alternatives or exclusions are named.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered structurally. The description's only added fact is that results are scoped to the connected account ('available to the connected account'), which is useful but minimal; nothing is said about ordering, completeness, or what a 'bounded' pack means.

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

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

A single front-loaded sentence with the verb and resource up front and no filler. The word 'bounded' is the only questionable token, adding ambiguity rather than information.

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

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

For a no-parameter read tool with a full output schema and rich annotations, the description covers the essentials of what it does. It is nonetheless thin in that it never defines what a creator pack is or how it relates to templates, leaving an agent to discover the return shape from the output schema alone.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies; there are no parameter semantics the description needs to compensate for.

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

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

States a specific verb ('Lists') and resource ('creator packs') scoped to the connected account, so the operation is unambiguous. However, it offers no differentiation from the sibling 'list_creator_templates', and the terms 'bounded' and 'Wisprs' are unexplained jargon that adds no discriminating information.

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

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

There is no guidance on when to call this versus the many other list_* siblings, and in particular no signal distinguishing creator packs from creator templates. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description's only added context is that templates carry 'outcomes they produce' and are 'bounded' — the first hints at return content, the second is opaque terminology that adds little usable understanding.

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

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

A single front-loaded sentence with no filler; the verb and resource come first. It is efficiently sized, though brevity tips into under-specification on 'bounded'.

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, return values need not be described, and the read-only annotations cover safety. However, for an enumerating tool sitting beside list_creator_packs, the description leaves a real disambiguation gap and an unexplained term, so an agent still has open questions.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline applies. Nothing in the description misrepresents or conflicts with the empty 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 verb+resource (list creator templates) is clear, but the qualifier 'bounded' is unexplained and the description never distinguishes this tool from the sibling list_creator_packs. An agent can guess the resource but cannot confidently separate templates from packs based on the text.

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

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

There is no statement of when to use this tool, when not to, or which sibling (notably list_creator_packs) to prefer in which situation. Usage must be inferred entirely from the name.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context by saying it returns a bounded page and live media counts but not folder contents. It does not discuss auth requirements or rate limits, but for this read-only listing tool the added scope detail is substantial.

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

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

The description is a single efficient sentence. The core purpose and scope are front-loaded, and the exclusion is stated without waste. Every phrase contributes useful information.

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

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

For a simple read-only two-parameter listing tool with an output schema and rich annotations, the description covers the essential behavior and exclusion. It is slightly incomplete because pagination behavior and parameter semantics are not explained, but the output schema reduces the need to describe return values.

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

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

Schema description coverage is 0%, so the description must compensate for cursor and pageSize having no documented semantics. It only hints at pagination with 'bounded page' and says nothing about cursor format, page-size limits, or default behavior. This is insufficient for the undocumented parameters.

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

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

The description uses a specific verb and resource: it lists folders. It also states the scope (bounded page), the data returned (live media counts), the tenant context (connected Wisprs tenant), and an explicit exclusion (without returning folder contents). This distinguishes it from content-returning or folder-mutating siblings such as search_library, create_folder, and delete_folder.

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 the tool is for folder metadata and counts rather than folder contents, which is useful selection context. However, it does not explicitly say when to use this instead of siblings such as search_library or how to handle cross-tool workflows. The usage guidance is therefore implied rather than explicit.

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

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the description's job is to add beyond that — and it does, by disclosing the redaction guarantee: no meeting URLs or provider payloads are exposed. It stops short of describing pagination behavior or whether results are ordered, which would matter for a bounded list.

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

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

One dense sentence with the resource and the output scope front-loaded, and no filler. It is arguably over-compressed given how much filtering semantics it leaves out.

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?

An output schema exists, so return shape need not be explained here, and annotations carry the safety profile. But for a filtered list tool with a free-form `status` string, the description leaves the agent unable to construct a correct call or know how to page through results.

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 mentions neither parameter. Most importantly, `status` has no enum and no description, so the agent has no idea what values are legal; `pageSize` (default 25, max 50) is also unmentioned. The single word "bounded" gestures at paging but does not compensate for the coverage gap.

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

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

Clear verb+resource ("Lists bounded meeting capture status for the connected tenant") and it scopes the output (consent state, transcript availability) without restating the name. It does not name any sibling, so an agent must infer on its own that list_transcripts is a different list and cancel/schedule_meeting_capture are the mutating counterparts.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisite (e.g. an active connection/tenant), and no named alternative. The agent is left to infer that this is the read-side counterpart of schedule_meeting_capture purely from the name.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds that results are per-authenticated-user and 'bounded', but leaves 'bounded' unexplained — the agent cannot tell whether that means a fixed cap, a page-size cap, or no pagination beyond one call.

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

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

One front-loaded sentence with no filler. It is efficient, though the brevity contributes to the missing detail rather than trading off against it.

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

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

An output schema exists, so return shape needn't be explained, and annotations cover safety. What is missing is the practically important behavior: how 'bounded' interacts with pageSize and the absence of any continuation parameter, which determines whether the agent can retrieve all notifications.

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 single parameter (pageSize, default 20, max 50) is never mentioned in the description. The schema carries type/default/min/max structurally, but nothing explains paging semantics — notably that there is no cursor/offset parameter, so one call cannot be continued.

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

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

States a specific verb and resource ('Lists ... notifications') plus scope ('for the authenticated user', 'in-app'). It is clearly distinct from the only nearby sibling, mark_notifications_read, but the description never explicitly differentiates itself.

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

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

There is no guidance on when to call this versus alternatives (e.g., mark_notifications_read) or on preconditions such as whether unread filtering exists. Usage is only implied by the verb 'Lists'.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that request payloads, source URLs, provider responses, and secrets are never returned, which is valuable privacy/scope information 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 efficient sentences, with the core purpose front-loaded and the data-exclusion note immediately after. No filler or repetition.

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

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

The presence of an output schema and rich annotations reduces what the description must cover. However, for a tool with two optional parameters and 0% schema description coverage, the description omits any invocation guidance about filtering by status or pagination, leaving a meaningful gap.

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

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

Schema description coverage is 0%, and the description does not mention the status filter or pageSize/pagination parameters at all. The schema still shows the status enum and pageSize default/max, but the description adds no meaning beyond those bare 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?

States a specific verb and resource: 'Lists bounded operation history for the connected tenant.' It is clear what the tool returns, but it does not differentiate itself from siblings such as get_job_status or other list_* 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 gives no explicit guidance on when to use this tool versus alternatives like get_job_status or other listing tools. Usage is only implied by the phrase 'operation history.'

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description contributes one genuinely useful trait — that credentials and private account fields are withheld from results — but says nothing about ordering, pagination, or whether all members are returned.

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

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

A single well-formed sentence with no filler and the core purpose front-loaded. Slightly more of the sentence is spent on what is excluded than on what is returned, but nothing is wasted.

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

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

An output schema exists, so return values need not be described. However, for a paginated list tool the description never addresses the pageSize parameter or what happens when results exceed 100, leaving a meaningful operational gap.

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

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

There is one parameter (pageSize, max 100, default 50) and its schema description coverage is 0%, so neither the schema nor the description explains it. The description does not mention pagination at all, leaving the only knob an agent can turn undocumented.

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

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

States a specific verb and resource: lists members of the authenticated workspace. No sibling tool covers member listing, so the absence of explicit differentiation is not a real problem, but the scope is also not narrowed (no filter or ordering hints).

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

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

There is no guidance on when to use this versus other list_* tools, no prerequisites, and no mention of pagination behavior. The phrase 'authenticated workspace' only implies that auth is required, which the agent would assume anyway.

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 provides valuable behavioral details like 'bounded previews and delivery status.' This informs the agent about the specific data points returned, complementing the structural safety hints provided in the annotations.

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

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

The description is a single, highly efficient sentence that packs the resource type, scope, and data features into minimal space.

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 the output schema exists, the description is complete enough by defining the scope and the nature of the included information (previews and status) for an agent to correctly invoke and interpret the results.

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. It mentions 'bounded previews,' which implies the need for pagination control, but it does not explicitly define the role or expected range of the 'pageSize' parameter 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 defines the resource (support tickets), the action (lists), and the scope (the connected user’s own tickets), which effectively differentiates it from sibling tools like create_support_ticket.

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?

While the 'user's own' qualifier provides a scope for usage, the definition does not explicitly state when to use this tool over other potential list or search mechanisms.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context by disclosing that results are a bounded (paginated) page scoped to the connected tenant, though it says nothing about cursor lifetime, ordering, or what happens when the page is exhausted.

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

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

A single front-loaded sentence that names the resource, the pagination trait, and the filter surface with no filler. Every clause carries information.

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

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

An output schema and complete annotations reduce what the description must do, and the enumeration semantics are conveyed. Gaps remain around pagination usage (cursor/pageSize behavior) and the distinction from search_library, which matters in a sibling set this large.

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

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

Schema description coverage is 0%, so the description carries the burden, and it covers three of five parameters (status, folderId via 'folder', includeDeleted via 'deleted state'). It says nothing about cursor or pageSize, leaving the two pagination parameters defined only by their types and 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?

States a specific verb and resource ('Lists a bounded page of transcripts') plus the tenant scope and the three filter dimensions, which clearly separates it from single-item siblings like get_transcript. It never names search_library, so the boundary against fuzzy search must be inferred.

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 mention of status/folder/deleted filtering implies the browsing-and-filtering use case, but there is no explicit when-to-use and no reference to alternatives such as search_library or list_folders. An agent must infer that this is the enumeration path rather than the search path.

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 read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-redundant behavior: results are bounded, text is a short *untrusted* preview (a useful prompt-injection caveat), and audio is not retrievable here without separate authorization.

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

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

Two tight sentences with the scope and the untrusted-preview caveat front-loaded; no filler and no repetition of the title 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?

An output schema exists so return shape needn't be explained, and the annotations carry the safety profile. What remains missing is the filter/pagination story (status values, pageSize limits), which is the main thing an agent needs beyond the bare call signature.

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 neither parameter is addressed: the status enum (pending/processing/completed/failed) and pageSize (1-50, default 25) are undocumented in both schema and description. 'Bounded' hints at a result cap but never explains the pageSize knob or how status filtering changes results, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (lists) and resource (text-to-speech history) plus scope (bounded, connected tenant), which cleanly separates it from synthesize_speech, get_tts_audio and list_tts_voices. It does not explicitly name those siblings, so an agent must infer the boundary from the resource name alone.

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

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

Usage is implied rather than stated: this is the browse/history tool, and the clause 'audio delivery remains private and separately authorized' softly points an agent elsewhere for audio. There is no explicit when-to-use or when-not-to-use guidance, nor any mention of how it relates to get_tts_audio or get_job_status for tracking a synthesis.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's value is in the extras it adds: results are bounded, filtered by the tenant's plan, limited to active voices, and identified by opaque tenant-scoped handles rather than raw provider IDs. That is meaningful context an agent could not derive from the schema. Pagination behavior is left unstated despite the pageSize parameter, keeping it off a 5.

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

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

One front-loaded sentence with no redundant restatement of the title. It is dense with qualifiers ('bounded', 'plan-filtered', 'tenant-scoped opaque') but every phrase carries information rather than padding.

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

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

An output schema exists so return values need not be explained, but for a paginated listing tool the description omits how paging works (whether pageSize alone is sufficient or a cursor/next-token is returned) and how a caller should proceed from returned handles to synthesize_speech. Adequate but with clear gaps for a discovery 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% and the description mentions none of the three parameters — the language filter, the provider enum, or pageSize. The names are largely self-explanatory and the enum is in the schema, but 'plan-filtered' is the only filtering concept the description surfaces, so it does not compensate for the coverage gap.

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

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

States a specific verb (Lists) and resource (text-to-speech voices) with useful qualifiers: 'bounded, plan-filtered', 'active', 'tenant-scoped'. This distinguishes it from synthesize_speech, get_tts_audio, and list_tts_syntheses, which are about synthesis/audio retrieval rather than voice discovery.

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

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

Usage is only implied — an agent can infer this is the lookup step before calling synthesize_speech, but the description never says so explicitly. It also does not state when not to use it versus list_tts_syntheses or get_tts_audio, and gives no prerequisite context about plan eligibility beyond the adjective 'plan-filtered'.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral information: signing secrets and delivery payloads are redacted in the response, which tells the agent it cannot retrieve those fields here. Pagination behavior remains unstated.

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

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

A single front-loaded sentence with zero filler; the scope and the redaction caveat are packed into one efficient line.

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?

An output schema exists so return values needn't be explained, and annotations cover the safety profile. However, the sole parameter is undocumented anywhere, and there is no hint of whether results are paged or how to fetch further pages — a real gap for a list tool with a pageSize input.

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

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

There is one parameter (pageSize) and schema description coverage is 0%, so the description carries the burden of documenting it — but it never mentions pagination, page size, or any bounds. The agent learns nothing about the only input beyond the raw schema, and no default/maximum behavior is contextualized.

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

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

States a specific verb (Lists) and resource (webhook endpoints) scoped to the authenticated user, which clearly separates it from the create/update/delete webhook siblings. It does not explicitly name an alternative, but the operation is unambiguous.

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

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

Usage is only implied by the verb 'Lists'; there is no statement of when to call this versus siblings like update_webhook_endpoint or delete_webhook_endpoint, nor any prerequisite or exclusion. Acceptable for a simple listing tool but adds no routing guidance.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=false), so the description's job is to add context. It adds the tenant-scoping and the all-vs-selected behavior, but says nothing about reversibility, what happens when notificationIds exceeds the 50-item cap, or how the two parameters interact when both are supplied. The 'marks read' framing also sits in mild tension with destructiveHint=true without explaining why the operation is flagged destructive.

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

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

A single well-formed sentence that front-loads the verb and resource and places the bulk-mode condition where it is immediately visible. No filler, no restatement of the title.

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

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

An output schema and annotations carry much of the load, so the description needn't explain returns or safety. Still, for a destructive default-parameterless mutation it leaves the parameter-interaction rule and the practical path (list_notifications → IDs) unstated, which is a meaningful gap.

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

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

Schema description coverage is 0%, so the schema documents no parameter meaning beyond types, defaults and a regex. The description rescues the most important semantics of 'all' (mark every currently unread notification) but never addresses notificationIds' format (ntf_ prefix), the 50-item limit, or which of the two parameters wins when both are provided.

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

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

States a specific verb ('Marks ... read') and resource ('tenant-owned notifications') with two explicit modes: selected IDs or all unread. The two operational modes are clear, but it never references the sibling list_notifications that an agent would need to obtain notification IDs.

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

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

Usage is only implied: the 'all is true' branch signals a bulk-marks-everything path, and the selected-IDs path implies the caller already has IDs. There is no explicit when-to-use guidance, no warning about the breadth of the all=true path, and no pointer to list_notifications as the way to source IDs.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior — that omitting folderId silently removes the transcript from folders rather than erroring — but it is silent on whether a move replaces all existing folder memberships and on the purpose of idempotencyKey for safe retries.

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

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

A single sentence, front-loaded with the primary action, where every clause carries information. Nothing is padded or redundant.

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

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

An output schema exists, so return values need not be described. However, for a destructive move with an undocumented idempotencyKey and an ambiguous multi-folder model, the description leaves meaningful questions unanswered before an agent can call it confidently.

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

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

Schema description coverage is 0% across 3 parameters, so the description must compensate. It does explain folderId's omission semantics, which the schema cannot express, but idempotencyKey goes entirely unexplained and transcriptionId is only implied by 'transcript'.

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

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

Names a specific verb (move) and resource (transcript → folder), and also states the inverse behavior when folderId is omitted. No sibling tool performs this operation, so it is distinguishable by name and description, though it does not explicitly contrast itself with any sibling.

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

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

The description implies the use case (assign or clear a transcript's folder) and reveals the omit-to-remove path, but offers no explicit guidance on prerequisites such as looking up a valid folderId via list_folders, or on when to prefer this over rename_transcript or other file-management siblings.

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

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

The annotations already declare mutation, idempotency, and destructive potential, but the description adds useful context: the operation is durable, tenant-scoped, and does not alter folder contents. It could still say more about rename semantics such as collision handling, but it substantially clarifies the behavioral impact.

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

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

A single front-loaded sentence that states the action, scope, and key behavioral constraint with no wasted wording.

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

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

The description covers the core rename behavior and safety context, and an output schema exists. However, it omits that the schema also supports changing color, and it leaves all parameter meanings unexplained, so an agent cannot fully understand invocation details from the description alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only weakly implies a name via 'Renames' and an idempotency key via 'idempotent', while completely omitting the folderId format and the undocumented color 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 states a specific verb and resource: renames one tenant-owned media folder. It is clearly distinguishable from siblings such as rename_transcript, create_folder, delete_folder, and move_transcript_to_folder.

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 identifies the object type but gives no guidance on when to choose this tool versus related folder tools, nor any prerequisites such as needing an existing folderId or handling name conflicts. Usage is only implied by the tool name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds useful optimistic-concurrency context ('expected revision prevents overwriting a newer edit') and durable idempotency, but it does not state failure behavior on revision mismatch or any permission/auth requirements.

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

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

Two sentences, front-loaded with the action and scope, followed by the key concurrency constraint. No sentence is padding.

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

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

This is a destructive mutation with four required parameters and no output-schema explanation needed, but the description covers only one parameter's semantics and omits error/conflict behavior. For a destructive tenant-owned operation with 0% schema description coverage, this is under-specified.

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

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

Schema description coverage is 0%, so the description must compensate. It only explains expectedRevision; it says nothing about the purpose or constraints of idempotencyKey, the format or scope of transcriptionId, or the bounds on name.

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

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

The description states a specific verb and resource: 'Renames one tenant-owned transcript'. Scope is clear, but there is no differentiation from nearby mutation siblings such as edit_transcript_text, move_transcript_to_folder, or rename_folder.

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 no guidance on when to use this tool versus alternatives, nor any when-not conditions. The mention of expectedRevision implies a concurrency-safety use case but does not route the agent between rename and edit operations.

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 real value beyond annotations: 'billable' discloses a cost consequence that no annotation encodes, and 'starts' signals asynchronous kickoff (implying polling via get_job_status). 'Idempotent' merely restates idempotentHint, and the description never explains what makes the call destructive (destructiveHint: true) or what the openWorld access entails.

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

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

A single tightly-packed sentence with no filler; cost and idempotency are front-loaded as qualifiers on the verb.

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?

Output schema exists, so return values need not be explained, and the async+billable framing is present. But for a destructive, open-world mutation with zero parameter documentation, the description should say what mode options produce and what happens on idempotencyKey reuse — that gap is material.

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

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

Schema description coverage is 0%, so the description carries the full burden for all three required parameters and discharges none of it: no explanation of the idempotencyKey reuse/conflict contract, no description of the mode enum values or their outputs, and no note on the transcriptionId format beyond the regex.

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

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

States a specific verb ('Starts') and resource ('content transformation for a completed transcript'), plus the prerequisite that the transcript must be completed. However, 'content transformation' is vague about what is actually produced — the mode enum (show-notes, thread, blog, quotes) is nowhere reflected in the description — and it does not differentiate itself from nearby siblings like summarize_transcript or export_transcript.

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

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

No explicit when-to-use or when-not-to-use guidance and no named alternative. The only implicit routing cue is 'completed transcript', which implies an eligibility precondition, but an agent choosing among summarize_transcript, export_transcript, translate_transcript and this tool gets no help.

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

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

Annotations already declare non-read-only, destructive, open-world, and idempotent behavior. The description adds useful context about explicit confirmation, retained source media, and a durable operation receipt, but it does not explain what destructive effect the retry may have or what happens if source media is unavailable.

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 tight sentences with no waste. The core action and scope are front-loaded, followed by the confirmation condition and return behavior.

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?

An output schema exists, so return-value detail is not required. However, for a destructive, idempotent retry operation with three required parameters and zero schema descriptions, the description should clarify idempotency and destructive implications more fully.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It implies transcriptionId and confirm through “one failed tenant-owned transcription” and “explicit confirmation,” but does not mention idempotencyKey at all, leaving a required and structurally constrained parameter unexplained.

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

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

The description states a specific verb and resource: requeue one failed tenant-owned transcription from retained source media. This is precise enough to distinguish it from transcript-reading, creation, and URL-transcription siblings.

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

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

It clearly establishes the context: only failed tenant-owned transcriptions with retained source media, and only after explicit confirmation. It does not explicitly name when to choose alternatives such as transcribe_url or get_job_status, so it falls short of full routing guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely covered. The description adds useful scope with 'tenant-owned transcript' and 'active public share link', plus a hint that confirmation is required, but it does not explain failure behavior or the effect on recipients.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action and scope immediately, and the trailing phrase about a durable confirmed operation remains relevant.

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 a destructive mutation with required confirm and idempotency parameters, but annotations and the output schema carry substantial context. The description is minimally adequate, though it omits parameter-specific guidance and edge-case behavior for an operation that revokes a public link.

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

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

Schema description coverage is 0% across three required parameters. The description indirectly hints at the transcript being affected and a confirmed operation, but it does not explain the idempotencyKey or the meaning of transcriptionId beyond 'one transcript', leaving most parameter semantics undocumented.

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

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

The description gives a specific verb, 'Revokes', and a specific resource, 'the active public share link for one tenant-owned transcript'. This clearly distinguishes the tool from its sibling create_share_link and from unrelated transcript 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?

Usage is implied by the phrase 'active public share link', which suggests the tool applies when such a link exists. However, the description does not explicitly state when to use this tool, when not to use it, or name alternatives.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the bar is lower. The description adds two things annotations don't cover: the consent attestation precondition and the fact that a durable operation receipt is returned, which points the agent to list_operations for follow-up.

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

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

Two short sentences with zero filler; the consent precondition and the return behavior are both front-loaded rather than buried.

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

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

A six-parameter destructive mutation with no annotation-free safety net and 0% schema description coverage needs more than this. Output format is covered by the output schema, but nothing explains what the meeting agent actually does once scheduled, how announce affects the call, or how to recover the receipt.

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 names no parameter. 'Recording consent' loosely implies consentAttested and 'durable operation receipt' hints at idempotencyKey, but startsAt, announce (default true), and title get nothing, and no format expectations are set.

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

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

Specific verb plus resource: 'Schedules a Wisprs meeting agent.' An agent can tell this apart from cancel_meeting_capture by the verb alone. No explicit sibling named, so it stops short of a 5.

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

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

It states one hard precondition, 'after explicit recording consent,' which is genuine usage context. But it gives no when-not, no alternatives, and no hint that cancel_meeting_capture or list_meeting_sessions are the companion calls.

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 establish a safe read-only, idempotent, non-destructive operation. The description adds useful behavioral context: it is scoped to the connected account and returns bounded ranked snippets rather than full transcripts. It does not cover pagination or rate limits, but it adds meaningful context beyond the annotations.

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

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

A single front-loaded sentence with no filler. It states scope and result type immediately and does not waste space.

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 output schema covers return values and annotations cover safety, but the description leaves all three input parameters unexplained, including cursor pagination. For a search tool with zero schema description coverage, this is incomplete for reliable invocation.

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

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

Schema description coverage is 0%, and the description provides no semantics for query, limit, or cursor. The word 'bounded' hints at a result cap but does not explain parameter behavior. With three undocumented parameters, the description fails to compensate.

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 ('Searches') and states the scope ('only the connected Wisprs account') and result form ('bounded ranked snippets, not complete transcripts'), which distinguishes it from full-transcript retrieval. It stops short of naming a sibling tool, so it is clear but not maximally differentiating.

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 the tool is for snippet search within the connected account and signals that full transcripts are handled elsewhere, but it never states when to choose this over list_transcripts or get_transcript. Usage is inferable rather than explicit.

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

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

Goes meaningfully beyond the annotations by disclosing that the call is billable, that it only starts the work rather than completing it, and that the returned receipt is durable — cost and async semantics are not encoded anywhere in the structured fields. What's missing is the operational consequence: whether the result must be polled and via which tool. Note the tension between the constructive framing and destructiveHint=true, though the description does not assert anything the annotation directly forbids.

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

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

A single tight sentence with the key facts front-loaded: cost, action, precondition, and return type. No filler, no repetition of the title.

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

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

The output schema covers the receipt, so return values needn't be spelled out, and the input schema covers validation. But for an async 'start' tool with a billable side effect, the description omits the most decision-relevant fact — how to obtain the finished summary and whether the call is retryable against an existing key.

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

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

Schema description coverage is 0%, so the description carries the full burden for both parameters and does not mention either. 'Durable operation receipt' hints loosely at why an idempotencyKey exists, but nothing explains the transcriptionId's expected format or what idempotency scope means in practice (per-transcript? per-key collision behavior?).

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

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

States a specific verb and outcome ('Starts a billable AI summary') on a specific resource ('a completed transcript') plus a return shape ('durable operation receipt'). An agent can tell it produces a summary rather than raw text, but it never distinguishes itself from nearby summarization-adjacent siblings like generate_chapters, translate_transcript, or repurpose_transcript.

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 'for a completed transcript' supplies a real precondition (the transcript must already be transcribed), which is more than most tools offer. However, it gives no explicit when-not guidance and never names the follow-up or alternative tools (get_job_status, list_operations, get_transcript_artifact), leaving the agent to infer the rest of the flow.

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 non-read-only, destructive, idempotent, and open-world behavior. The description adds value beyond them by disclosing that the job is 'metered' (cost/quota implications) and that voice handles must be plan-authorized, plus that the return is a durable operation receipt. It stops short of stating rate limits, failure/retry behavior, or why the destructive flag applies.

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

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

A single front-loaded sentence with no filler; every clause (metered, plan-authorized, receipt) carries information an agent would not get from the schema.

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

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

The existence of an output schema relieves the description of explaining return values, but for a 9-parameter mutation with zero schema description coverage, the definition leaves the agent without parameter meaning, cost expectations, or the follow-up polling/retrieval path. That is a substantial gap for a costly, side-effecting operation.

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

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

Schema description coverage is 0% across 9 parameters, so the description carries the full burden and largely fails: it never mentions text length limits, speed/style/stability/similarityBoost/useSpeakerBoost tuning knobs, or language. Only voiceId and idempotencyKey are obliquely hinted at through 'plan-authorized voice handle' and 'durable operation receipt'.

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 precise verb+resource ('Starts a ... text-to-speech job') and adds key scope details (metered, plan-authorized voice, returns an operation receipt). The phrase 'starts a job' clearly distinguishes it from its read-only siblings like get_tts_audio and list_tts_syntheses.

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 versus alternatives such as list_tts_voices (to obtain a valid voice handle) or get_job_status/get_tts_audio (to retrieve results). The mention of 'plan-authorized voice handle' implies a prerequisite but does not name the tool or condition that satisfies 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?

Adds context beyond annotations: the operation is 'billable', requires a public HTTPS URL, is asynchronous, and returns a receipt immediately. The cost/billing disclosure is critical and nowhere in the annotations. Combined with destructiveHint/openWorldHint annotations, this is strong coverage.

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

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

Two tight sentences, front-loaded with the action, followed by the async receipt behavior. The docs link is a reasonable pointer. No wasted clauses.

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 and rich annotations covering safety and idempotency, the description is mostly adequate. But for a 4-param tool with 0% schema description coverage, leaving language/displayName semantics unexplained and the idempotencyKey format unclear keeps it from being 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?

Description adds meaning to url ('one public HTTPS media URL'), which is genuinely useful. However, the required idempotencyKey is unexplained (though idempotentHint annotation helps), and language/displayName are entirely undocumented — a real gap at 0% schema coverage across 4 params.

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

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

Specific verb+resource: 'starts a billable transcription from one public HTTPS media URL' via the Wisprs jobs API. Clear what the tool does. It doesn't explicitly differentiate from siblings like retry_transcription or get_job_status, but 'starts' implies initiation rather than polling.

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?

Tells the agent this kicks off async work — 'returns a durable operation receipt immediately. The transcript is ready when the operation completes' — which implies subsequent polling. But there is no explicit when-to-use vs. retry_transcription or get_job_status, and no stated prerequisites (account, quota).

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

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

Annotations already declare the write/cost/destructive profile and idempotency. The description adds genuinely new context with 'billable' and the 'completed' prerequisite, but leaves the async nature implicit — it 'starts' something yet never says a job is created and must be polled.

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

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

A single tight sentence: verb, cost note, precondition, and target format all front-loaded with no filler.

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

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

An output schema exists so return values need no explanation, but for a billable, asynchronous, idempotent mutation the description omits job-tracking behavior, what idempotencyKey dedupes, and any confirmation of what 'completed' means.

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% across three required parameters. The description clarifies only targetLanguage (BCP-47) and hints at transcriptionId; idempotencyKey — a required 16-128 char key with a regex — is never explained, so the description does not compensate for the schema gap.

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

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

States a specific verb and resource ('starts a ... translation of a completed transcript') plus a target, which clearly separates it from summarize_transcript and repurpose_transcript. It doesn't name a sibling explicitly, so it falls just short of a 5.

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

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

'completed transcript' implies a precondition (the source must already be transcribed), but there is no explicit guidance on when to choose translation over repurpose_transcript or summarize_transcript, and no mention that the started job must be tracked via get_job_status.

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

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

Annotations already declare destructive, idempotent, open-world, and non-read-only behavior. The description adds meaningful context beyond those annotations: authorization is required, SSRF-safe DNS validation is performed, and the call returns a durable operation receipt.

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 states the action, scope, prerequisites, and return behavior without obvious filler. The documentation link is optional but does not meaningfully harm 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?

The tool is a destructive, idempotent mutation with an output schema, and the description covers prerequisites and return behavior reasonably well. However, it omits required parameter semantics, so an agent cannot fully determine how to invoke it from the description alone.

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

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

Schema description coverage is 0%, so the description should compensate by explaining the parameters. It mentions that URL or active state can be updated, but it does not explain the required endpointId or idempotencyKey semantics, leaving two required parameters undocumented.

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

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

The description states a specific verb (Updates), resource (tenant-owned Wisprs webhook), and scope (URL or active state). It is clearly distinguishable from siblings such as create_webhook_endpoint, delete_webhook_endpoint, and list_webhook_endpoints.

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 clear context and prerequisites: the endpoint is tenant-owned and the update occurs after authorization and SSRF-safe DNS validation. It does not explicitly name alternatives or exclusions, but the operational context is sufficient to select it over create/delete/list siblings.

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