WebDiet

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

Annotations already declare idempotentHint=true and non-destructive, so description adds little behavioral context beyond token handling. 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 informative and front-loaded, though slightly verbose; every 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?

Given no output schema, the description explains the two authentication methods adequately, though it could mention what the tool returns (e.g., success confirmation).

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

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

The schema has 0% description coverage for the token parameter, but the description explains it is a JWT for session login and also covers the no-arg case, compensating well.

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, specifying two methods (permanent config header vs session token) and distinguishing itself from sibling tools like 'connect'.

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 guidance on when to use the tool and how to use it (with or without token parameter), but does not explicitly mention when not to use it 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=true, so the description adds value by detailing response states (authenticated vs missing credentials) and the presence of connect_url. This provides behavioral context beyond safe read.

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

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

The description is two concise sentences with key information front-loaded. Every part is meaningful and there is no extraneous content.

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, the description fully explains the return values (authenticated, pending, connect_url) for different states. This is sufficient for a simple status check 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?

There are zero parameters, so the description correctly adds no parameter information. With 100% schema coverage and no parameters, it meets the baseline expectation for a parameterless tool.

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 'Returns connection status and URLs,' which is a specific verb and resource. It distinguishes itself from siblings like 'authenticate' by focusing on status rather than performing authentication.

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 checking connection status but does not explicitly mention when to use this tool versus alternatives like 'authenticate' or when not to use it. There is no guidance on prerequisites or 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?

Beyond the sparse annotations, the description discloses key behavioral traits: invoke works without installing and does not bloat the toolkit, install makes an MCP permanent, writes require workspace owner/admin, and invoke returns connect/checkout links when needed. These details go well beyond readOnlyHint and destructiveHint, and there is no contradiction with 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 long but justified by the tool's 14 actions. It is front-loaded with purpose and core flow, then organized into main use cases and the prompt library. There is little filler, though the density of semicolon-joined clauses makes it slightly harder to parse than ideal.

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 broad orchestrator with no output schema and many optional parameters, the description covers the key contexts: catalog search, one-off invocation, installation, billing, auth, and prompt library. It does not specify return formats or per-action output details, but given the tool's openWorldHint and multi-purpose nature, the provided context is strong.

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 23 parameters and 0% schema description coverage, the description must compensate. It does explain the central action enum and maps the search/describe/invoke flow to concepts like mcp_id and tool_id, but many other parameters (limit, immediate, tier_slug, cancel_reason, prompt_targets, report_context, etc.) remain undefined. The description is helpful but not sufficient for full parameter understanding.

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 is highly specific and immediately establishes the tool as the mcp.ai marketplace: 'the in-platform catalog of every MCP/tool, AND the way to run them.' It gives concrete example queries and distinguishes the tool from the sibling webdiet tools, making its purpose unmistakable.

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 workflow guidance: search → describe → invoke, and clearly contrasts invoke vs install ('prefer invoke for a single/occasional use') and explain when to use request_mcp ('when nothing fits'). It also covers auth requirements and retry flows for credentials/payment, which is exemplary when-to-use 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 indicate idempotentHint=true and destructiveHint=false, and the description adds value by specifying the need to include conversation for reproduction, 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 concise with one sentence and an instruction, but lacks explicit structuring for parameters. It is front-loaded 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?

Given 3 parameters and no output schema, the description covers purpose and a key usage hint but misses explaining the 'context' parameter and what happens after reporting, making it adequate but not 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?

Schema description coverage is 0%, so the description should compensate. It only mentions the 'conversation' parameter partially and omits details on 'context' and 'message', 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 clearly states the tool reports bugs, missing features, or feedback, which is a specific verb-resource pair. It distinguishes itself from siblings; no other sibling tool covers reporting issues.

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 instructs to include the conversation array, providing clear context for usage. Since there are no alternative reporting tools, explicit exclusions are unnecessary.

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, destructiveHint=false, and idempotentHint=true, which fully describe the tool's safe, read-only behavior. The description adds no additional behavioral context, but does not contradict annotations either.

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

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

A single, front-loaded sentence with no extraneous words. 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, parameterless read-only tool with no output schema, the description is fully complete. It states exactly what the tool returns (platform and adapter versions).

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?

There are zero parameters and schema coverage is 100%, so the description does not need to add parameter information. It could explicitly state 'takes no arguments', but the schema already makes this clear.

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 'Show the current MCP platform and adapter versions', specifying the verb (show) and the resource (versions). It is distinct from all sibling tools, which perform various CRUD operations on different 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 implies when to use (when version info is needed) and there are no similar sibling tools to cause confusion. No explicit alternatives are given, but none are necessary given the tool's simplicity.

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, and the description confirms it is a read operation. However, the description does not disclose any additional behavioral traits such as authentication requirements, response size, or potential delays. It adds only surface-level 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 a single, front-loaded sentence of 15 words with no redundancy. Every word adds value, making it both concise and clear.

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 has no parameters and no output schema, the description is adequately complete for its purpose. It specifies exactly what the tool returns (MCPs, connection status, catalog tools count) and is sufficient for an agent to understand the tool's function.

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

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

The tool has zero parameters and the schema coverage is 100% (trivially). Per guidelines, baseline for 0 params is 4. The description adds no parameter information, but none is 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?

The description clearly states the tool returns the current toolkit state, including installed MCPs, connection status, and number of catalog tools each exposes. It uses a specific verb ('Returns') and defines the resource, distinguishing it from sibling tools like show_version or authenticate.

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 (to check toolkit state) but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions. Given the large number of sibling tools, more explicit guidance would help.

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, idempotentHint=true, destructiveHint=false. Description adds that it decodes URL-encoded HTML and provides both plain-text and HTML representations. 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 relatively concise with a few sentences and bullet points. Front-loaded with main action. Includes some internal data representation details that could be trimmed, but overall 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?

No output schema provided, but description explains return fields adequately. Covers main use case, bulk support, and decoding behavior. Sufficient for a read-only 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 3 params with 0% description coverage. Description adds meaning by explaining patient_id is required and patient_ids for batched execution, but does not detail the account parameter. Compensates somewhat but not fully.

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 lists anamnesis records with full Q/A content, specifies returned fields, and distinguishes from sibling tool webdiet_preconsulta.

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 says when to use vs. webdiet_preconsulta for not-yet-linked responses, and mentions bulk support via patient_ids. Does not explicitly state when not to use, but context is clear.

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

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

