WebDiet

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

Annotations indicate idempotentHint=true, but description adds that no args returns a link, token arg performs login, and discusses token expiration. Adds value beyond annotations without contradiction.

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?

Single, well-structured paragraph with no wasted words. Front-loaded with key info (audience, purpose, best practice). Every sentence contributes.

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?

Simple tool with one param; description covers all needed context: purpose, two usage modes, best practice, and implicit return (link or success). No output schema needed.

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 has 1 optional param with 0% description coverage. Description compensates by specifying the 'token' is a JWT from browser login and how to use it. Adequately explains parameter 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 clearly states the tool is for authentication, providing a login link or accepting a token. It distinguishes from sibling tools, none of which are authentication-related.

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 describes two authentication methods (permanent config with header vs session-only with token) and advises which is best. Provides clear context for use by IDE agents.

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, destructiveHint=false. Description adds behavioral context by specifying the return values (authenticated, pending, connect_url) and conditions, which goes beyond what annotations provide.

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 no fluff, front-loaded with key information. Every word 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?

Given no parameters and no output schema, description is fully complete. It explains the two states (all connected vs missing credentials) and what is returned in each 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?

Tool has no parameters, so schema coverage is 100%. Per guidelines, 0 params has baseline 4. Description confirms no parameters needed.

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 specific verb 'returns' and resource 'connection status and URLs', and clearly distinguishes between different states (all providers connected vs missing credentials). It differentiates from sibling 'authenticate' by focusing on status rather than initiating auth.

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?

Description implies usage for checking connection status but does not explicitly state when to use this tool vs alternatives like 'authenticate'. No when-not or alternative guidance is 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?

Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds context about auth requirements for writes, search result flags for installation status, and the behavior of list_tools/invoke in flat-mode clients. This adds value 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?

The description is a dense single paragraph without breaks or bullet points. It contains valuable information but could be more concise and structured (e.g., separating action descriptions) to improve readability.

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 (13 parameters, no output schema), the description covers actions and their intent but lacks details on return values, error handling, or parameter formats. It is adequate for basic understanding but incomplete for full autonomous use.

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 13 parameters with 0% description coverage. While the description explains each action's purpose and implies parameter usage (e.g., query for search, mcp_id for describe), it does not explicitly define parameters like limit, immediate, or tier_slug. This leaves ambiguity for an AI agent.

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 as 'THE official mcp.ai marketplace' and enumerates specific actions (search, describe, install, etc.), distinguishing it from external registries. It provides a precise verb-resource mapping for each action.

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 this tool first for discovering capabilities, before external registries. It provides contextual guidance for each action (e.g., search first, describe for details, request_mcp if nothing fits) and notes that writes require admin privileges.

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 declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that the tool requires a conversation array for reproduction, which is helpful. However, it does not elaborate on potential side effects (e.g., duplicate tickets) or rate limits, so the description contributes modestly 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?

The description is two sentences, front-loaded with purpose, and provides an essential usage instruction. Every sentence earns its place with no wasted words.

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 bug report tool with no output schema and clear annotations, the description adequately informs an AI agent about what to include. It could mention that the report is sent to developers or what the response looks like, but the current level is mostly 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 0%, so the description must compensate. The description mentions including the conversation array, clarifying its purpose, but does not specify format or constraints for 'context' or 'message'. Parameter names are self-explanatory, but additional detail would improve semantics.

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 purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb and resource, and distinguishes itself from sibling tools (no other feedback tool exists).

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 context for usage ('Include the conversation array with recent messages for reproduction'), implying when to use it. While it does not explicitly state when not to use or list alternatives, the context is sufficient given the sibling tools.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds no further behavioral context beyond these annotations. Minimal additional value.

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?

Extremely concise; single sentence of 9 words with no fluff. Every word 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 read-only info tool with no parameters and no output schema, the description is complete and sufficient.

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?

No parameters exist in the input schema, and schema coverage is 100%. The description need not add param details, earning a baseline of 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 exactly what the tool does: show current MCP platform and adapter versions. It is a specific verb+resource and distinguishes well from siblings which are mostly domain-specific 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?

No explicit guidance on when to use this tool vs alternatives. However, the tool is simple and self-explanatory; the context is implied by its purpose.

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 readOnly, idempotent, non-destructive. The description adds specific return details (installed MCPs, connection status, catalog tools) that enhance transparency 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?

Single sentence, no fluff, front-loaded with the verb and resource. Every word 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?

Given no output schema, the description adequately explains what the tool returns. For a simple info tool, this is fully 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?

No parameters exist, so baseline 4 applies. The description does not need to add parameter information.

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 the specific verb 'Returns' and clearly states the resource: toolkit state, including installed MCPs, connection status, and catalog tools count. This uniquely identifies the tool among 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?

No explicit when-to-use or alternative guidance is given, but since this tool is unique in its purpose, usage is implied. Lacks explicit context but adequate.

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=true, idempotentHint=true, destructiveHint=false, aligning with the listing operation. The description adds value by explaining that the tool decodes URL-encoded HTML to produce readable text and preserves original HTML for rich rendering, which is beyond what annotations provide.

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 moderately long but well-structured with bullet points and clear categorization of fields. It is front-loaded with the main purpose and each sentence adds value, though some redundancy could be trimmed.

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 output schema, the description thoroughly explains the return structure (fields, data formats, encoding) and provides references to sibling tools and optional bulk usage. It covers all necessary context for an agent to use the tool 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 description coverage is 0%, so the description must compensate. It explains patient_id (required) and patient_ids for bulk support, but does not describe the account parameter. This partial coverage earns a 3.

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 lists anamnesis records with full Q/A content, specifying each field (id, titulo, data, texto, texto_html, interpretacao). It distinguishes from the sibling tool webdiet_preconsulta, which handles unlinked pre-consultation responses.

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 states when to use this tool (for patient anamnesis) and when to use webdiet_preconsulta instead (for pre-consultation responses not yet linked to a patient). It also mentions bulk support via patient_ids, providing clear usage context.

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 clearly states the destructive and irreversible nature, aligning with annotations (destructiveHint=true). It adds value by emphasizing irreversibility and bulk capability, but could further disclose permissions or side effects on related 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?

The description consists of two short sentences. The first front-loads the primary purpose and irreversibility; the second adds bulk support. No extraneous words.

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 delete tool with no output schema, the description covers the essential aspects: destructiveness, irreversibility, and bulk capability. It could be enhanced by mentioning account parameter usage or error handling, but is fairly 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?

