Audexum

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 structurally. The description still adds non-obvious operational context: it spends no credits and takes no arguments, which matters for a metered speech service and is not derivable from the annotations. It doesn't discuss rate limits or staleness, but the gaps are minor.

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

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

Three short sentences, front-loaded with the returned fields, then usage triggers, then behavioral guarantees. Every sentence carries distinct information with no repetition of the title or name.

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?

Although an output schema exists (so return values need not be re-explained), enumerating the fields is cheap and helps the agent decide whether to call it for a given user question. Combined with clear triggers, siblings, and the free/read-only guarantee, the definition is sufficient to call correctly with no follow-up 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; the closing 'Takes no arguments.' is a useful confirmation rather than filler. Baseline of 4 for a zero-param tool is warranted.

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 ('Check') and resource ('the signed-in user's Audexum account') and enumerates exactly what is returned: plan, credits_left, usage_percent, period_resets, V4 availability, pricing link. It also implicitly separates itself from audexum_guide by scoping this tool to the live account rather than plan/cost reference material.

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 three concrete trigger conditions (before a long generate_speech/transcribe job, when the user asks about remaining credits, after an insufficient-credits error) and routes the agent elsewhere for adjacent needs ('For what plans include or cost, use audexum_guide; to upgrade, give the user pricing_url'). This is explicit when-to-use plus named alternatives.

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

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

Annotations already declare this is a safe, idempotent, closed-world read, so the safety burden is lifted. The description adds useful scope context by enumerating what the guide covers (engines, voices, limits, price, products, plans, credit packs). It stops short of distinguishing content that may go stale or differ from live account data.

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

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

Three short sentences: coverage first, then routing triggers, with no filler. Every clause either defines scope or tells the agent when to fire the tool.

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

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

With no parameters, an output schema present (so return values need not be described), and rich safety annotations, the remaining job is scope and trigger, both of which the description covers. Nothing needed to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly implies a parameterless, fetch-everything reference call and adds no misleading parameter expectations.

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

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

The description states a specific resource (the full Audexum documentation: engines, voices, limits, pricing, products, plans, credit packs) rather than restating the tool name. An agent can immediately distinguish this static reference tool from action siblings like generate_speech, transcribe, and list_voices.

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

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

It gives explicit trigger conditions ("call it when the user asks what Audexum can do, which voice or engine to use, or about plans and prices"), which is strong when-to-use guidance. It does not, however, address overlap with siblings such as list_voices for voice enumeration or get_upgrade_link/account_status for plans and pricing, so exclusions are absent.

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 safety hints, and the description adds important behavioral context: credits are spent based on characters times engine multiplier, character limits vary by engine, and v4 supports inline acting tags. It also notes plan restrictions for v4.

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

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

The description is front-loaded with purpose and return value, then uses a compact Args list to document each parameter. Despite its length, every part provides necessary information for a six-parameter tool with no schema descriptions.

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

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

Given the complexity, zero schema description coverage, and existing output schema, the description is complete enough to call the tool correctly. It covers inputs, limits, engine tradeoffs, voice sourcing, and credit consumption.

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. It explains every parameter: text limits and tags, engine tiers and defaults, voice ID source and examples, language ISO code and default, style supported engines, and speed range.

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 first sentence states a specific verb and resource: turn text into natural speech and return an MP3 link. It clearly distinguishes this from sibling tools like transcribe and references list_voices for voice selection.

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

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

The description gives strong practical guidance on engine selection, voice IDs, text splitting, and defaults. It does not explicitly state when not to use the tool or name an alternative speech tool, but the usage context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds one piece of business context not present in annotations or schema: that buying credits also unlocks V4. It says nothing about the form of the returned link or how the user should consume it.

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, zero filler, and the payload (what the link is) is front-loaded before the invocation cue. 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?

A zero-parameter read-only tool with a declared output schema, so return-format details are unnecessary. The description covers what it returns and when to call it; the only minor omission is any note on how to present the link to the user, which is low-stakes given the output schema exists.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameter semantics are needed or missing.

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 exactly what the tool returns: a link for upgrading the Audexum plan or buying credits. It is unambiguous and clearly distinct from every sibling (none of account_status, audexum_guide, generate_speech, list_voices, transcribe, or youtube_transcript overlap with billing/upgrade actions), though it never explicitly names those siblings as alternatives.

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

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

Explicitly names the trigger conditions: "Call this when the user asks how to get more credits, V4, or upgrade." That is a clear when-to-use statement. It does not state when NOT to use it or point to an alternative tool, but no plausible alternative exists among the 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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds ordering behavior not in the annotations ('by engine, best first'), which directly tells the agent the first entry is the recommended voice — a real selection cue beyond structured fields.

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 scope and ordering rule, then the hand-off to generate_speech. 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-field explanations are unnecessary, and annotations cover the safety profile. The description supplies grouping/ordering and the cross-tool link, which is enough for a zero-parameter listing tool, though it doesn't hint at list size or refresh behavior.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly adds no parameter detail because there is nothing to document; the mention of `id` refers to a field of the returned voices, not an input.

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 resource ('voices') and scope ('All voices by engine'), which is meaningfully more than a restatement of the name. It also names the downstream consumer (generate_speech), so an agent can place it in the workflow, though it doesn't explicitly contrast 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?

Guidance is about what to do with the output ('Pass a voice `id` (and its engine) to generate_speech'), which is useful routing, but there is no explicit when-to-call-this-tool statement. Usage is only implied, and no exclusions or alternatives are given.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false), so the description's job is to add context. It does so meaningfully: credit consumption, a 25 MB size ceiling, accepted container formats, and language auto-detection. Auth requirements and latency/async behavior are still 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?