Annotations already provide destructiveHint=true. The description adds 'Irreversible' and 'bulk support', which reinforces the permanent nature. No additional behavioral traits (e.g., side effects, auth needs) are disclosed, but the annotations carry the safety burden. Acceptable for a simple delete 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 very concise: two sentences, front-loaded with the core action. Every word adds value, no fluff.

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 has 5 parameters (0% schema description), no output schema, and is destructive, the description is too sparse. It does not explain the return value, prerequisites (e.g., account authentication), or how to use the singular required parameters. Sibling tools are clearly related, but the description lacks differentiation details beyond name.

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 description coverage is 0%, so the description must explain parameters. It mentions 'patient_ids, anamnese_ids for batched execution' but does not clarify the singular required parameters (patient_id, anamnese_id) or the account parameter. This leaves ambiguity about how to perform single vs. bulk deletions.

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') and the resource ('anamnesis record'), and explicitly mentions irreversibility. It distinguishes from sibling tools like webdiet_anamnese (list/get) and webdiet_anamnese_write_save (create/update) by focusing on deletion.

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 the tool (for deletion, including bulk operations via patient_ids and anamnese_ids). It lacks explicit when-not-to-use or alternative tools, but the context and name make usage clear.

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

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

Description states it's a write (non-destructive) and duplicate action, but does not detail side effects, auth requirements, or behavior with bulk inputs. Annotations provide basic hints, no 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?

Purpose stated first, then actions and bulk. Some redundancy (flattened action note), but no excessive wording. Could be more streamlined.

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?

Lacks explanation of most parameters, return behavior, and details on duplicate process. With low schema coverage and no output schema, agent is left with ambiguity.

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?

Low schema coverage and description only hints at bulk usage of patient_ids/anamnese_ids, leaving most parameters (texto, titulo, account, interpretacao) unexplained. Agent cannot infer how to fill parameters without guessing.

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 duplicates anamnesis records, lists actions but flattens to duplicate, and distinguishes from sibling tools like webdiet_anamnese_delete and other write variants.

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?

States duplication purpose, references destructive deletion tool, implies save variants exist as siblings. Lacks explicit when-not advice but enough 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 indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds value by specifying that the tool handles creation and update, and explicitly references the delete sibling for destructive actions. It also mentions bulk execution. However, it lacks details on side effects (e.g., whether it replaces or merges data), return values, or authorization requirements, leaving some behavioral aspects undisclosed 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 front-loaded with the primary purpose and key actions. It is reasonably concise but includes some extraneous details (e.g., listing all actions when the tool is for 'save' only). The structure is logical, with the main purpose first, followed by clarification of the flattened action and bulk support. A slight reduction in redundancy 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?

Given the tool's complexity (8 parameters, 1 required, no output schema), the description covers the core operation and bulk support but lacks explanations for multiple parameters (`texto`, `titulo`, `account`). It also does not describe return values or post-conditions. While adequate for basic use, gaps in parameter semantics and behavioral details reduce completeness.

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 compensate. It explains the role of `anamnese_id` (empty = new), and bulk support for `patient_ids` and `anamnese_ids`. However, it omits explanations for `texto`, `titulo`, `account`, and `interpretacao` (though `interpretacao` may relate to a sibling tool). This leaves several parameters semantically unclear, limiting the agent's ability to use them 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 tool's purpose: 'Create / update anamnesis records in WebDiet.' It specifies the action (save, create/update) and the resource (anamnesis records). It distinguishes from the sibling `webdiet_anamnese_delete` for destructive removal, and the mention of 'Flattened action: save' clarifies that this tool focuses on the save operation, differentiating it from other write actions like duplicate and save_interpretation which are separate sibling 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 provides clear context for when to use this tool (to create or update anamnesis records) and explicitly directs users to `webdiet_anamnese_delete` for destructive removal. It also notes bulk support via patient_ids and anamnese_ids. However, it does not detail prerequisites (e.g., patient existence) or limitations, nor does it explicitly contrast with sibling write tools beyond the delete hint.

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 do not contradict (readOnlyHint=false, destructiveHint=false). The description adds that the action can create or update based on anamnese_id, and supports batch execution via patient_ids/anamnese_ids. This provides useful behavioral context beyond annotations, though idempotency or error handling is not mentioned.

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

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

The description is front-loaded with the main purpose, then lists actions, destructive alternative, and bulk support. It is relatively concise (5 sentences) with no redundant information. A bit more structure could improve readability, but it's effective.

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 coverage, the description covers the action logic and bulk capability but lacks details on return values, error conditions, and the effect of missing optional fields. The required parameter (patient_id) is not highlighted. Thus, completeness is moderate.

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% (no parameter descriptions in JSON schema). The description adds meaning for 'interpretacao' (interpretation field) and explains that anamnese_id empty means new record, and mentions batch parameters. However, parameters like texto, titulo, account remain unexplained, which is a gap.

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

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

The description clearly states the tool creates/updates anamnesis records with a flattened action of save_interpretation. It distinguishes from destructive deletion and other write tools (save, duplicate) by naming them explicitly, 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 provides a clear alternative for destructive removal (webdiet_anamnese_delete) and implies when to use this tool (for saving interpretations). However, it does not explicitly compare with sibling write tools like webdiet_anamnese_write_save or webdiet_anamnese_write_duplicate, which are separate 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?

Adds value beyond annotations: explains that the tool can list or get records, describes specific measurements returned (weight, height, skinfolds, etc.), includes direct URL field, and mentions batch execution. However, it does not clarify how the tool determines which action to perform based on input parameters, leaving some behavioral ambiguity.

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 at around 100 words with clear sections: purpose, actions, included fields, alternatives, bulk support. The 'Flattened action: get' line is slightly out of place and could be removed. Otherwise well-structured.

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

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

Covers many details: returned fields for both list and get, bulk capabilities, linking to external system. However, it lacks output schema and does not explain how to differentiate list vs get via parameters, nor does it describe units or interpretation of measurements. Additional context about response format and edge cases would improve completeness.

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 compensate. It explains that patient_ids and antropometria_ids are for batched execution, and implies that patient id parameters trigger list while antropometria_id triggers get. However, it does not explicitly map each parameter to its role or explain the behavior when multiple parameter types are provided.

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 anthropometry records' with specific verb and resource. It lists two actions (list and get) and distinguishes from create/save siblings by explicitly naming webdiet_create_antropometria and webdiet_save_antropometria. However, it does not differentiate from the sibling webdiet_antropometria_list, leaving ambiguity about overlap.

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 direction for when to use this tool vs create/save tools. Also mentions bulk support with patient_ids and antropometria_ids. However, it lacks guidance on when to use this tool versus the existing webdiet_antropometria_list sibling, and does not explain under what circumstances to use list vs 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?

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds behavioral detail about return fields (url, measurements) and bulk support, which is valuable 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 well-structured: summary, action breakdown, URL note, usage guidance, bulk support. It is informative but could be slightly tighter. However, it is not verbose and 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?

Given no output schema, the description explains return fields for both list and get, including the URL. It covers bulk support and mentions necessary IDs. Lacks explicit mention of account parameter, but overall adequate for a read 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 explain parameters. It mentions patient_ids and antropometria_ids for bulk, but does not describe account, patient_id, or antropometria_id. The purpose implies patient_id, but explicit schema details are missing.

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

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

