MESSORA

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

Beyond the readOnly/idempotent annotations, the description adds crucial behavioral context about the job state machine: SUCCESS, FAILURE, REVOKED are terminal, while PENDING/STARTED require re-querying. This is essential for correct usage and goes beyond the structured annotations.

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

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

Two concise sentences, front-loaded with the purpose and followed by essential state semantics. Every word earns its place with no 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 single-parameter tool with rich annotations and an output schema present, the description covers the necessary purpose and behavioral polling semantics. No missing critical information; the output schema handles return value details.

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 has 0% description coverage, leaving job_id only defined as 'Job Id'. The description adds that it refers to a crawl/search job, providing some context, but does not explain the format, how to obtain the ID, or any acceptable values beyond the schema's minLength constraint.

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 queries a 'crawl or search' job, with a specific verb ('Consulta') and resource. The terminal states further clarify it returns job status, distinguishing it from sibling tools like start_crawl/start_search which initiate jobs.

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 polling guidance: PENDING/STARTED should be queried again, implying users should use this repeatedly until a terminal state. However, it does not explicitly mention alternatives or when not to use it, though sibling names make the distinction obvious.

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, covering the safety profile. The description adds what data is returned (plan, credits, balance) but does not disclose additional behavioral aspects like authentication or rate limits. No contradiction with annotations.

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

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

A single, concise sentence that clearly communicates the tool's purpose. No unnecessary words or repetition; it is front-loaded with the verb and resource.

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 (0 parameters) and the presence of an output schema, the description adequately covers what the tool does and what it returns. It is complete for the intended use case.

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 0 parameters, and the baseline for 0 params is 4. No parameter semantics are needed since there is nothing to describe.

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 'Consulta' and clearly identifies the resources: plan, used credits, and account balance. It distinguishes itself from sibling tools like get_job and scrape_url by focusing on account usage rather than job/crawl operations.

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

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

The description implies the tool is for checking account usage information, but it does not explicitly state when to use it versus alternatives or provide exclusions. Sibling tools are clearly different, so context is sufficient, but explicit guidance is missing.

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

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

The description adds a meaningful behavioral detail beyond annotations: credit is consumed only when the backend returns scrape_status=success. This is not present in the annotations and provides useful cost/risk context, though it does not disclose other behavioral traits such as return format or error handling.

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 conveys the core purpose and a key cost behavior without wasted words. However, given the tool's complexity, the extreme brevity borders on under-specification, but the structure itself is clean.

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?

Despite having a complex tool with 16 parameters and a detailed output schema, the description provides only a minimal purpose statement and one cost note. It fails to explain when to use the tool, what output formats can be requested, or how parameters like render_js or fact_check affect behavior, making it inadequate for the tool's complexity.

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

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

Schema description coverage is 0% and there are 16 parameters, yet the description provides no parameter-level semantics beyond mentioning 'URL'. The tool has many options (formats, timeout, render_js, fact_check, etc.) that are completely unexplained, leaving the agent without any added understanding from the description.

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: 'Extrai conteúdo de uma URL' (Extracts content from a URL). This gives a specific verb and resource, and distinguishes it from sibling tools like start_crawl or start_search, which focus on broader crawling or search behavior.

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 its use for extracting content from a single URL, but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. Sibling tool names suggest alternatives (e.g., start_crawl), but the description itself does not address them.

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

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

Annotations already indicate readOnlyHint=false (mutating) and destructiveHint=false. The description adds the job lifecycle information (PENDING/STARTED -> SUCCESS/FAILURE/REVOKED) and the need to poll, which is useful. However, it does not disclose any side effects, rate limits, authentication needs, or what the crawl actually does beyond starting. With the annotations providing the safety profile, a 3 is appropriate.

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 main purpose and followed by a clear directive. Every word earns its place; there is no fluff or redundancy. This is concise and well-structured.

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

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

Given the tool's complexity (16 parameters, async behavior, output schema), the description is far too minimal. It explains the high-level flow (start and poll) but provides zero details about parameter semantics, crawling scope, or how to configure the crawl. The output schema may describe the return value, but the description does not cover the rich parameter space, leaving agents to guess at the meaning and effect of options like pdf_ocr, max_depth, follow_subdomains, and include_frames.

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% - the description contains no parameter information whatsoever. The schema itself only lists parameter titles and defaults, no explanatory descriptions. For a tool with 16 parameters (including max_depth, pdf_ocr, include_links, etc.), the description completely fails to explain what these parameters mean or how they affect the crawl behavior. This is a critical 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 clearly states the tool's core action: it starts an asynchronous crawl and returns a job_id. It uses a specific verb ('inicia') and resource ('crawl'), and implicitly contrasts with siblings like get_job (which is for querying) and scrape_url (which likely handles single pages). However, it does not explicitly distinguish from start_search, which could also be an async operation.

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 tells the agent to poll get_job until PENDING/STARTED becomes SUCCESS, FAILURE, or REVOKED. This provides clear usage context: call start_crawl first, then poll the job status. It does not mention alternatives like scrape_url or start_search, but for the described flow, this is sufficient 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 indicate non-read-only, non-idempotent, non-destructive, and open-world behavior. The description adds valuable context about the asynchronous nature and the requirement to poll via get_job, which goes beyond the structured annotations. It also hints at 'premium' implications, though it does not detail rate limits or side effects.

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

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

The description is a single, front-loaded sentence that communicates the core action and the follow-up step. Every word earns its place, and it avoids unnecessary detail, making it highly efficient.

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

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

Given the 8-parameter schema and the asynchronous job pattern, the description covers the essential flow (start then poll) and references the output via job_id. It does not elaborate on the meaning of 'premium' or parameter specifics, but the output schema exists and the tool name suggests the search domain. Overall, it is sufficiently complete for an agent to initiate the operation 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?

With schema description coverage at 0%, the description was expected to compensate for the lack of parameter explanations. However, it provides no information about query, tags, country, freshness, num_results, include/exclude_domains, or timeout_seconds. The parameter names are somewhat self-explanatory, but the description itself adds no semantic value, leaving users to infer from names alone.

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

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

The description clearly states the tool starts an asynchronous premium search and returns a job_id, using a specific verb ('Inicia') and resource ('busca premium'). It distinguishes itself from sibling tools like start_crawl (different action) and get_job (polling) by explicitly mentioning the job_id return and the subsequent use of get_job.

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

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

The description provides clear usage context by instructing the agent to consult get_job until a terminal state, which implies this tool is for initiating asynchronous work. It does not explicitly list alternatives or exclusions, but it names the follow-up tool, which is sufficient guidance for a straightforward async pattern.

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