With 0% schema coverage, the description adds meaning to array parameters (patient_ids, anamnese_ids) by noting they support batched execution. However, it does not explain the required patient_id, anamnese_id, or optional account parameter, leaving gaps.

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 specific verb 'permanently delete' and resource 'anamnesis record', clearly distinguishing it from sibling tools like webdiet_anamnese_write_save (create/update) and webdiet_anamnese (list/get). It also mentions bulk support, adding scope.

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 states 'Permanently delete' and 'Irreversible', indicating when to use (when deletion is intended). Bulk support is noted, but no explicit guidance on when to use single vs bulk or when not to use this tool versus alternatives like deactivation.

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 indicate non-read-only, non-idempotent, non-destructive, which align with a duplicate operation. The description adds context about bulk execution and the duplicate action, exceeding what annotations provide. No contradictions.

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 somewhat verbose with redundant action enumeration and the odd '[Flattened action: duplicate]' note. While it gets to the point early, it could be more concise and 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?

With 8 parameters, 1 required, no output schema, and no parameter descriptions, the description omits critical details about duplication behavior (e.g., which fields are copied). It only partially addresses bulk operations, leaving significant gaps for correct usage.

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%, and the description only mentions patient_ids and anamnese_ids for bulk support. It does not explain the remaining 6 parameters (texto, titulo, account, anamnese_id, interpretacao), leaving the agent without meaningful parameter guidance.

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 it creates/updates anamnesis records and specifically highlights the 'duplicate' action. The tool name 'duplicate' and siblings (write_save, write_save_interpretation) differentiate it, 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 mentions the alternative 'webdiet_anamnese_delete' for destructive removal and notes bulk support. However, it lumps multiple actions (save, save_interpretation, duplicate) without clarifying that this tool is specifically for duplicate, which could confuse when to use it versus 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 indicate mutation (readOnlyHint=false) and non-destruction (destructiveHint=false). The description adds context such as 'create or update' behavior based on anamnese_id, bulk support via patient_ids/anamnese_ids, and the presence of multiple actions. It does not cover idempotency or return values, but the added value is moderate.

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 concise and front-loaded with the main purpose. It is structured with clear bullet points for actions and a separate note on deletion. The '[Flattened action: save]' line adds minor clutter but overall is 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 8 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It explains bulk support and action triggers but omits details on return values, parameter formats, and how actions are selected (besides anamnese_id). The tool is complex and requires more context.

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 explain parameters. It clarifies that empty anamnese_id means new record and that patient_ids/anamnese_ids enable batch execution. However, it does not explain texto, titulo, account, or interpretacao, leaving significant gaps.

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 the tool creates/updates anamnesis records in WebDiet, and lists three actions (save, save_interpretation, duplicate). This clearly identifies the verb and resource. However, the inclusion of multiple actions within one tool may cause confusion with sibling tools that are action-specific (e.g., webdiet_anamnese_write_duplicate), slightly reducing clarity.

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 directs agents to use webdiet_anamnese_delete for destructive removal, which is helpful. However, it does not explicitly differentiate when to use this tool versus the separate sibling tools for duplicate or interpretation, leaving ambiguity.

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-destructive, non-idempotent. The description adds that the tool can create/update, duplicate, and batch, and that anamnese_id empty means new record. However, it does not disclose how updates behave (e.g., overwrite all fields) or what side effects occur, which is important 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?

The description is concise (5 lines) and front-loads the main purpose with actions listed clearly. Some structuring (e.g., bullet points) could improve readability, but it is efficient and avoids unnecessary detail.

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 8 parameters, no output schema, and a write operation, the description lacks key details: what the return value is (e.g., success confirmation, created IDs), how to interpret responses, and full parameter semantics. Bulk support is mentioned but not fully explained.

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 coverage, the description only mentions patient_ids and anamnese_ids for batch support. The other 6 parameters (texto, titulo, account, patient_id, anamnese_id, interpretacao) are not explained, leaving the agent to infer their meaning. This is insufficient for correct invocation.

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 identifies the tool as handling create/update of anamnesis records with three explicit actions (save, save_interpretation, duplicate), specifically flattened to save_interpretation. It differentiates from sibling tools like webdiet_anamnese_write_save and webdiet_anamnese_write_duplicate and from the delete tool.

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 advises using webdiet_anamnese_delete for destructive removal, but does not clarify when to use each action (save vs save_interpretation vs duplicate) within this tool. No prerequisites or context for usage are provided, leaving some ambiguity.

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 safe read operation. Description adds meaningful behavior details: batch support via plural parameters, inclusion of URL field, and explicit list of measurements in 'get' action. No contradictions.

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?

Well-structured with clear separation of actions and bulk support. Front-loaded with purpose. Slightly verbose but each sentence adds value.

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 main operations and return data despite lack of output schema. Missing details on account parameter and exact mapping of parameters to actions, but overall sufficient for basic usage.

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 has 5 parameters with 0% description coverage. Description partially explains use of patient_ids and antropometria_ids for batch, and implies single ID usage for get action. However, it does not explicitly define each parameter's role or the account 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?

Description clearly states it reads anthropometry records with two actions (list and get) and specifies the fields included. It distinguishes from write tools but does not explicitly differentiate from sibling 'webdiet_antropometria_list', which could cause confusion.

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?

Provides guidance to use for analyzing body composition and directs to other tools for creating/saving. However, it lacks comparison with the similar list sibling and does not specify when to use list vs get mode or handle optional parameters.

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 and non-destructive behavior. The description adds context about bulk support and the URL field in returned records, no contradictions. It provides useful behavioral insight 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?

The description is somewhat lengthy and mixes list and get actions, which could be more focused. It includes a flattened action note and bulk support info, but the structure could be improved for clarity.

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?

Without an output schema, the description adequately describes the list output (id, date, type, URL) and mentions bulk support. However, including the get action's output details creates confusion about the tool's actual returns.

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 input schema has 5 parameters with 0% description coverage. The description only explains patient_ids and antropometria_ids for bulk support, leaving account, patient_id, and antropometria_id undocumented. This is insufficient for an agent to use the tool correctly.

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 it reads anthropometry records for a WebDiet patient. It distinguishes between 'list' and 'get' actions, but including both in the description may confuse the agent about the tool's single action. The flattened action note and sibling tool names help clarify, so it is mostly clear.

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 advises use for analyzing body composition evolution and mentions creation tools, but does not explicitly differentiate from the sibling tool webdiet_antropometria_get. The comparison is implied but not stated, leaving room for ambiguity.

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 destructiveness; description adds 'Permanently delete' and 'Irreversible' for emphasis, plus bulk support via calculo_ids, which is extra 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?

Two sentences, front-loaded with purpose, no unnecessary words. 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?

Covers core behavior and bulk option for a simple delete tool with no output schema. Lacks error handling or fallback info, but adequate.

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 has 0% description coverage. Description clarifies calculo_ids for batch execution, but account parameter is unexplained. Partial value added.

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 clearly states 'delete' action on 'energy expenditure calculation', and the resource is distinct from sibling tools like get, list, write_create, write_save. Mention of bulk support adds specificity.

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?

Implies use for removal but no explicit when-to-use vs. alternatives. No exclusions or prerequisites stated.

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 and idempotentHint=true. Description adds behavioral context: returns TMB/GET in specific units, supports batched execution via patient_ids/calculo_ids. No contradictions.

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?

