Lazybird

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

Beyond the annotations (readOnly=false, idempotent=false, destructive=false), the description discloses two important traits: the call consumes characters from the user's balance (minimum 50) and the generated voice is not saved. It does not cover latency, failure modes, or rate limits, so it stops short of full behavioral disclosure.

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

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

Three tight sentences, front-loading the core action, then the cost constraint, then the persistence caveat. No wasted words and every sentence earns its place.

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

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

Covers what an agent needs to call it correctly: cost, non-persistence, and the sampleUrl handle for the follow-up save_voice call. With no output schema present, the return shape beyond sampleUrl is left implicit, which is the only notable gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a useful hint that the 'description' parameter should encode age, gender, accent, tone and energy, which goes slightly beyond the schema's single example, but it adds nothing about 'language' or the 'text' 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: create a brand-new AI voice from a description and hear a sample line. It also distinguishes itself from the sibling save_voice by explaining that this tool does not persist the voice, so an agent can tell the two apart without opening 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?

Gives clear use cases (character, brand, narrator) and an explicit follow-up path: call save_voice with the returned sampleUrl to keep the voice. It does not contrast with generate_speech or search_voices, so alternatives are only partially mapped.

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: annotations only say it is a non-readonly, non-idempotent, non-destructive write, while the description discloses the cost model (one character of balance per character of text), the 5000-character hard limit, and the output format (MP3 link). Non-idempotency is implied by the per-call billing but not stated outright, which keeps it short of 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?

Front-loaded with the primary outcome (voiceover plus MP3 link), then cost, then the size limit and workaround. Dense but every clause carries information; the 'play, download or put in a video, podcast, ad or course' list is slightly illustrative padding but harmless.

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

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

No output schema exists, and the description compensates by describing the return value (a link to an MP3). With a fully documented schema and clear mutation annotations, only minor gaps remain — e.g. latency, error behavior when balance is insufficient, or whether the link expires.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only the cost implication of 'text' (each character debits the balance) and restates the 5000-length cap already present as maxLength; it says nothing extra about voiceId, locale, speed or instruction.

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 ('turn a script into a ready-to-use voiceover') and names the concrete artifact produced — a link to an MP3 — so the agent knows exactly what comes back. This is clearly distinct from the sibling tools (design_voice, search_voices, save_voice), which do not synthesize audio.

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 context is implied rather than stated: the mention of Lazybird voices and the 'search_voices' reference in the schema indicate the lookup-then-generate workflow, and 'split longer scripts into parts' tells the agent what to do past the 5000-character cap. However, it never explicitly says when to use this versus design_voice or save_voice, and gives no exclusions or prerequisites (e.g. voice must already exist).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds genuinely new context: which fields come back and that the character allowance resets. It does not mention whether output is cached/live or how the reset timestamp is formatted, so it adds some but not rich behavioral context.

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

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

One short sentence, front-loading the resource and the returned fields with no filler. The phrasing 'characters used, left and when the allowance resets' is slightly awkward to parse, which is the only blemish.

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

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

There is no output schema, so the description carries the burden of describing return values — and it does list the relevant fields (email, plan, usage, remaining, reset). For a no-parameter, read-only tool with full annotation coverage, that is close to complete; only output formatting details are absent.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the schema is trivially complete. Baseline 4 applies; the description correctly avoids inventing inputs.

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

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

The description names the exact resource (the connected Lazybird account) and enumerates the returned fields: email, plan name, character usage and remaining allowance, and reset timing. An agent knows this is an account/quota lookup rather than a speech or voice operation. It lacks an explicit verb and does not name a sibling, but the sibling tools (voice, speech) are clearly unrelated, so disambiguation is not really needed.

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

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

There is no explicit when-to-use statement, but with zero parameters and an obvious read-only account resource, the intended use (check plan/quota before generating speech) is strongly implied. Nothing warns about when not to call it, e.g. no need to call it repeatedly, but the implied context is clear enough.

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

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

Annotations already declare this as a non-read-only, open-world, non-idempotent write, so the description is not obligated to re-state that. It adds real behavioral context the annotations lack: the operation consumes one of the account's voice slots (a quota consequence) and requires an explicit user-confirmed rights gate before setting rightsConfirmed. It does not say what happens on failure or whether a slot is consumed by a rejected sample.

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 purpose and input provenance, then the consent constraint and slot consumption. Every clause carries actionable information; nothing is redundant with the title or schema.

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

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

For a three-parameter write tool with no output schema, the description covers what the tool does, what inputs are acceptable, the legal/consent precondition, and the resource cost (voice slot). An agent has everything needed to decide to call it and how to prepare the arguments.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description meaningfully enriches sampleUrl beyond the schema's 'https link to the audio sample' by specifying acceptable provenance, duration (10-60s), single-speaker requirement, and formats (MP3, WAV, OGG). It also clarifies that rightsConfirmed must only be set after the user actually confirms, which is stronger than the schema's constant note.

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 ('Add a voice to the user's Lazybird account from an audio sample') and immediately distinguishes it from the sibling design_voice by describing that tool's output as one valid input source. An agent can tell save_voice (persists a voice) apart from design_voice (creates one) without opening 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?

Gives concrete selection conditions: use this when you have either a design_voice result or a public link to a 10-60 second single-speaker recording, and it states the consent gate for cloning a real person's voice. It does not address what to do when the sample fails those constraints or how it relates to search_voices, so it is clear context rather than exhaustive 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the corpus composition (public catalog vs. own/team voices), the return payload (voice ids, avatar images, preview audio links), and the cursor-based pagination model. It does not mention result-count caps or per-section limits, but limit is documented in the schema.

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

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

Three sentences, front-loaded with what the tool searches and immediately followed by filters, return payload, and pagination. Every clause carries information; no restatement 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?

For an 8-parameter, zero-required search tool with no output schema, the description still conveys corpus scope, filterable axes, the shape of results, and how to page. It omits default behavior when no filters are supplied and the default section, which an agent may still need to infer from the schema.

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

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

Schema coverage is 88%, so the baseline would be 3, but the description adds meaning the schema does not: the free-text query covers use-case words such as "narrator" or "ad", and the section parameter is the prerequisite for continuing a paged search. It says nothing extra about labels or sort, but those are self-documenting in the schema.

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

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

States a specific verb and resource ("Find the right voice") and then defines the searchable corpus precisely: the 500+ voice public catalog plus the user's cloned/designed voices and team-shared ones. It also distinguishes the tool's role from siblings by naming generate_speech as the downstream consumer of the returned voice 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 clear from "Find the right voice for a voiceover" and the hand-off to generate_speech, and it explains how to continue paging (pass section plus the returned cursor). There are no explicit exclusions, so it does not tell the agent when to prefer design_voice or save_voice instead, which is the only gap.

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