The description clearly states it reads anthropometry records and distinguishes between list and get actions. It explicitly says 'Use this to analyze patient body composition evolution over time,' and contrasts with create/save tools, making purpose unmistakable.

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 when-to-use: 'analyze patient body composition evolution over time.' Also gives specific alternatives for writing: 'For creating/saving records, use webdiet_create_antropometria + webdiet_save_antropometria.' This fully clarifies when not to use this 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?

Annotations already provide destructiveHint: true, and the description reinforces this with 'Permanently delete' and 'Irreversible.' It adds the bulk execution detail beyond annotations, but lacks disclosure of other behavioral aspects like permissions or error states.

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 wasted words. The first sentence front-loads the primary purpose and irreversibility, and the second adds bulk support information efficiently.

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 and three parameters, the description covers the main action and bulk variant but omits explanation of the 'account' parameter and does not describe the expected response on success, leaving some contextual 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%, so the description must compensate. It explains the array parameter 'calculo_ids' for bulk use but does not clarify the single 'calculo_id' or the 'account' parameter, leaving gaps in understanding for all three 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 'Permanently delete an energy expenditure calculation. Irreversible.' The verb 'delete' and resource 'energy expenditure calculation' are explicit, and the qualifiers distinguish it from sibling tools like webdiet_calculo_energetico_get or webdiet_calculo_energetico_list.

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 'Bulk support: accepts calculo_ids for batched execution,' which provides guidance for using the bulk variant. However, it does not explicitly state when not to use the tool or compare it to other delete tools, leaving some context implicit.

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: it returns TMB and GET in specific units, and supports batch execution via patient_ids and calculo_ids. No contradictions 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 relatively short but contains redundant notes (e.g., '[Flattened action: get]') and an unnecessary action list that misaligns with the tool name. Could be more succinct and focused on the get 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?

Output fields are described, but missing details like required parameter combinations, error cases, or response format. With no output schema, the description should provide more context. Adequate for a simple tool but leaves 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?

With 0% schema description coverage, the description must explain parameters. It only mentions patient_ids and calculo_ids for batch, but does not clarify account, calculo_id, or patient_id individually, nor their combinations. Incomplete parameter documentation.

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 reads energy expenditure calculations (Cálculo Energético) and specifies it returns TMB and GET. However, it mentions both 'list' and 'get' actions, which is confusing because a separate sibling tool exists for listing. The flattening note 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?

No explicit guidance on when to use this tool versus the sibling 'webdiet_calculo_energetico_list' or other alternatives. The description implies it can both list and get, but the sibling list tool suggests this should only be for getting by ID. Lack of clear usage boundaries.

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=true and destructiveHint=false, and the description aligns with 'Read' behavior. It adds useful context about returned data (TMB, GET) beyond annotations. No contradictions; the description enhances transparency with specific result details.

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 short but includes some redundancy (e.g., Portuguese translation, 'Flattened action: list'). It could be more streamlined without losing clarity. Every sentence serves a purpose, but structural improvement could reduce noise.

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

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

With 5 parameters, 0% schema coverage, and no output schema, the description should provide more context on parameter usage and output format. It mentions result fields but not how they are returned, and fails to explain the interplay between patient_id/patient_ids and calculo_id/calculo_ids.

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 mentions patient_ids and calculo_ids for batch, but does not explain account, calculo_id, or patient_id individually. The relationship between singular and plural parameters is unclear, 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 clearly identifies the tool as reading energy expenditure calculations, with actions list and get, and mentions specific result fields (TMB, GET in Kcal/dia and Kcal/kg). It distinguishes from siblings like webdiet_calculo_energetico_get and webdiet_calculo_energetico_delete via explicit action naming.

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 bulk support and implies list vs get, but does not provide explicit guidance on when to use this tool over alternatives or when not to use it. It lacks contextual cues for scenarios beyond the basic action distinction.

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, destructiveHint=false, so the agent knows it's a write operation. The description adds value by listing available formulas and factors, but does not disclose side effects, authentication needs, or any constraints beyond the schema.

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

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

The description is relatively concise, with a clear list of supported formulas and factors. However, it includes an internal note '[Flattened action: create]' which is irrelevant for the agent and adds clutter. The structure is adequate but not optimal.

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 (12 parameters, multiple formulas/factors) and absence of output schema, the description should explain return values or response behavior. It only mentions bulk support but does not detail the output. Annotations are minimal, so the description fails to complete the picture.

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%. The description mentions concepts like formulas and activity factors but does not map them to specific parameters (e.g., 'mlg', 'peso'). The agent cannot infer meaning or constraints from the description alone.

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

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

The description states 'Create / update energy expenditure calculations in WebDiet' with specific verbs and resource. It lists supported formulas and factors. However, it does not differentiate from the sibling 'webdiet_calculo_energetico_write_save', 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?

The description explains the actions (create, save) and mentions bulk support, but it does not provide when to use this tool versus alternatives (e.g., the sibling write_save tool). It also lacks guidance on 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 indicate readOnlyHint=false, consistent with create/update. The description adds behavioral context: actions, bulk support, and details on formula/factor selection, enhancing transparency 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 well-structured: starts with purpose and actions, then lists supported formulas and factors, and ends with bulk support. It is informative without being overly verbose, though it could tighten some repetitive lists.

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 lack of output schema and 12 parameters, the description covers core behavior and bulk features but omits parameter-level details and return values. It is sufficient for basic usage but not fully comprehensive.

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 partially compensates by explaining formula, activity factor, and injury factor values. However, it does not explain other parameters like mlg, nome, peso, altura, leaving some ambiguity. Adequate but 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's purpose: 'Create / update energy expenditure calculations in WebDiet.' It specifies actions (create, save) and lists supported formulas and factors, making its function unambiguous and distinct from siblings like write_create.

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 based on actions: create for new, save for existing. It does not explicitly contrast with the sibling write_create tool, but the action differentiation is clear enough for an AI agent to infer when to use this combined 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?

Annotations indicate it is not read-only, not destructive, and not idempotent, which aligns with a create operation. The description adds behavioral context: it returns a record ID and supports bulk execution. No contradictions 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 two sentences that efficiently convey the tool's action, output, type options, and bulk support. Every sentence adds value without redundancy.

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

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

Given 5 parameters, no output schema, and minimal annotations, the description should explain the meaning of all parameters. It only addresses tipo and patient_ids, leaving 'data' and 'account' unexplained, which is a significant gap 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 description coverage is 0%. The description explains 'tipo' (enumerated types) and mentions 'patient_ids' for bulk execution, but fails to describe the 'data' parameter (a string) and 'account' parameter. 'data' is especially critical as it likely contains the measurement values.

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', providing a specific verb and resource. It distinguishes from sibling tools like webdiet_antropometria_get (get) and webdiet_save_antropometria (save), as it creates and returns an ID needed for saving.

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 a workflow: create then save with the returned ID. It mentions bulk support via patient_ids. However, it does not explicitly state when to use this tool versus alternatives (e.g., for updating existing measurements), nor does it provide exclusions 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 already indicate readOnly, idempotent, and not destructive. The description adds behavioral details: returns all records in date range (default last 30 days), includes record fields, and date format. No contradictions, and it enriches the agent's understanding of the tool's behavior.

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 extraneous text like '[Flattened action: categories]' which is unclear. It front-loads the purpose but could be streamlined. Each sentence contributes value, but the structure could be tighter.

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 simple input schema and absence of output schema, the description provides adequate context: it explains the tool's purpose, actions, record fields, and date format. It covers the essentials for agent usage, though it misses the 'account' parameter and does not mention pagination or limits.

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

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