5 sentences, each adding value: purpose, actions, results, flattened action clarification, bulk support. No superfluous content. Well-structured and easy to parse.

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 5 parameters, no output schema, and annotations present, description covers purpose, actions, results, and batched execution. Lacks explanation of parameter relationships (e.g., difference between calculo_id and calculo_ids). Adequate for a get tool with sibling list 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 has 5 parameters with 0% description coverage. Description mentions bulk support (patient_ids, calculo_ids) and implies patient_id+calculo_id for single get, but does not explain account or default values. Partially compensates for missing 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?

Description clearly states 'Read energy expenditure calculations' and lists actions (list, get). Differentiates from sibling write/delete tools, and includes specific output metrics (TMB, GET).

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?

Indicates actions: list (all calculations for a patient) and get (load saved data). Provides some usage guidance by distinguishing list vs get, but does not explicitly state when not to use or compare to 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 declare readOnlyHint=true and destructiveHint=false, consistent with description. Description adds context about available actions (list, get) and result fields (TMB, GET). No contradictions.

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?

Description is relatively short but includes redundant phrasing (e.g., 'Flattened action: list') and mixes actions for multiple tools. Could be more streamlined without losing clarity.

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 output schema, description should explain return structure. Mentions TMB and GET but no format or pagination. Does not state required parameters for list (patient_id implied but schema says 0 required). Incomplete for a list 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 coverage is 0%, so description should clarify parameter meanings. Only bulk support (patient_ids, calculo_ids) is mentioned. Does not explain account, individual patient_id requirement, or difference between calculo_id and calculo_ids. Insufficient for 5 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?

Description clearly states it reads energy expenditure calculations and specifies list action for all calculations for a patient. It differentiates from sibling tools like webdiet_calculo_energetico_get by mentioning get action in passing, but the flattening indicates this tool is for list. Purpose is specific and distinguishable.

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?

Description implies usage for listing calculations per patient but does not explicitly state when to use this over the get sibling. Mentions bulk support (patient_ids, calculo_ids) which hints at batch use, but no clear when-not or examples.

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 indicate write (not read-only) and non-destructive. The description adds context about batch execution and formula support. However, the flattened action comment creates confusion, and no details about idempotency or authentication are provided.

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 relatively compact but includes extraneous notes like '[Flattened action: create]' that reduce clarity. Critical information is present but not front-loaded, and the structure could be more logical.

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 12 parameters, no output schema, and no parameter descriptions, the description is insufficient. It omits return values, the action selection mechanism, and detailed parameter explanations. Bulk support is acknowledged, but overall completeness is low.

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 coverage, the description must explain parameters. It mentions formula types and activity/injury factors but does not map them to specific parameter names (e.g., 'formula', 'fator_atividade'). Essential parameters like 'peso' and 'altura' remain 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 it creates/updates energy expenditure calculations, but the mention of 'Flattened action: create' contradicts the update capability. The sibling tool 'webdiet_calculo_energetico_write_save' likely handles updates, but the description does not differentiate this tool from that sibling, causing 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?

No explicit guidance on when to use this tool versus alternatives like 'webdiet_calculo_energetico_write_save' or 'webdiet_calculo_energetico_list'. Bulk support is mentioned but not linked to specific scenarios. The description lacks 'when-to-use' and 'when-not-to-use' context.

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 provide no readOnly or destructive hints beyond false. The description adds lists of supported formulas and factors but does not disclose side effects, authorization requirements, or the impact of updates. This is insufficient 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?

The description is moderately concise but includes a lengthy, comma-separated list of formula names that could be summarized. The 'Flattened action: save' line adds little value. Overall, it could be streamlined without losing key 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?

With 12 parameters, 0% schema coverage, and no output schema, the description should cover more. It mentions bulk support and some input details but leaves many parameters undocumented and does not explain return values or error 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?

Schema description coverage is 0%, so the description must explain parameters. It mentions formulas and factors but does not map them to specific parameters (e.g., 'formula', 'fator_atividade'). Many parameters like 'mlg', 'nome', 'peso', 'account' are left 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 clearly states the tool creates/updates energy expenditure calculations, and mentions 'Actions: create (new calculation), save (update existing calculation)'. However, the title 'write_save' and the 'Flattened action: save' could cause confusion about whether creation is supported. It distinguishes from sibling 'write_create' only implicitly.

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 guidance on when to use this tool versus alternatives like 'webdiet_calculo_energetico_write_create'. It lists actions but does not provide selection criteria or prerequisites.

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds bulk support via patient_ids and types (adulto, infantil, gestacional). It does not disclose error behavior, permissions, or side effects beyond creation. Given minimal annotation depth, the description adds moderate 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 main purpose. Every sentence adds value: first states action and return value, second adds types and bulk support. No wasted words.

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 no output schema, the description mentions the return value (record ID). It covers key aspects: creation, types, bulk support. However, it lacks details on constraints (e.g., required patient existence) and does not explain the 'data' and 'account' parameters, which are left to schema. Nearly complete for a simple create 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 0%, so description must compensate. It explains the 'tipo' parameter (adulto, infantil, gestacional) and 'patient_ids' for bulk support. It also implies the output (record ID). However, it does not describe the 'data' or 'account' parameters, leaving gaps. Partial help for 2 of 5 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 clearly states 'Create a new body measurement record for a patient.' It specifies the resource (body measurement) and action (create). It distinguishes from sibling tools like webdiet_antropometria_get and webdiet_antropometria_list, which are read operations. The mention of the returned record ID for webdiet_save_antropometria adds specific purpose context.

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 explains when to use the tool (to create body measurements) and notes that the returned ID is needed for webdiet_save_antropometria, providing usage flow. However, it does not explicitly state when not to use or mention alternatives, but the context is sufficient for an agent to decide.

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 read-only, idempotent, non-destructive. The description adds value by detailing record structure, date range behavior, and actions, providing additional behavioral context 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?

The description is concise and front-loaded with purpose. However, the trailing note '[Flattened action: categories]' is unclear and could be integrated more cleanly. Overall, efficient but not perfect.

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 record fields and date range, but does not explain how to invoke the two distinct actions (no action parameter), and misses the 'account' parameter. This ambiguity reduces completeness for a tool with no 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?

With 0% schema description coverage, the description explains inicio, fim (date format example), and tipo (via record fields), but fails to describe the 'account' parameter, leaving a gap. Partial compensation.

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 it reads financial records and lists two actions (list and categories), distinguishing it from sibling tools like webdiet_financeiro_list which likely only lists records. The verb and resource are explicit.

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 usage context such as date range format and default 30 days, but does not explicitly guide when to use this tool vs alternatives like webdiet_financeiro_list. No when-not-to-use guidance is 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?

The description adds value beyond annotations by emphasizing irreversibility and bulk execution. Annotations already set destructiveHint=true, and the description reinforces this without contradiction.

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, front-loaded sentences with no unnecessary words. The key actions and bulk feature are clearly stated.

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 delete tool with destructive annotations, the description covers primary behavior and bulk support. No output schema exists, so return values are not expected. Minor gaps like idempotency are acceptable for a deletion 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?

