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

No annotations are provided, so the description carries the burden. It discloses cost with 'Billed per token from the credit balance', which is relevant context. However, it omits information about response format, rate limits, or any side effects beyond billing, leaving gaps in transparency.

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

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

The description is two concise sentences, front-loaded with the action and scope, and includes billing and model discovery without any fluff. Every sentence serves a purpose.

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

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

With 5 parameters and no output schema, the description gives the core purpose and cost but leaves return format and usage boundaries implied. It does not describe the response structure or when to prefer other tools, making it only moderately complete 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 60%, so the baseline is 3. The description adds no extra detail about system, max_tokens, or temperature, though it does clarify 'model slugs' indirectly via list_models. The schema already covers model and prompt adequately, but the uncovered parameters remain unaddressed.

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

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

Description uses a specific verb 'Send a prompt' and names the resource 'any of the 120+ models on ApexApi'. It clearly differentiates from siblings like generate_image and generate_speech by focusing on prompt-based text generation. The title 'Ask an AI model' also aligns well.

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

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

The description explicitly instructs to 'Use list_models to discover model slugs', which is a useful prerequisite. It does not provide exclusions or mention alternatives like extract_structured, but the primary use case is clear and the guidance is sufficient for basic selection.

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

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

With no annotations to convey safety or side effects, the description carries the full burden. It states it 'polls' a job, but does not disclose what the response contains, whether it blocks, what statuses are possible, or any rate-limit/failure behavior. This minimal transparency leaves the agent uncertain about expected outcomes.

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

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

The description is a single sentence that conveys the core functionality without redundant words. It is front-loaded and every phrase earns its place.

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

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

The tool is simple, but without an output schema the description should explain what a polling response looks like (status, results, error handling). It only says 'poll' without describing the return value or any nuances like repeated polling semantics. This is a significant gap for an async job checker.

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

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

The schema provides parameter names and an enum for kind, but no descriptions. The description adds meaningful context by mapping kind values to specific job types (crawl_site and extract_structured), clarifying that 'id' refers to a job id. It does not fully compensate for the 0% schema coverage but provides essential linkage.

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

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

The description clearly states the tool's function: to poll an asynchronous job, explicitly naming the two job types (crawl_site and extract_structured). This distinguishes it from sibling tools that create or scrape, making the purpose unambiguous.

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

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

The description implies when to use it: after launching a crawl_site or extract_structured job. However, it provides no explicit guidance on when to use this over alternatives or any exclusions. Since no alternative polling tool exists, the implicit context is adequate but not fully 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?

With no annotations, the description fully shoulders the burden of behavioral disclosure. It honestly reveals the 60-second wait, the job-id fallback for long runs, per-page billing with a cap, and the result_url for the full output. This is far beyond minimal and gives the agent accurate expectations.

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

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

Three sentences, front-loaded with the core purpose, followed by cost and async behavior. Every sentence earns its place—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?

For a tool with no output schema and no annotations, the description covers all essential aspects: input (seed URL), scope (same-domain), output (markdown + result_url), cost, and long-run handling. An agent has enough information to invoke the tool and interpret 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 coverage is 100%, so baseline is 3. The description adds 'capped by limit' and cost context, but the schema already states 'Max pages (default 100) — bounds cost at limit × $0.005.' Therefore the description adds minimal incremental meaning beyond the schema.

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

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

The description opens with 'Crawl same-domain pages from a seed URL into markdown,' a specific action on a resource that clearly distinguishes this tool from siblings like scrape_page (single page) and check_job (job status). The title 'Read a whole site' reinforces the purpose without ambiguity.

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

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

It provides clear context on when to use the tool (for whole-site crawling) and mentions async fallback via check_job if execution exceeds 60 seconds. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to select it appropriately among 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?

No annotations are provided, so the description carries the full burden. It discloses billing behavior ($0.01 per record) and failure policy (failures free), which is useful. However, it omits details such as authentication requirements, rate limits, or handling of invalid/unsupported URLs beyond 'failures free'. This is partial transparency.

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

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

The description is two sentences, front-loaded with the core purpose, and includes only necessary details (pricing, supported scrapers). No redundant words or overly long explanations.

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

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

Given the tool's moderate complexity (3 params, no output schema), the description covers the essential aspects: source platforms, pricing, failure policy, and available scrapers. It doesn't detail the exact JSON structure per scraper, but the phrase 'ready-made structured JSON' provides sufficient expectation for an agent to select and invoke the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying which URLs are eligible (Amazon, Walmart, etc.) and implicitly linking the 'limit' parameter to per-record billing. This helps the agent understand parameter semantics in context.

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

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

The description clearly states the tool extracts structured JSON from specific platforms (Amazon, Walmart, etc.) with a specific verb 'extract' and resource 'structured data'. It distinguishes itself from siblings like scrape_page and crawl_site by emphasizing 'ready-made' structured output from a curated list of sources.

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

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

The description implies when to use the tool: when the URL is from one of the listed platforms and structured data is needed. It lists supported scrapers, effectively setting the inclusion criteria. However, it does not explicitly mention alternatives like scrape_page for unsupported URLs, so it lacks an explicit when-not-to-use statement.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that it returns a URL, but omits important details such as whether the operation is synchronous, whether it consumes credits (given list_models mentions prices), or what happens on failure. This is a significant gap for a generation 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?

The description is exactly two sentences, front-loaded with the core function and output, followed by a useful prerequisite note. Every sentence earns its place with no redundancy or filler.

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

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