With schema description coverage at 0%, the description compensates somewhat by explaining 'inicio/fim' format and default behavior, and partially describing 'tipo' (entrada/saida with translations). However, 'account' is not explained, and 'inicio'/'fim' defaults are not explicitly documented in the schema. The description adds meaning but 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 it reads financial records and lists two actions (list, categories). It specifies the verb 'Read' and the resource 'financial records'. However, the tool name includes 'categories', while the description broadens the purpose to general reading, which could cause confusion. It does not explicitly differentiate from sibling tool 'webdiet_financeiro_list'.

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 the two actions (list and categories) and the default date range, but it provides no guidance on when to use this tool versus alternatives like webdiet_financeiro_list. It lacks explicit when-to-use and when-not-to-use scenarios.

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 reinforces the destructiveHint annotation with 'Permanently delete' and 'Irreversible', and adds the behavioral detail of bulk support via financeiro_ids. It does not mention related data impact or permissions, but the annotations already signal destructiveness.

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: first states purpose, second adds bulk support. No unnecessary words, front-loaded 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?

Covers basic purpose and bulk capability but lacks parameter explanations, response details, and clarification on required vs optional fields. For a delete tool with 3 parameters, more context is 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?

With 0% schema description coverage, the description must explain parameters. It covers financeiro_ids for bulk but does not explain the 'account' parameter or the relationship between financeiro_id (required) and financeiro_ids (optional), creating confusion.

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 'Permanently delete a financial record' and 'Irreversible', specifying the action (delete) and the resource (financial record). This distinguishes it from siblings 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 mentions bulk support via financeiro_ids, guiding users on batch execution. However, it does not explicitly state when to use this tool versus other deletion tools (e.g., webdiet_manipulados_delete) or any prerequisites, such as required permissions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds behavioral context: default last-30-day range, date format, and record fields. However, it does not discuss pagination, error handling, or rate limits.

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

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

The description is structured but a bit wordy, including actions, record fields, and date format. The 'Flattened action: list' note is redundant. It could be more concise 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?

Since no output schema exists, the description appropriately details returned fields. It explains the date format and defaults. While pagination and ordering are absent, the coverage is good for a read list tool. The missing 'account' param detail is a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'inicio' and 'fim' format and defaults, and 'tipo' enum values. 'account' parameter is not mentioned. Thus, it provides moderate meaning beyond the schema for 3 of 4 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 'Read financial records' and specifies it lists records in a date range. It distinguishes from sibling tools like webdiet_financeiro_categories, webdiet_financeiro_delete, and webdiet_financeiro_write, but the mention of 'categories' as an action within the same tool creates minor ambiguity. Overall, the core purpose 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 alternatives. It does not mention when not to use it or suggest better-suited sibling tools like webdiet_financeiro_categories for category retrieval.

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 are basic (readOnlyHint: false, destructiveHint: false). The description adds moderate behavioral context: data format (comma for decimals), installment support, and custom categories via nova_cat. However, it does not disclose side effects, authorization needs, or output behavior beyond creation.

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 five sentences covering all key aspects: purpose, tipos, categories, format, installments, delete alternative, and bulk support. No redundant information; 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?

Given 15 parameters and no output schema, the description covers essential usage nuances (decimal comma, defaults, bulk) but lacks return value information. It is sufficient for creating records, though error handling or confirmation details are absent.

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

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

Schema coverage is 0%, so the description must compensate. It explains tipo, valor format, forma, parcelas, dataCobranca, nova_cat, and patient_ids, but many parameters (cpf, data, nome, account, horario, categoria, observacao, patient_id) remain unexplained. The description adds meaningful context but not fully.

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 financial records in WebDiet' and specifies the two tipos (entrada/saida) with examples, distinguishing it from the sibling webdiet_financeiro_delete for destructive operations. It also mentions bulk support, providing a clear scope of the tool's 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 explains when to use the tool (creating financial records) and explicitly points to webdiet_financeiro_delete for deletion. It gives examples for tipos and categories but does not cover when not to use it for updates or other scenarios, though the context is clear enough.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior, which is consistent. The description adds valuable details: cached data per session, client-side filtering, and specific return fields. This 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 and a bullet list, no unnecessary words. Information is front-loaded: purpose first, then behavioral details.

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 three parameters, no output schema, and no sibling ambiguity, the description covers purpose, mechanism, return fields, and constraints. It is complete for an agent to use 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 has 0% description coverage, so the description must compensate. It explains the keyword parameter's minimum length and the default for limite. However, the account parameter is not described. Thus, 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 clearly states the tool searches the WebDiet food database for numeric food IDs needed for prescriptions, specifying the resource and return data. It distinguishes itself from sibling tools by its unique 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?

Provides context for when to use (to get food IDs for macro data in prescriptions) and mentions the minimum 3-character keyword requirement. Does not explicitly discuss when not to use or list alternatives, but the context is clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it loads data and supports bulk execution, but does not elaborate on rate limits, pagination, or other behavioral traits 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, front-loaded with purpose, no wasted words. Highly concise and well-structured.

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

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

Covers main purpose and key parameter (tipo) but misses explaining 'limite' and 'account', which are important for proper usage. No output schema, so description should compensate more for missing parameter 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?

With 0% schema coverage, the description adds semantic meaning by detailing the 'tipo' enum values (diario, reacoes, anexos, orientacoes) and bulk support via 'patient_ids', but does not explain 'limite' (likely pagination) or 'account'.

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 loads food diary entries, meal reactions, attachments, or orientations for a patient. It distinguishes from siblings by being a unified getter, but does not explicitly differentiate from specific list tools like webdiet_list_anexos or webdiet_orientacoes_list.

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 by stating 'Use tipo to select' and mentions bulk support, but provides no guidance on when to prefer this tool over specific list tools 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 indicate readOnly and idempotent. The description adds context about what the agenda includes (appointments, overdue tasks, birthdays, events), which is useful beyond the annotations. However, it does not mention authentication needs or return format.

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, clear sentence with no wasted words. It front-loads the action and lists item types, followed by the default behavior.

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 has two optional parameters and no output schema, the description tells what it loads but not the return structure or exact parameter semantics. It is adequate for a simple tool but could be more 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 coverage is 0%. Description explains 'date' implicitly (defaults to today) but does not specify format or behavior when empty. The 'account' parameter is completely unexplained. With no schema descriptions, the description should provide more detail about 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 the tool loads the nutritionist's calendar/agenda for a date, listing appointments, overdue tasks, birthdays, and events. It distinguishes from siblings like 'webdiet_get_consultations' which likely focuses on consultations only.

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 use for daily overview but does not explicitly mention when to use it vs alternatives like webdiet_get_consultations. No exclusions or prerequisites are 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 declare readOnlyHint=true and idempotentHint=true, which are consistent. The description adds behavioral context: the command returns a JSON with a 'code', and the workflow avoids loading large files into context. 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 concise yet informative, with a clear flow: states purpose, recommends usage, lists steps, and explains benefit. Every sentence adds value without redundancy.

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

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