With 0% schema description coverage, the description partially compensates by mentioning financeiro_ids for batch, but does not explain the required financeiro_id or account parameter. 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 clearly states it permanently deletes a financial record and is irreversible. It mentions bulk support via financeiro_ids, distinguishing it from sibling tools like webdiet_financeiro_list or webdiet_financeiro_write.

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 deletion but does not explicitly state when to use versus alternatives or when not to use. No exclusions or alternative tool references 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?

Annotations already declare read-only, idempotent, non-destructive. The description adds useful context: defaults to last 30 days, date format YYYYMMDDHHmm, and fields returned. However, it does not mention pagination, limits, or whether categories action is actually available.

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?

Description is relatively concise and front-loaded with purpose. The mention of 'categories' and the '[Flattened action: list]' note add minor confusion but do not severely impact structure.

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?

Adequate for a read-only list tool. It describes common fields and date filtering. However, no mention of maximum results, pagination, error conditions, or whether all parameters are optional.

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?

Since schema coverage is 0%, the description carries full burden. It explains inicio/fim format and tipo enum values (entrada=income, saida=expense) and default 'entrada'. Missing explanation for 'account' parameter, which is present in 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 states the tool reads financial records and lists them in date range. However, it also mentions 'categories' as an action, which is ambiguous since the title and flattened action indicate only 'list' is active. This slightly reduces clarity.

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 guidance on when to use this tool vs alternatives. Sibling financial tools (e.g., webdiet_financeiro_categories, webdiet_financeiro_write) are not mentioned. The agent is not told that this is for reading only or when to prefer it over other list tools.

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 indicate non-read-only, non-destructive, and non-idempotent, which aligns with creating records. The description adds behavioral context: formatting rules (comma for decimals), installment logic, bulk execution via patient_ids, and default categories. It does not contradict 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 concise and front-loaded with the main purpose. Each sentence adds value, but it could benefit from structured formatting (e.g., bullet points) to improve readability. Overall, it efficiently packs significant detail.

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 core functionality, key parameters, and usage, including bulk support. However, it lacks documentation for several parameters and does not describe output, error handling, or prerequisites. For a complex write tool with 15 parameters, some gaps remain despite good overall coverage.

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 provides meaningful explanations for 9 of 15 parameters (patient_id, valor, tipo, forma, parcelas, dataCobranca, nova_cat, categoria, patient_ids), including format and defaults. However, it omits cpf, data, nome, horario, account, observacao, leaving the agent partially informed.

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 creates financial records in WebDiet, specifying it handles income (entrada) and expenses (saida). It distinguishes from siblings by explicitly mentioning the delete alternative (webdiet_financeiro_delete) and implies listing/categories exist as 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?

Provides detailed usage guidance: explains when to use each tipo, gives default categories, value format, payment method examples, installment handling, and bulk support. It explicitly directs destructive operations to another tool. However, it does not mention when not to use this tool vs listing or other finance tools.

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 read-only and idempotent. The description adds valuable behavioral details: the catalog is cached per session, filtering is client-side, and it lists return fields (macros, medidas_caseiras). This provides 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?

The description is concise, with two sentences covering purpose and key details. It is front-loaded with the core action. It could be more structured but contains no unnecessary 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 description explains the data source, return fields, and filtering behavior. Given the no output schema, it adequately describes what the tool returns. However, it omits pagination details (related to limite) and error scenarios.

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 three parameters with no descriptions (0% coverage). The description only clarifies the keyword constraint (min 3 characters) and mentions caching. It does not explain the 'limite' or 'account' parameters, leaving their meaning incomplete.

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 searches the WebDiet food database to obtain numeric food IDs needed for prescription macros, and it specifies the data source and client-side filtering. It is clearly distinct from sibling tools which deal with other entities.

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 explains when to use the tool (to get food IDs for prescriptions), notes the minimum keyword length, and describes the data source. However, it does not explicitly state when not to use or mention alternative tools, but no direct alternatives exist 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's addition of bulk support and the default 'tipo' value adds useful behavioral context without contradicting annotations. No mention of auth or rate limits, but the safety profile is clear from 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 extremely concise with two sentences. The first sentence clearly states purpose and usage of 'tipo'. The second sentence adds bulk support. No unnecessary words; 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 there is no output schema, the description should indicate what the tool returns for each tipo. It does not describe the return format or structure, which is a significant gap for a tool with multiple modes. Also lacks info on pagination or how 'limite' affects 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 coverage, the description must explain parameters. It explains 'tipo' (with enum values) and 'patient_ids' (bulk). However, it misses explanations for 'limite' (likely limit/offset) and 'account', and 'patient_id' is mentioned only indirectly. Partial coverage of 5 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 clearly states that the tool loads food diary entries, meal reactions, attachments, or orientations for a patient, with a parameter to select the type. However, the tool name 'get_consultations' is misleading as these data types are not strictly consultations, which slightly reduces clarity.

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 explains how to use the 'tipo' parameter to select the desired data type and mentions bulk support with 'patient_ids'. However, it does not provide explicit guidance on when to use this tool versus sibling-specific tools like 'webdiet_list_anexos' or 'webdiet_orientacoes_list', leaving the agent to infer.

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 it's read-only, idempotent, non-destructive. The description adds what data is returned (appointments, tasks, birthdays, events), providing 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?

The description is a single sentence, concise and front-loaded with the purpose. It could be slightly more structured but is 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 no output schema and simple parameters, the description lists the types of items returned. However, it lacks details on date format or any constraints, and ignores the 'account' parameter.

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 should explain both parameters. It explains 'date' (defaults to today) but does not mention the 'account' parameter, leaving its purpose unclear.

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 loads the nutritionist's calendar/agenda for a date, listing specific items (appointments, overdue tasks, birthdays, events). This distinguishes it from sibling tools like webdiet_get_consultations or webdiet_prontuario.

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 tool versus alternatives. The description only mentions defaults to today, but does not explain when to use it instead of similar tools like webdiet_get_consultations.

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 safety traits; description adds workflow details about output format and execution steps, going 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?

Concise single paragraph with clear front-loaded purpose and structured steps, no wasted words.

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?

Explains output format and next steps well despite no output schema; minor lack of error handling 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?

Schema has 0% description coverage; description only mentions file_path in context, leaving account and file_name 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?

Clearly states it returns a curl command for file upload, distinguishing it from sibling tools like webdiet_upload_anexo which attaches after upload.

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 recommends for large files, provides a step-by-step flow, and names the next tool to call (webdiet_upload_anexo).

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, idempotentHint, and destructiveHint, so the tool is clearly safe. The description adds context about the is_default flag and the add_account_url usage, which goes 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 sentences, front-loaded with purpose. Minor issue: the second sentence mixes languages ('como link clicável') and is slightly verbose, but overall concise.

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?