For a simple 3-parameter tool with no output schema, the description covers the basics: what it does, its output format, and how to find models. However, it leaves unresolved questions about cost, synchronous vs. asynchronous behavior (especially given the check_job sibling), and error handling, making it adequate but not complete.

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

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

Schema description coverage is 67%, covering size and model but not prompt. The description adds meaning by explaining that the prompt is a text prompt for image generation and directs the user to list_models for available model slugs, which partially compensates for the missing prompt description. It does not add syntax or format details beyond what the schema provides.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Generate an image from a text prompt. Returns a URL.' This distinguishes it from siblings like generate_speech and chat, leaving no ambiguity about what the tool does.

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

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

It provides clear usage context by telling the user to 'Use list_models with type=image for available models and prices,' which is a prerequisite for using this tool correctly. However, it does not explicitly mention when not to use this tool or name alternative image generation tools, but none exist 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?

Despite having no annotations, the description discloses key behavioral traits: it uses the external ElevenLabs service, returns an MP3 URL, and incurs costs per 1,000 characters. It omits latency, error handling, and authentication details, but covers the most operationally relevant aspects for a simple TTS 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?

Three short sentences, each adding distinct value (purpose, output, cost). Information is front-loaded and there is no redundancy or filler.

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

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

The tool is simple, and the description adequately covers purpose, output, and cost. Given the lack of annotations and output schema, it could mention error cases or rate limits, but for a straightforward API call it is reasonably complete.

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

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

The schema already provides descriptions for all three parameters (input, model, voice), so the description adds no additional parameter-specific context. The billing note is related to input length but does not enrich the understanding of any parameter beyond what the schema offers.

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

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

The description clearly states the tool's function as text-to-speech via ElevenLabs and its output (MP3 URL). This distinguishes it from sibling tools like generate_image, and the purpose is immediately unambiguous.

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

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

The description implies usage for text-to-speech needs and warns about per-character billing, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. This is 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?

No annotations are provided, so the description must convey behavior. It states the balance is 'current' and in USD, implying a read-only operation, but it does not disclose potential side effects, authentication requirements, or return format. For a simple getter, this is adequate but not rich enough to fully compensate for missing 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 two sentences, front-loaded with the core purpose and followed by one contextual remark. Every word earns its place; no redundancy or filler.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is sufficiently complete. It explains the balance's units and its role as the only usage limit, which provides meaningful context for why an agent would call this tool. Missing minor details like response shape or error cases, but those are not critical for a zero-param read-only getter.

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

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

The tool has zero parameters, so the description correctly omits parameter details. The baseline for 0 params is 4, and the description adds no unnecessary information, keeping the tool simple and understandable.

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

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

The description uses a specific verb ('get') with a clear resource ('prepaid credit balance in USD'), which fully defines the tool's purpose. It also adds a scoping detail ('Balance is the only usage limit') that distinguishes it from the sibling tools, which are all about different actions like chat, scraping, or image generation.

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's usage (checking the balance before using other tools) but does not explicitly state when to use it versus alternatives. It mentions that balance is the only usage limit, which suggests the context, but lacks a direct 'Use this when...' statement. No exclusions or alternative tool names are provided.

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

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

Without annotations, the description provides some behavioral context: it is a 'live' catalog and includes per-token pricing specifics. However, it does not mention whether the operation is read-only, pagination behavior, or any authentication requirements, leaving gaps for a tool with no 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 two sentences, with the key purpose (live catalog of all models) front-loaded and no redundant wording. Every detail (type, context window, pricing, filter tip) 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?

For a simple one-parameter list tool, the description covers the return contents (type, context window, pricing) and filter behavior. It lacks details about ordering, pagination, or response format, but the absence of an output schema and the tool's simplicity make this acceptable.

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

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

The schema already documents the 'type' parameter at 100% coverage. The description adds value by explaining the rationale for filtering ('keep the list short') and implying that omitting the filter returns all models, which goes beyond the schema's simple 'Filter by model type'.

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

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

The description clearly states the tool catalogs all ApexApi models, listing type, context window, and USD pricing. This is a specific verb (catalog/list) with a clear resource (all models), distinguishing it from siblings like chat or get_balance.

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

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

The description implies when to use it (to view available models and pricing) and provides a usage tip ('Filter by type to keep the list short'). It does not explicitly name alternatives or exclusions, but no sibling tool offers a similar listing function, so the context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly adds important behavioral traits: automatic anti-bot handling, billing per successful page, and that failures are free. This gives the agent useful context beyond the basic fetch operation, though it does not mention redirects or rate limits.

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

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

The description is two sentences, front-loaded with the primary action and resource. Both sentences earn their place: the first explains what the tool does and output options; the second explains billing behavior. No fluff or redundancy.

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

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

For a simple one-URL fetch tool with two parameters and no output schema, the description covers the main aspects: purpose, output formats, anti-bot handling, and pricing. It is complete enough for an agent to understand the tool's basic scope, though it lacks details on potential failure modes (beyond 'free') or limits, which is acceptable for this simplicity.

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 schema already documents both parameters (url and format). The description adds no additional parameter-specific details; it only mentions output formats generally, which is already covered by the enum. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Fetch' with a precise resource 'any URL' and clearly states the output format ('clean, LLM-ready markdown (or html/text)'). It distinguishes itself from sibling tools like crawl_site by focusing on fetching a single page rather than crawling.

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

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

The description implies usage for fetching a single URL as markdown, but it does not explicitly state when to use this tool over alternatives (e.g., crawl_site for crawling multiple pages) or when not to use it. The guidance is present but implicit.

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