Covers the main workflow and return value (curl command with code), but lacks details on error handling, input validation, authentication needs, or the exact format of the curl command. Given the absence of an output schema, more completeness would be helpful.

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% (no parameter descriptions in schema). The description only references 'file_path' implicitly, ignoring 'account' and 'file_name'. It does not clarify their purpose or format, failing to compensate for the lack of schema documentation.

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 returns a curl command for uploading files, specifies the resource (upload command) and action (returns). It distinguishes from siblings like webdiet_upload_anexo by outlining the two-step process.

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 and provides a step-by-step flow. However, it lacks explicit guidance on when not to use this tool (e.g., for small files one could possibly upload directly).

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 and idempotentHint, so the description adds value by detailing the return fields and their meanings (e.g., 'is_default' flag). No contradictions. The description gives useful 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 with two sentences and a note. No fluff, but could be better structured. The information is front-loaded. It earns its sentences.

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 return values (id, email, label, is_default, add_account_url) but omits details like pagination or ordering. The 'account' parameter is undocumented. Given no output schema, the description is reasonably complete but has a notable gap.

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

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

The input schema has 0% description coverage, and the description does not explain the optional 'account' parameter at all. It only mentions 'account' in the context of other tools, leaving the parameter's purpose unclear. The description fails to compensate for schema 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 verb 'List' and the resource 'all WebDiet accounts linked to this install', and it includes what fields are returned. This distinguishes it from sibling tools like webdiet_patient_list or webdiet_food_search.

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 this tool (to list accounts) and provides context about the 'is_default' flag for other tools. It also mentions using the returned 'add_account_url' for adding accounts. However, it doesn't explicitly state when not to use this tool 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 already declare readOnlyHint=true and destructiveHint=false. The description adds batch processing capability (accepts patient_ids) and clarifies the attachment types, which goes 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?

Four concise sentences with no fluff. Each sentence adds value: purpose, subtype usage, sibling pointer, and bulk support. Front-loaded 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?

With 4 parameters, no output schema, and moderate complexity, the description explains the main types and batch capability but ignores 'account' and doesn't clarify singular vs plural patient IDs. Could be more 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 coverage is 0%, so description must compensate. It explains the 'tipo' enum values and the 'patient_ids' array for batch. However, 'account' and the singular 'patient_id' are not described, leaving ambiguity.

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, specifying the two subtypes and even pointing to a sibling tool for guidelines/orientations. The verb 'list' is implicit but the purpose is unmistakable.

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 when to use each tipo (laminasAnexos for educational slides, cloudAnexos for cloud files) and directs users to an alternative for guidelines/orientations. Also mentions bulk support for patient_ids, providing clear decision criteria.

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, so the safety profile is clear. The description adds value by detailing what is returned (active layout + all templates), which is beyond the 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 concise sentences: purpose first, return value second. No wasted words, front-loaded, 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 no output schema, the description explains the return format reasonably. However, it omits any explanation of parameters or the read-only nature (though annotations cover safety). For a list tool with two parameters, more detail on their function would improve completeness.

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%, yet the description does not explain the two parameters (tipo and account) or their expected values. The default for 'tipo' is 'adicionar', but no context is given for what this means. The description fails to compensate for the lack of schema documentation.

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 'patient welcome message templates' and specifies it returns both the active layout and all available template layouts. This verb+resource combination is specific and distinguishes it from sibling tools like webdiet_preconsulta_list_templates.

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 (to load welcome message templates) but provides no explicit guidance on when not to use or how it compares to other list tools among the many webdiet_ siblings. No 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?

Annotations already declare destructiveHint=true, and the description reinforces with 'Permanently delete' and 'Irreversible', adding behavioral context beyond the boolean hint. It also discloses bulk execution capability, but does not detail authorization needs or side effects beyond deletion itself.

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—two short sentences that immediately convey the core action, irreversibility, and bulk support. No extraneous words; every sentence earns its place.

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

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

For a destructive tool with 5 parameters and no output schema, the description covers its destructive nature and bulk capability but lacks parameter-level guidance and does not describe return values or error behavior. It is adequate but leaves gaps that an agent must infer.

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 compensate, but it only mentions that 'patient_ids' and 'manipulado_ids' are accepted for batched execution. It does not explain the required single parameters ('patient_id', 'manipulado_id') or the optional 'account' parameter, leaving the agent to infer relationships and usage.

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 ('permanently delete'), the resource ('a manipulado for a patient'), and its distinct role among siblings (only delete operation for manipulado). This specificity helps an agent differentiate it from list, get, write, and other manipulado 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 provides clear context: it's irreversible ('Permanently delete... Irreversible.') and mentions bulk support via array parameters. However, it does not explicitly state when not to use it (e.g., if soft-delete is preferred) or compare to other tools, but given no sibling delete tool, the guidance is sufficient.

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, destructiveHint. The description adds bulk support but also introduces contradictory behavior by describing list and list_banco actions, which belong to separate sibling tools. This inconsistency undermines 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 overly long, detailing three actions when the tool likely only handles 'get'. The verbosity and duplication with sibling tools reduces 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 exists, so description must detail return values. For the 'get' action, it only says 'fetch full HTML content (componentes + doses)', which is vague. Bulk support is mentioned but not fully explained. Given the tool's complexity and multiple implied operations, the description is 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 coverage is 0%, so description must explain parameters. It covers many (keyword, categoria, incluir_bloqueados, patient_id, manipulado_id, patient_ids, manipulado_ids) but omits 'limite' and 'account'. Partial coverage, but adds meaningful context for the listed 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 lists three actions (list_banco, list, get) but the tool name and '[Flattened action: get]' indicate it should only perform 'get'. This confuses the tool's primary purpose, making it unclear whether it handles multiple operations or just one.

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 write and delete alternatives but fails to distinguish this tool from the sibling list tools (webdiet_manipulados_list, webdiet_manipulados_list_banco), which it implicitly duplicates. No explicit when-to-use 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 already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details like bulk support (patient_ids, manipulado_ids) and the structure of returned items for list_banco, exceeding what annotations offer.

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 and disorganized, mixing actions with usage notes and an unclear '[Flattened action: list]' statement. 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?