Describes return fields and special behavior (add_account_url), but does not explain the optional 'account' parameter's purpose. Without output schema, description is incomplete for a simple list 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 has one optional parameter 'account' with no description and 0% coverage. The description does not mention this parameter, failing to add meaning. With zero coverage, the description should compensate but does not.

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 clearly states 'List all WebDiet accounts linked to this install' with a specific verb and resource. It also details the returned fields (id, email, label, is_default) and distinguishes from siblings, as no other tool lists accounts.

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?

Provides guidance on when to use the returned add_account_url (for adding accounts) and explains the is_default flag. However, it does not explicitly state when to use this tool versus alternatives or when not to use 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?

Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe reads. Description adds useful context: bulk execution via patient_ids, approximate item count (~238), and the nature of items (PDFs about nutrition). 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?

Description is concise with three sentences, front-loaded with the main purpose. Each sentence adds value: purpose, subtype differentiation with alternative, and bulk support. No unnecessary words.

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, but the tool is a simple list operation; the description covers the main input semantics and safety profile via annotations. Minor missing detail on output format or account parameter, but overall sufficient for agent use.

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 description compensates by explaining the 'tipo' enum (laminasAnexos vs cloudAnexos) and mentioning 'patient_ids' for bulk support. However, 'account' parameter is not described, leaving a gap. Overall, adds significant meaning beyond 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 states the tool loads educational slides or cloud file attachments, with specific subtypes (laminasAnexos vs cloudAnexos) and distinguishes from webdiet_orientacoes for guidelines. It uses specific verbs and resources.

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 tells when to use each tipo (laminasAnexos for educational slides, cloudAnexos for uploaded cloud files) and directs to webdiet_orientacoes for guidelines. Also mentions bulk support for batched execution.

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 mark the tool as read-only and idempotent. The description adds that it returns data, which is consistent. No additional behavioral details like authentication or side effects are provided.

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?

Single sentence with clear, concise information. No unnecessary words, front-loaded with 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?

Output is described sufficiently for a list tool, but parameter semantics are missing. No output schema exists, but the return format is covered. Overall adequate but incomplete.

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 fails to explain the 'tipo' and 'account' parameters. Without parameter documentation, the agent cannot use the tool correctly.

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 verb 'load', the resource 'patient welcome message templates', and the output 'active layout and all available template layouts'. It distinguishes from sibling list tools by specifying a unique resource.

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 guidance on when to use this tool versus other list tools like webdiet_list_accounts or webdiet_list_anexos. Missing context about prerequisites or conditions.

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 mark destructiveHint: true. Description adds 'irreversible' and details about bulk support (patient_ids, manipulado_ids), providing useful behavioral context beyond annotations. No contradictions.

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, front-loaded sentences. First states the essential purpose and irreversibility; second adds bulk support. No wasted words.

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 the core action and bulk feature, but lacks details on return behavior, error conditions, or parameter usage rules. Given no output schema and simple tool, it is minimally adequate but has clear gaps.

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%. Description only explains the array parameters (patient_ids, manipulado_ids) for bulk execution, but does not clarify the singular parameters (patient_id, manipulado_id, account) or required combinations. This is insufficient to compensate for the lack of 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?

Description clearly states the tool's purpose: 'Permanently delete a manipulado for a patient.' It specifies the resource (manipulado), action (delete), and context (patient). The mention of bulk support further clarifies functionality, distinguishing it from sibling tools like list, get, and write.

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—when deletion is needed—and warns of irreversibility. It does not explicitly name alternatives or when not to use, but given there is no other delete tool among siblings, the guidance is adequate.

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=true and idempotentHint=true. The description adds context: the data source (WebDiet formula bank), bulk support via patient_ids and manipulado_ids, return of HTML content, and default behavior for incluir_bloqueados. This goes beyond annotations, though the mixed action listing slightly detracts.

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 verbose with bullet points and extraneous detail on list_banco and list actions that likely belong to sibling tools. A more concise focus on the get action would improve clarity and reduce cognitive load.

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 domain (compounded formulas), bulk execution, and return format (HTML content) for the get action. However, the inclusion of list parameters and actions without output schema or pagination details reduces completeness. The tool appears to bundle multiple operations, making it less focused.

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 explains keyword (busca livre na indicação clínica), categoria (enum), and incluir_bloqueados (default false). It also mentions patient_ids and manipulado_ids for batching. However, parameters like limite, account, patient_id, and manipulado_id are left unexplained, leaving gaps.

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 'Flattened action: get' but then lists list_banco and list actions with detailed parameter mappings, blending multiple operations into one tool. This conflicts with the tool name and sibling tools like webdiet_manipulados_list and webdiet_manipulados_list_banco, making the actual purpose unclear.

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 mentions alternative write and delete tools but fails to clarify when to use this get tool versus the separate list tools. By including list parameters and actions within the description, it does not provide clear when-to-use guidance and may mislead an agent into using this tool for list operations that have dedicated 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 declare readOnlyHint=true and destructiveHint=false, and the description aligns by calling it a 'Read' tool. It further details behavior: list_banco searches a bank with filters, list gets prescribed items, get fetches full HTML. This adds useful context beyond annotations, though the 'Flattened action' note slightly muddles.

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 well-organized with sections for actions, but it is somewhat verbose (e.g., the 'Flattened action: list' line seems extraneous). While informative, it could be trimmed without losing value.

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 missing output schema, the description thoroughly explains return values for each sub-action (e.g., nome, categoria, texto_html, bloqueado for list_banco; id, nome, data, liberado, pdf_url for list; full HTML for get). It also covers bulk behavior and links to related tools, making the tool fully self-explanatory.

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 must explain parameters. It covers keyword, categoria, incluir_bloqueados, and patient_ids/manipulado_ids for bulk, but omits explanation of limite, account, patient_id, and manipulado_id. The description adds meaning beyond the schema (e.g., enum values, default behavior) but is incomplete for all nine 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 clearly states it reads 'Prescrição de manipulados' and lists three sub-actions (list_banco, list, get), distinguishing it from write and delete siblings. However, the 'Flattened action: list' line is confusing and somewhat contradicts the multiple actions described, slightly reducing clarity.

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 tells when to use this tool (read operations) and when not (write/delete refer to webdiet_manipulados_write and webdiet_manipulados_delete). It also explains the three sub-actions with their purposes and mentions bulk support for batched execution, providing comprehensive 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 readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the tool searches ~249 templates, returns fields like nome, categoria, texto_html, bloqueado, and supports bulk execution. No side effects or permissions mentioned, but annotations cover the safety profile sufficiently.

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?