Front-loaded purpose, then a compact Args block, then the cost and alternative routing in one line. Every sentence earns its place; the Args formatting is conventional and only mildly redundant with the schema.

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

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

An output schema exists, so return values need not be explained. Parameters are fully described despite 0% schema coverage, and the annotations plus the credits/alternative notes give the agent everything needed to decide and invoke correctly.

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

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

Schema coverage is 0%, so the description carries the full parameter burden and does so: audio_url is constrained to public http(s) URLs with a size limit and format list, and language is documented as an optional ISO 639-1 hint that is auto-detected when omitted. This fully compensates for the empty schema descriptions.

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 ('Transcribe speech in an audio or video file to text') and names the sibling it is not (youtube_transcript) for a distinguishable case. An agent can tell it apart from youtube_transcript 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?

Explicitly routes YouTube links to youtube_transcript, which is the key routing decision among the siblings. It also warns that the call spends Audexum credits, giving the agent a cost-based usage consideration rather than leaving it to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the tool is free, consumes no credits, and is subject to a daily allowance (a rate-limit disclosure), plus it points to the third-party API documentation.

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 core purpose in one sentence, followed by a compact Args block and a one-line cost note. Slightly redundant to restate parameter names in an Args list, but each item adds semantic detail the schema lacks.

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. For a two-parameter read-only tool, the description covers purpose, provider, cost model, and both parameters; only edge-case behavior (missing captions, unsupported language fallback) is absent.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: url is defined as a YouTube video link and language as an ISO 639-1 preferred caption language with a default of "en". Format detail for language is supplied that the schema lacks, though no example codes or fallback behavior when the requested language is unavailable are given.

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 ("Get the transcript (captions) of a YouTube video") and names the upstream provider. It is sufficiently distinct from the generic sibling 'transcribe' by virtue of the YouTube-specific scope, but it never explicitly contrasts itself with that sibling or with generate_speech.

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 it is the right tool when the input is a YouTube URL. There is no explicit when-to-use/when-not guidance, and the nearest alternative, 'transcribe', is never mentioned or distinguished.

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