Despite multiple actions and 9 parameters, the description does not fully explain parameter interactions or return types for all actions (e.g., list and get lack output details). Output schema is absent, so description should cover this but is 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 coverage is 0%, so description must compensate. It explains keyword, categoria, incluir_bloqueados, patient_id, patient_ids, manipulado_id, manipulado_ids but omits limite and account, providing partial but incomplete parameter documentation.

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 reads 'Prescrição de manipulados' but lists three actions (list_banco, list, get) while the tool name and '[Flattened action: list]' suggest only list. Sibling tools exist for list_banco and get, causing 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?

The description tells when to use write/delete siblings, but fails to mention the existence of webdiet_manipulados_list_banco and webdiet_manipulados_get, leaving ambiguity about which tool to use for the listed 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context: that it reads from a bank of ~249 pre-built templates, explains the effect of incluir_bloqueados, and describes the returned fields (nome, categoria, texto_html, bloqueado). This goes 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 excessively long and includes details about sibling tools (list, get) and write/delete operations, which are not relevant for this tool's invocation. This bloats the text and reduces focus. While informative, it lacks conciseness and could be streamlined to describe only the list_banco functionality.

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 of 9 parameters and no output schema, the description is insufficient. It fails to document several parameters (e.g., limite, account) and does not clearly explain why patient-related parameters are present in a bank search tool. The bulk support mention is unclear. More detail is needed 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 description coverage, the description must compensate. It provides explanations for keyword, categoria, and incluir_bloqueados, but fails to cover limite, account, patient_id, patient_ids, manipulado_id, and manipulado_ids. The bulk support mention gives partial context for patient_ids and manipulado_ids, but it is vague and not connected to the search functionality. Overall, partial but incomplete 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 reads and searches the WebDiet formula bank ('list_banco → search the WebDiet formula bank'). It distinguishes from sibling tools by explicitly describing what 'list' and 'get' do (list prescribed manipulados, get specific prescribed manipulado), making the purpose distinct and 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 provides explicit guidance on when to use this tool (for searching the formula bank) and directs write operations to webdiet_manipulados_write and delete to webdiet_manipulados_delete. However, the mention of 'Bulk support: accepts patient_ids, manipulado_ids for batched execution' is ambiguous and might mislead about the typical use of this tool, slightly lowering the score.

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 the tool is not read-only and not destructive. The description adds some behavioral context: for duplicate, it creates a copy with '(cópia)'; for publish, it toggles visibility; for send, it skips blocked formulas. However, it does not disclose side effects, permissions, or rate limits, and the flattening note is contradictory.

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 structured with bullet points and a flattened action note, but it is verbose and includes redundant information (e.g., listing all actions twice). The last line 'For destructive delete use... [Flattened action: duplicate]' is confusing and could be clearer.

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 only mentions return values for the save action (id and pdf_url). For duplicate and other actions, return types are omitted. Additionally, error handling, prerequisites, and the effect of bulk operations are not described, leaving significant gaps for agent execution.

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 partially does: for save, it explains 'texto' is raw HTML and 'nome' is formula name; for bulk support, it says patient_ids and manipulado_ids are accepted. However, it does not map parameters to the duplicate action specifically, leaving ambiguity about required fields.

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 (save, send, publish, duplicate) despite the tool name 'write_duplicate' and the note '[Flattened action: duplicate]'. This creates confusion about the tool's primary purpose and fails to distinguish it from sibling tools like webdiet_manipulados_write_save, webdiet_manipulados_write_send, and webdiet_manipulados_write_publish.

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 webdiet_manipulados_delete for destructive deletes but does not provide explicit guidance on when to use this tool versus the separate write_save, write_send, or write_publish tools. The inclusion of all actions in the description misleads the agent about which tool to select for a given operation.

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?

Discloses effects beyond annotations: send immediately sets liberado=true, publish toggles and returns new state, save returns id and pdf_url, skip of blocked formulas. The internal note '[Flattened action: publish]' slightly muddies clarity.

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?

Long but structured with action breakdown. Mixed Portuguese/English and internal note increase cognitive load. Could be more concise without losing useful 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 return values for save and publish, mentions bulk support, cross-refers siblings. Lacks return details for duplicate and bulk execution, and account parameter is unexplained. Adequate but not fully complete for a complex multi-action 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?

Despite 0% schema coverage, description explains most parameters: nome, texto, patient_id, manipulado_id, bulk arrays. Missing account parameter. Partial compensation, not full.

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/sends/publishes/duplicates manipulados in WebDiet, listing each action with specifics. It distinguishes from sibling webdiet_manipulados_delete for destructive 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?

Explicitly when to use each action: save for create/update, send as shortcut for prescribir+publicar, publish to toggle visibility, duplicate for copying. Also directs to webdiet_manipulados_delete for deletion.

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 mutating behaviors (create, update, toggle, copy) beyond annotations (readOnlyHint=false, destructiveHint=false). It adds context such as send making formulas visible immediately and publish toggling status. No contradictions with annotations. Minor omission: does not detail auth or rate limits, but acceptable.

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 bullet points for actions and examples. However, the note '[Flattened action: save]' introduces confusion and the text is slightly verbose. Overall, clear and informative.

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 (multiple actions, batch support), the description is fairly complete. It mentions return values (id, pdf_url) for save, and bulk support. Lacks details on other actions' returns but sufficient for most use cases.

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 compensates by explaining nome, texto, and manipulado_id. However, parameters account, patient_ids, manipulado_ids are not described, leaving gaps. Partial compensation, but not comprehensive.

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, sends, publishes, or duplicates manipulados, using specific verbs and resources. It distinguishes from the destructive sibling tool webdiet_manipulados_delete, 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?

For each action (save, send, publish, duplicate), the description explains when to use it (e.g., 'Omit manipulado_id to create; pass it to update') and explicitly advises using the sibling tool for destructive deletion. This provides excellent guidance on 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 indicate readOnlyHint=false and destructiveHint=false, and the description confirms non-destructive behavior. It reveals specific behaviors: save returns id and pdf_url, send makes formulas immediately visible, publish toggles and returns new state, duplicate creates a copy with '(cópia)'. It also mentions skipping blocked formulas with error messages. This adds value beyond annotations, though more detail on error handling for save/publish could improve.

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 organized with a clear list of actions and their details. It front-loads the overall purpose and then uses bullet points for clarity. The 'Flattened action: send' note helps understanding. Some redundancy exists (e.g., explaining publish in both the list and comment), but overall it's well-structured and reasonably 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 (multiple actions, bulk support, no output schema), the description covers essential behaviors and return values for each action. It mentions bulk execution and excludes deletion. It lacks explicit details on error handling or limits, but these are not critical for basic usage. The description is sufficient for an agent to understand and invoke 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 coverage is 0%, so description carries full burden. It explains key parameters: 'texto' as raw HTML, 'nome' as formula name, 'manipulado_id' for update vs create, and mentions 'patient_ids' and 'manipulado_ids' for bulk. However, parameters like 'account', 'nomes', and default values are not explained. The description adds significant meaning to the most critical params, but somewhat incomplete 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?