Description is well-structured with bullet points for actions. It front-loads the main purpose and then details parameters. However, it includes information about other tools (list, get) which, while relevant, adds length beyond the scope of this specific tool. Could be trimmed for more focus.

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 (9 params, no output schema, no parameter descriptions in schema), the description covers the bank search well with filter categories and returned fields. But it fails to describe all parameters (e.g., limite, patient_ids) and does not explain bulk behavior or output format fully. Adequate but incomplete.

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 description must compensate. It explains keyword, categoria (with enum values), and incluir_bloqueados (with default behavior). However, it omits descriptions for limite, patient_id, patient_ids, manipulado_id, and manipulado_ids, leaving gaps for the agent. Bulk support is mentioned but not detailed.

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 clearly states the tool reads 'Prescrição de manipulados' and specifically handles searching the formula bank (list_banco). It distinguishes from siblings by explicitly directing write operations to webdiet_manipulados_write and destructive delete to webdiet_manipulados_delete. The verb 'search' is implied through filtering parameters.

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?

Description provides clear context for when to use this tool (searching formula bank) and directs to alternative tools for write and delete operations. However, it does not explicitly state when not to use this tool for other read actions like listing already prescribed formulas (handled by webdiet_manipulados_list).

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 indicate readOnlyHint=false and destructiveHint=false. Description aligns by describing write operations (create, send, publish, duplicate) and no destructive behavior. It adds some behavioral details (e.g., send immediately liberates, publish toggles visibility) but lacks coverage on permissions, rate limits, or side effects beyond those described.

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 longer than necessary and includes information about actions that may not be relevant to this specific tool. The bullet list and '[Flattened action: duplicate]' note add some structure, but there is redundancy and mixed language (Portuguese/English).

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 (8 parameters, no output schema, minimal annotations), the description should be more complete. It covers multiple actions but blurs the tool's specific role. It mentions bulk support but does not explain return values or behavior edge cases. The description is incomplete for an agent to reliably 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 has 8 parameters with 0% coverage in schema descriptions. The description explains 'texto' as raw HTML and 'nome' as formula name, and mentions using 'manipulado_id' for updates. However, it does not explain 'nomes', 'account', 'patient_ids', or 'manipulado_ids' in detail, leaving gaps.

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 covers multiple actions (save, send, publish, duplicate) but the tool name ends with 'write_duplicate' and sibling tools exist for save, send, and publish. This creates confusion about the tool's specific purpose. The '[Flattened action: duplicate]' note tries to clarify but the description still lists all actions, obscuring the primary function.

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 mentions a separate tool for delete but does not specify when to use this duplicate tool versus the other write_* sibling tools (save, send, publish). No explicit guidance on when to choose this tool over alternatives is 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?

Annotations indicate mutations (readOnlyHint=false, destructiveHint=false). The description adds specific behaviors: save returns id and pdf_url, send makes liberado=true immediately, publish toggles visibility, and duplicate creates a copy. Bulk support is mentioned. No contradiction with annotations, but the flattened action note causes confusion.

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 well-structured with action bullets, front-loaded summary, and no excessive fluff. The puzzling '[Flattened action: publish]' and redundant mention of the delete sibling add minor clutter.

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 multi-action complexity and no output schema, the description covers each action's core behavior and return values for save, but lacks full return details for other actions. It does not explain how to invoke specific actions (no action parameter) and fails to disambiguate from sibling tools.

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 partially compensates by explaining 'texto' (raw HTML), 'nome' (formula name), and 'manipulado_id' (omit for create, pass for update). However, parameters like 'account', 'patient_ids', 'manipulado_ids', and 'nomes' are left undefined, and bulk support usage is vague.

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 it creates, sends, publishes, and duplicates manipulados, listing each action with specific verb+resource. However, the tool is named 'write_publish', which is misleading since it also includes save, send, and duplicate; plus, sibling tools exist for those actions without differentiation.

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 mentions to use a sibling tool for delete, but does not clarify when to use this tool versus the separate write_save, write_send, or write_duplicate tools. The note '[Flattened action: publish]' suggests it might only be for publish, conflicting with the broader action list, and no action parameter exists in the schema.

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 useful behavioral details for the save action (create vs update, returning id and pdf_url) and mentions bulk support. Since annotations only give basic hints, the description adds significant value. However, the inclusion of other actions slightly dilutes focus, but still transparent enough for the save operation.

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 overly verbose, mixing information for multiple actions that likely belong to separate tools. It lacks a clear structure focused on the save action, with unnecessary details about send, publish, and duplicate.

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 8 parameters, no output schema, and the need to clearly define the save action, the description is incomplete. It fails to explain all parameters, does not clarify error conditions, and the scope confusion undermines completeness for the primary save 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?

With 0% schema description coverage, the description must explain all 8 parameters. It explains some (nome, texto, manipulado_id) but omits account and nomes, and provides no detail on how parameters like nomes are used. This leaves gaps for the AI agent.

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 lists multiple actions (create, send, publish, duplicate) but then states 'Flattened action: save', creating confusion about the tool's actual scope. The title is null, and the description does not clearly restrict the tool to the save action, making it misleading for an AI agent to determine its primary purpose.

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 mentions using webdiet_manipulados_delete for destructive actions, but fails to guide the agent to use separate sibling tools (webdiet_manipulados_write_send, etc.) for send, publish, and duplicate. This omission may lead the agent to incorrectly expect this tool to handle those actions.

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 important behavioral context beyond annotations: send auto-sets liberado=true, publish toggles visibility and returns new state, duplicate copies with suffix, send skips blocked formulas. 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?

The description is well-structured with action bullets and front-loaded purpose. Some redundancy (e.g., 'Flattened action: send') could be trimmed, but overall it's clear and 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?

The description covers behavior for all four actions, return values for save and publish, and bulk support. Lacks explicit return info for duplicate and send, but given complexity, it is fairly 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 description explains key parameters like 'texto' (raw HTML) and 'nome' (formula name), and mentions bulk parameters. However, with schema coverage at 0%, some parameters like 'account' and 'nomes' remain unexplained, though context can be inferred.

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 it creates, sends, publishes, and duplicates manipulados, with each action explained. It distinguishes from sibling tools like webdiet_manipulados_delete and webdiet_manipulados_write_save.

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 explicit when-to-use guidance for each action (save, send, publish, duplicate) and notes that destructive delete should use a different tool. It also mentions bulk support.

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, idempotentHint, destructiveHint. The description adds valuable behavioral context: it's a read operation, supports bulk via patient_ids, and mentions the 'flattened action: list' mechanism. No contradictions.

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 well-structured with sections for actions, banking, and bulk support. It is slightly lengthy but every part adds value. A minor trim could improve 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?