The description clearly states the tool handles multiple actions (save, send, publish, duplicate) for manipulados, and lists each action's purpose. It distinguishes from the delete sibling tool. However, the name 'write_send' emphasizes 'send' while covering other actions, and sibling tools like webdiet_manipulados_write_publish and webdiet_manipulados_write_duplicate overlap, causing slight 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?

The description explains when to use each action: save for create/update, send for copying from banco, publish for toggling visibility, duplicate for copying. It explicitly directs destructive deletes to another tool. However, it does not compare this tool's combined actions against the individual sibling action tools (e.g., when to use this send vs. separate publish/duplicate 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 declare readOnlyHint, idempotentHint, destructiveHint. The description adds that it supports bulk execution via patient_ids and distinguishes between two actions (list vs list_banco). However, the action distinction may be misleading given the existence of a dedicated list_banco tool, so 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 about 6 sentences, which is moderately concise. However, it includes redundant references to 'list_banco' that are not clearly demarcated as belonging to this tool, and the structure could be improved by separating action definitions more clearly.

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 description does not describe the return format or fields. The bulk support mention is helpful, but details on how to select between actions (list vs list_banco) are missing. The tool's interaction with sibling tools is partially hinted 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?

Input schema has 0% description coverage; the description only explains the 'patient_ids' parameter for bulk support. 'account', 'limite', and 'patient_id' are undocumented. The description does not compensate for the missing schema explanations, leaving most parameters opaque.

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 reads 'Listas e Orientações' and mentions two actions ('list' and 'list_banco'), but this conflates with a sibling tool 'webdiet_orientacoes_list_banco'. The purpose is somewhat clear but muddled by including an action that likely belongs to another tool, 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 suggests using 'list_banco' to view templates before sending via a write tool, but does not explicitly guide when to use this tool versus the separate 'webdiet_orientacoes_list_banco' sibling. No explicit when-not-to-use or alternative selection criteria 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 readOnlyHint and idempotentHint, so the description adds context about the bank's purpose and workflow (saved templates). It does not introduce new behavioral traits 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 with about four sentences covering purpose, sibling distinction, workflow, and batch support. It is well-structured with front-loaded purpose, though the 'Actions:' line could be slightly streamlined.

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 4 parameters, no output schema, and only partial parameter explanation, the description fails to fully cover what the tool needs and returns. It mentions 'see available names' but not the response structure, leaving incompleteness for an agent.

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

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

Schema description coverage is 0%, but the description adds meaning for patient_ids (bulk support) and hints at sending names. However, it does not explain limite, account, or patient_id individually, 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 clearly states the tool reads 'Listas e Orientações' specifically the orientation bank (favorites). It distinguishes between list_banco (bank) and the sibling list (patient-specific), using 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?

The description explicitly instructs to use list_banco to see available names before using the write tool to send, and mentions bulk support with patient_ids. It provides clear context but does not explicitly state 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?

The description adds useful behavioral details beyond annotations, such as HTML entity encoding for emojis and title prepending. Annotations already indicate a non-read-only, non-destructive nature, and the description aligns with that 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 relatively concise but includes an unclear 'Flattened action: save' line and redundant information. It could be more structured and remove ambiguity without adding length.

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, so the description should explain return values or results, which it does not. It also fails to clarify the scope of the 'send' action within this tool, leaving gaps for an agent in understanding the full tool 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?

With 0% schema parameter descriptions, the description partially compensates by explaining 'texto' and 'titulo' behavior, but it does not cover all 8 parameters (e.g., 'nomes', 'account', 'orientacao_id'). The explanation adds value but is 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 states the tool can create/update/send 'Listas e Orientações', but the name suggests only 'save', and there is a sibling tool for 'send'. The mention of 'send' action within this tool creates ambiguity about its exact purpose relative to the sibling.

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

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

No explicit guidance is given on when to use this tool versus the sibling 'webdiet_orientacoes_write_send'. The description includes 'send' as an action here, which conflicts with the sibling's existence, potentially misleading an agent about tool selection.

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

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

The description adds behavioral context beyond annotations: it explains emoji encoding in 'texto', the prepending of <h1> for 'titulo', and bulk support. Annotations already indicate read/write intent (readOnlyHint=false) but the description provides meaningful side-effect details. 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 uses a mix of sentences and bullet points, but the structure is somewhat disjointed. The 'Flattened action: send' line interrupts the flow. It is not excessively long but could be more concise and logically 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 tool's complexity (2 actions, 8 parameters, no output schema), the description covers key behaviors but fails to fully explain how to switch between save and send actions or the role of all parameters. Annotations are minimal, and while the description adds some completeness, it is not comprehensive enough for reliable invocation.

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 explanation of 'texto' encoding, 'titulo' rendering, and bulk support for patient_ids/orientacao_ids adds value. However, key parameters like 'nomes', 'account', and 'orientacao_id' (singular) remain unexplained. Only about half of the 8 parameters are addressed, 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 the tool can 'Create / update / send Listas e Orientações' which provides a clear verb+resource. However, the mention of two actions (save and send) and the flattened action 'send' creates some ambiguity about the primary function. It does not explicitly distinguish from sibling tool webdiet_orientacoes_write_save, but the context implies this tool specializes in sending.

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 sending orientations from the bank to a patient by exact name, and mentions bulk support. However, it does not provide explicit guidance on when to use this tool versus webdiet_orientacoes_write_save or other siblings. No when-not-to-use or alternative suggestions are given.

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

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

Discloses internal mechanism (uses removerPaciente and resolves id/link from fresh list) and reiterates irreversibility. Annotations already signal destructiveness, so description adds useful behavioral context 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 sentences, no redundancy. First sentence states core purpose and mechanism, second adds bulk support. Information is front-loaded and every word 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?

For a delete tool, covers permanence, irreversibility, mechanism, and bulk mode. Lacks mention of cascading effects on related data (e.g., consultations), but overall adequate for typical 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?

Adds meaning for patient_id (primary identifier) and patient_ids (bulk support), but does not explain the 'account' parameter. Schema has 0% description coverage, so the description partially compensates but leaves one parameter unspecified.

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 permanently deletes a WebDiet patient, using specific verb 'delete' and resource 'patient', and distinguishes from sibling tools like create or list by emphasizing irreversibility and 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?

Explicitly warns that the action is irreversible, implying caution, and mentions bulk support for batched execution. However, it lacks explicit guidance on when to use this tool versus alternatives like update or get.

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?

Aligned with annotations (readOnlyHint, idempotentHint, destructiveHint). Discloses key behaviors like pagination, fallback mechanism, and return of permanent link/URLs. 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 front-loads the main purpose but includes verbose details and a confusing 'Flattened action: get' line. Could be more streamlined without losing essential 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?