No output schema is provided, and the description does not mention return format or pagination. It adequately covers the main use cases (list patient orientations and bank), but lacks details on response structure, which is important for an agent to process 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%, so the description must compensate. It only explains the patient_ids parameter for bulk support. The meanings of limite, account, and patient_id are not clarified, leaving most 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 clearly states that the tool reads 'Listas e Orientações' and lists actions (list, list_banco) with specific resources. However, the presence of a separate sibling tool 'webdiet_orientacoes_list_banco' introduces potential confusion about whether this tool actually handles both actions, despite the 'Flattened action: list' note.

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 distinguishes between patient-specific orientation lists and the orientation bank, and provides cross-tool guidance: 'Use list_banco to see available names, then pass those exact names to webdiet_orientacoes_write action=send.' This gives clear when-to-use and alternative tool context.

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 and destructiveHint, so the description adds useful context about the orientation bank being saved favorites and bulk execution. No contradictions, and the description complements the annotations well.

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 well-structured with clear sections for actions, bank explanation, and bulk support. It could be slightly more concise, but it is front-loaded and reasonably 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 no output schema and 4 parameters, the description adequately explains the tool's purpose and batch support but lacks details on return values or how results are structured. This is a noticeable 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?

With 0% schema description coverage, the description should compensate but only mentions that patient_ids supports batched execution. It does not explain limite, account, or patient_id. This is insufficient for clarity.

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 reads 'Listas e Orientações' and distinguishes between 'list' and 'list_banco'. It specifies that list_banco retrieves the nutritionist's saved/favorite orientations, making the purpose very clear.

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 when to use list_banco vs list and provides a workflow: use list_banco to see available names, then pass them to webdiet_orientacoes_write action=send. It also mentions bulk support with patient_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 provide basic hints (not readOnly, not destructive). The description adds valuable behavioral context: HTML entity encoding for emojis, automatic <h1> prepending for title, and bulk support. This goes beyond annotations, though auth needs and other side effects are omitted.

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 mostly concise (6 sentences), though it repeats the action concept and could be tightened. Front-loaded with purpose, but the flattened action note adds minor clutter.

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 8 parameters, no output schema, and no enums, the description explains key behaviors for two parameters and bulk support, but misses return values, error states, and behavior for undocumented parameters.

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 adds meaning for 'texto' (HTML encoding) and 'titulo' (h1 prepended), but leaves other parameters like 'nomes', 'orientacao_id' unexplained. Partial compensation.

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 creates/updates/sends 'Listas e Orientações' in WebDiet, with a flattened action of save. It distinguishes from sibling tools like list and send by focusing on the save 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 implies the tool is for modifying orientations but does not explicitly state when to use it over sibling tools like 'webdiet_orientacoes_write_send' or 'webdiet_orientacoes_list'. No exclusion criteria or alternatives are mentioned.

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 discloses important behaviors: HTML entity encoding for emojis in 'texto', prepending <h1> when 'titulo' is set, and bulk support via patient_ids/orientacao_ids. Annotations provide no hints (all false), so the description adds significant value beyond them. However, it could mention idempotency 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 relatively concise with two main sentences plus a note on bulk support. However, the line '[Flattened action: send]' is cryptic and could confuse. Overall, it is efficient but slightly cluttered.

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 8 parameters, 0% schema description, no output schema, and no nested objects, the description is moderately complete. It explains two actions and key behaviors but leaves many parameters unexplained and does not describe return values or error conditions. Adequate but not thorough.

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 adds meaning to 'texto' (emojis encoding) and 'titulo' (prepended <h1>), and mentions bulk arrays. But it does not explain 'nomes', 'account', 'patient_id', or 'orientacao_id'. Partial coverage leaves gaps.

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 handles 'Create/update/send' for 'Listas e Orientações' in WebDiet. It distinguishes between save and send actions, but the '[Flattened action: send]' line introduces ambiguity about which action is currently active. Overall, the verb+resource is clear.

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 does not provide explicit guidance on when to use this tool versus siblings like webdiet_orientacoes_write_save. It mentions both save and send actions but does not indicate which scenario calls for each. No alternatives or exclusions are discussed.

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 value beyond annotations by explaining internal behavior ('uses removerPaciente — resolves id/link from a fresh list first') and emphasizing irreversibility. Annotations already set destructiveHint=true, and description aligns without contradiction.

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 concise with two short paragraphs: one stating purpose and internal details, another noting bulk support. No redundant or extraneous 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?

Given the tool's simplicity and lack of output schema, the description adequately covers the core action, irreversibility, and bulk capability. It does not discuss success/failure response, but for a delete operation this is 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?

With 0% schema description coverage, the description partially compensates by explaining that 'patient_ids' enables bulk execution, but does not document the 'account' parameter or provide details on 'patient_id' format. Meaningful improvement over schema is limited.

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 action ('Permanently delete a WebDiet patient') and the resource, with additional context on internal mechanics and irreversibility. It distinguishes from sibling tools like get, list, create, update as the only delete 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 implies caution with 'Irreversible' and mentions bulk support, but does not explicitly state when to use this tool vs. alternatives (e.g., when not to use, prerequisites like authentication). No comparison with other patient tools is 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint; description adds pagination behavior, fallback mechanism (dadosPaciente.php), and bulk support. No contradictions.

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?

Description is structured with clear sections but slightly verbose. The 'IMPORTANT' note and 'Flattened action' hint add value but could be integrated more concisely.

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 no output schema, description covers return data for both actions, pagination, and bulk execution. Missing details on error handling or rate limits, but adequate for read-only tool with safe annotations.

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?

Parameter schema has 0% coverage; description explains keyword, patient_id, patient_ids, and mentions pagination implicitly (page, page_size). However, 'account' parameter is undocumented. Partial compensation for low schema coverage.

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?

Clearly states 'Read patients in WebDiet' and details two actions (list and get) with specific return fields. Differentiates from siblings by explicitly covering both actions in one tool, while sibling 'webdiet_patient_list' suggests a separate list-only 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?

Provides context for using IDs from this tool in write operations, but does not explicitly guide when to choose this tool over siblings like 'webdiet_patient_list'. No 'when not to use' instructions, leading to ambiguity.

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, and the description reinforces that it's a read operation. It adds important behavioral traits: pagination behavior, fallback mechanism when id is not on first page, and bulk execution support. No contradictions.

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 moderately concise, front-loading the main purpose and using a structured note for important details. Some redundancy ('IMPORTANT' section) could be trimmed, but it remains clear and well-organized.

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 absence of an output schema, the description adequately covers return values for both actions (id, name, link for list; full profile for get) and mentions direct URLs. It addresses pagination and fallback. Missing are error handling or rate limits, but overall fairly complete for a read tool with two actions.

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 explain parameters. It does so for most: keyword for search, page/page_size for pagination, patient_id for get, patient_ids for bulk. The 'account' parameter is not explained, but overall adds significant meaning beyond the bare 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 states 'Read patients in WebDiet' and breaks down two distinct actions (list and get) with their specific returns. It distinguishes itself from sibling patient tools by covering both listing and getting in a single tool, and mentions bulk support.

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 guidance on pagination and how to use identifiers for writes, but does not explicitly contrast when to use this tool vs. other patient tools like webdiet_patient_get or write tools. It implies usage context for both list and get actions.

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 critical warning about nascimento being required to avoid a Fatal Error, which is valuable beyond the annotations. It does not discuss rate limits, authentication, or other behaviors, but the warning provides significant 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?

The description is relatively concise and front-loaded with the main action. The warning about nascimento is well-placed. However, some phrasing could be more structured to improve readability.

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 high parameter count (19) and lack of output schema, the description leaves many details undocumented. It does not explain the update return value, full list of parameters, or error scenarios beyond the crash warning. Significant gaps remain.

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 only explains key parameters (nome, nascimento, patient_id, patient_ids) but fails to document the other 15 parameters (e.g., cep, cpf, email). The format for nascimento is given, but overall parameter coverage is insufficient.

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 creates or updates patients in WebDiet, and specifies the required fields for create action. However, the sibling tool 'webdiet_patient_write_update' exists which may cause confusion about when to use each, and the note '[Flattened action: create]' adds 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?

Provides explicit guidance: when to use create vs update, points to webdiet_patient_delete for destructive removal, and mentions bulk support. However, it does not differentiate from the sibling update tool, which could lead to confusion.

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 show non-read-only, non-destructive, consistent with description. Adds important behavioral context: crash without nascimento, bulk support. No contradictions.

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?

Relatively concise but contains internal note '[Flattened action: update]' which may confuse. Key info front-loaded; some redundancy in mention of actions.

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?

Missing details: no output schema, return value for create mentioned but not for update, bulk usage not explained. With many parameters and sibling overlap, description insufficient for complete understanding.

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 coverage and 19 parameters, description only explains nome and nascimento. Most fields (cep, cpf, etc.) lack semantic explanation, leaving agent to infer from names.

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?

Describes create/update actions clearly with required fields. However, sibling webdiet_patient_write_create exists and overlap not explained, reducing differentiation.

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 states when to use create vs update and points to webdiet_patient_delete for destructive removal. Provides critical warning about nascimento. Does not address distinction from separate create 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 description adds context beyond annotations, such as 'Templates are NOT affected' and 'Bulk support', and aligns with the destructiveHint annotation. No contradictions.

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 with essential information upfront, no wasted words.

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 primary function, irreversibility, bulk support, and template exemption. Lacks details on error handling or authorization but is sufficient for a delete 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?

With 0% schema coverage, the description explains 'response_ids' for bulk support but does not clarify the 'account' parameter, providing only partial compensation.

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 'Permanently delete a pre-consultation response in WebDiet' with specifics like 'Templates are NOT affected' and 'Irreversible', clearly defining the action and distinguishing it from other 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 indicates when to use (to delete a pre-consultation response) and mentions bulk support, but lacks explicit guidance on when not to use or 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds that it reads questionnaires and supports batched execution via response_ids, which is useful but does not contradict annotations. However, the description's multi-action nature is not fully transparent about how the tool decides which action to perform.

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 long but uses bullet points for structure. It contains redundant information and is not front-loaded; the first sentence is generic. Could be more concise by focusing on the primary get_response action and mentioning sub-actions briefly.

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 existence of sibling tools for listing, the description should clarify why this tool exists as a composite. It lacks explanation of how the tool selects the sub-action based on parameters, and missing parameter details reduce completeness. No output schema is provided, but the description does list return fields for list actions.

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 must explain parameters. It partially explains nome and tipo as filters for list_responses, but limit, offset, account, response_id, and response_ids are not explained. The meaning of 'response_id' seems clear but is not explicitly linked to get_response.

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 lists multiple actions (list_templates, list_responses, get_response) under the tool name 'get_response', creating ambiguity. The 'Flattened action' note suggests the intended use is get_response, but the inclusion of other actions conflates purposes and is confusing given separate sibling tools for listing.

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 some usage hints for list_templates ('USE THIS when...') and mentions filters for list_responses, but it fails to differentiate this tool from its siblings webdiet_preconsulta_list_responses and webdiet_preconsulta_list_templates. No clear guidance on when to use this composite tool vs. the dedicated list tools.

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=true, idempotentHint=true, destructiveHint=false, so the base behavioral profile is clear. The description adds that it supports batched execution via response_ids and lists the response fields returned. However, the description also suggests it can list templates and get individual responses, which are inconsistent with the tool's primary function and schema parameters. This inconsistency reduces 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 lengthy and includes a bulleted list of three actions, which is excessive for a tool that is supposed to focus on list_responses. The 'Flattened action: list_responses' annotation helps, but the earlier list creates confusion. Information is repeated (e.g., mention of 'link_to_patient' both in the list and at the end). The description could be much more concise.

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 (7 parameters, no output schema), the description is incomplete. It explains some response fields but not all parameters, and it incorrectly extends to actions handled by other sibling tools. The lack of explanation for account, limit, offset, and the ambiguous response_id leaves gaps. The description would benefit from focusing solely on list_responses and detailing all parameters and 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 explain parameters. It only explains 'tipo' and 'nome' as filters, and mentions 'response_ids' for bulk support. Other parameters like 'limit', 'offset', 'account', and 'response_id' are not explained. 'response_id' is ambiguous given the get_response mention. This leaves the agent uncertain about how to use most 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 states it reads pre-consultation questionnaires, but then lists three separate actions (list_templates, list_responses, get_response) which conflates multiple purposes. The tool name and flattened action indicate 'list_responses' is the primary function, but inclusion of other actions confuses the agent. Without clear differentiation from sibling tools 'webdiet_preconsulta_list_templates' and 'webdiet_preconsulta_get_response', the purpose lacks clarity.

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 some usage guidance: for listing responses, use filters tipo and nome; linking responses to patients is done via another tool. However, it does not explicitly explain when to use this tool versus its siblings for templates or individual responses. The mention of list_templates and get_response within the description may mislead the agent into thinking this tool handles those functions, which it likely does not based on the schema.

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, destructiveHint=false. The description adds that this tool reads templates and returns specific fields (link, preview_url). This adds some context but does not disclose additional behavioral traits beyond what annotations provide. No contradictions.

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 includes a bulleted list of three actions, but only list_templates is relevant. The information about list_responses and get_response could be confusing and adds length. The description is not tightly focused on the flattened action.

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 7 parameters, 0% schema coverage, no output schema, and many sibling tools, the description is incomplete. It does not explain parameters, differentiate clearly from list_responses or get_response, or describe return structure adequately. The inclusion of other actions in the description adds confusion rather than clarity.

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%, meaning no parameters are described in the input schema. The description fails to explain any of the 7 parameters (nome, tipo, limit, offset, account, response_id, response_ids). Users have no guidance on how to use these parameters, which 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 that this tool reads questionnaire templates in WebDiet and specifically mentions it lists templates with fields like nome, descricao, perguntas, etc. It also gives a usage tip for the 'link do questionário'. However, it includes extraneous details about other actions (list_responses, get_response) which slightly dilutes focus.

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 when to use this tool (when user asks for 'o link do questionário de pré-consulta'). It also mentions other actions for different tasks (responses, linking). However, it does not explicitly state when NOT to use this tool or contrast with sibling tools beyond the preconsulta set.

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