Covers multiple actions, pagination, bulk support, and return values. Lacks error conditions but is adequate given no output schema. Overall complete for a read tool with moderate complexity.

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

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

With 0% schema coverage, the description explains the primary parameters: keyword for list, patient_id for get, and patient_ids for bulk. It also mentions the numeric ID fallback. However, page and page_size are not explicitly explained, though typical.

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 distinguishes between 'list' (search by keyword) and 'get' (full profile) actions. This differentiates it from siblings like webdiet_patient_list and webdiet_patient_write_create.

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 list vs get within the tool, and mentions pagination and fallback for IDs. However, it does not clarify when to use this combined tool vs the separate webdiet_patient_list sibling, creating potential 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 indicate readOnly, idempotent, non-destructive. Description adds details on pagination, fallback mechanism, and return of permanent 'link' identifiers and URLs. 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?

Structured with purpose, actions, important note, and bulk support. Some redundancy (flattened action) but overall well-organized. Could be slightly 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?

Covers main actions and pagination, but lacks full output schema description. For 6 params and no output schema, more details on return values and parameter interactions would improve completeness.

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, description partially explains parameters (keyword, page, patient_id, patient_ids) but lacks explicit descriptions for each. Adds moderate value 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 'Read patients in WebDiet' and distinguishes two actions (list and get) with specific return fields. It is distinct from siblings like webdiet_patient_get (single patient) and other read 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?

Describes when to use list vs get, and provides important guidance on pagination and how to pass identifiers for writes. Does not explicitly state when not to use, but context is clear.

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

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

Goes beyond annotations by warning that without nascimento, 'metodoPlanning.php crashes with a Fatal Error.' This is critical behavioral context not captured in annotations. Also mentions flattened action and bulk execution behavior.

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 and front-loaded with the main purpose. The warning about the crash is important. Minor redundancy: the '[Flattened action: create]' line could be integrated. Still efficient overall.

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 19 parameters, no output schema, and critical crash risk, the description covers the essential information: required fields, format, action distinction, bulk support, and safety warning. It is sufficiently complete for an agent to use correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the critical parameters (nome, nascimento) with format and reason. However, it does not elaborate on the other 17 parameters, though many are named intuitively.

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 explicitly states 'Create or update patients in WebDiet.' and distinguishes between create and update actions with required fields for create. It also mentions the sibling delete tool, clarifying 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?

Provides clear when-to-use guidance: for create (nome + nascimento required), for update (partial fields), and explicitly directs destructive removal to webdiet_patient_delete. Also notes 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?

The description goes beyond annotations by warning about the crash if nascimento is missing during create, and notes that update allows partial fields. It also clarifies this tool is not for destruction. However, it does not disclose idempotency or other error conditions. The warning adds significant 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?

The description is moderately concise but contains extraneous elements like '[Flattened action: update]' and the 'IMPORTANT' warning, which while valuable, could be better integrated. The structure is somewhat fragmented, mixing usage notes, warnings, and hints.

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 (19 parameters, no output schema, no annotation details), the description covers only core create/update semantics and a critical failure mode. It lacks details on return values, error handling, and many parameter meanings, making it incomplete for effective tool 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?

With 19 parameters and 0% schema description coverage, the description only clarifies 'nome' and 'nascimento' for create, and mentions 'patient_ids' for bulk. The other 16 parameters (e.g., cep, cpf, email) have no explanation, leaving the agent uninformed about their purpose or constraints.

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

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

The description states it creates or updates patients, which is clear. However, there is a sibling tool 'webdiet_patient_write_create' that likely focuses on creation, and the description does not distinguish when to use this tool versus that one. The '[Flattened action: update]' note 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?

It provides guidance for create vs update (required fields for create) and mentions when to use delete. But it fails to differentiate from the sibling 'webdiet_patient_write_create' or give criteria for bulk vs single use. The guidance is present but incomplete.

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. The description adds value by stating 'Irreversible' and 'Templates are NOT affected', providing context beyond annotations. Bulk support is also noted.

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

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

The description is two concise sentences with no redundancy. Key information is front-loaded.

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 critical aspects: irreversibility, non-effect on templates, and bulk support. The 'account' parameter is not addressed, but given the tool's simplicity (delete with optional IDs), it is nearly 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%. The description explains the 'response_ids' parameter for bulk execution, but the 'account' parameter is not explained, leaving ambiguity.

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 pre-consultation response') and the resource, and the tool name distinguishes it from siblings like get_response, list_responses, list_templates, and write_link_to_patient.

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 notes that templates are not affected, which helps differentiate from template-related tools. However, it lacks explicit when-to-use or when-not-to-use guidance relative to other delete tools like webdiet_anamnese_delete.

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, idempotentHint=true, destructiveHint=false. The description adds useful behavioral details: bulk support via response_ids, output fields like 'link' and 'preview_url', and retrieval of PDF URLs. No contradictions 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 structured with bullet points but is somewhat lengthy. It repeats the word 'Actions' and includes a redundant '[Flattened action: get_response]' line. Could be more concise while retaining 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?

The description details outputs for each sub-action but does not specify invocation logic (which parameters trigger which action) or default behavior when no parameters are provided. Missing error handling and rate limit info.

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 explain parameters. It only partially explains 'nome' and 'tipo' as filters for list_responses, but leaves 'limit', 'offset', 'account', 'response_ids' undocumented. The mapping of parameters to sub-actions is 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 states 'Read pre-consultation questionnaires' and lists three sub-actions (list_templates, list_responses, get_response), but the tool name 'get_response' implies a single retrieval. It distinguishes from sibling link tool but not from separate list tools, 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?

The description only mentions using webdiet_preconsulta_write for linking, but does not explain when to use this combined tool vs. the existing sibling tools (webdiet_preconsulta_list_templates, webdiet_preconsulta_list_responses). No guidance on selecting sub-actions or default behavior.

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=true and destructiveHint=false, which description aligns with by stating 'Read pre-consultation questionnaires'. Additionally, description discloses bulk support via response_ids, which adds value 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?

Description is somewhat verbose, listing three actions but only list_responses applies. It includes Portuguese phrases and redundant detail. Could be more concise while preserving 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?

Explains the output structure for responses (id, id_code, etc.) but omits parameter descriptions for 5 out of 7 parameters. With no output schema, more detail on pagination and account is needed for complete 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?

Only two parameters (nome, tipo) are semantically explained as filters for responder name and template name. With 0% schema coverage and 7 parameters, description fails to explain limit, offset, account, response_id, and response_ids purpose.

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 and lists patient submissions to pre-consultation questionnaires. It explicitly distinguishes from sibling tools like webdiet_preconsulta_list_templates and webdiet_preconsulta_get_response by describing each action and noting this tool is for list_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?

Provides guidance on when to use this tool (list responses) vs. alternatives (list_templates for links, get_response for single response, link_to_patient for linking). Mentions filtering by tipo and nome. Lacks explicit 'do not use' scenarios but is still helpful.

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