DietBox

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

Annotations indicate idempotentHint=true, which aligns with the description's mention of token-based login that can be repeated. The description adds context about side effects (setting a session token) and the distinction between permanent and session, which annotations alone don't cover. 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?

The description is informative but somewhat lengthy. It could be tightened without losing clarity. However, it's well-structured with front-loaded purpose.

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

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

Covers the main authentication scenarios. No output schema, but return value is implied. Adequately complete for a tool with simple I/O.

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 for the 'token' parameter. The description compensates by explaining it should be a JWT token and how to use it (with or without). Adds meaning beyond just the type.

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

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

The description clearly states it's for authentication, explaining the login process with browser and token. It distinguishes between permanent and session-only usage, making it distinct from other 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?

Provides explicit when-to-use: for authentication, with alternatives (config for permanent, paste for session). Also explains calling with no args to get link, and with token to complete login. No other tool does this.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by describing the conditional return behavior (authenticated:true vs. connect_url), which is not covered by annotations.

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

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

The description is extremely concise: two sentences that cover the main purpose and conditional behavior without any unnecessary words. It is front-loaded with the primary function.

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 provides some context on return values for two states, but it is incomplete regarding other possible states or error conditions. For a simple tool, it is adequate 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?

The tool has no parameters, so the input schema is empty and fully documented. According to the baseline for zero parameters, a score of 4 is appropriate as the description does not need to add parameter semantics.

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

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

The description clearly states that the tool returns connection status and URLs, with specific details about return values in different states. It effectively communicates the tool's purpose, though it does not explicitly differentiate from sibling tools like '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 when to use the tool (to check connection status) by detailing return values for connected vs. missing credentials states, but it does not provide explicit guidance on 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 indicate read-only, idempotent, non-destructive behavior. The description supplements this by noting bulk support and flattening to the list action, adding value without contradicting 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 short and front-loaded with the main purpose, using three concise sentences. While it could be more structured (e.g., bullet points), it avoids unnecessary words.

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

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

The tool has 6 parameters and no output schema, yet the description omits return value details, pagination, date format, and limits. This leaves the agent underinformed for correct invocation and handling of results.

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

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

With 0% schema description coverage and 6 parameters, the description only vaguely hints at 'date range' and 'patient' filtering, and mentions 'patient_ids' for bulk. It fails to explain 'account', 'timezone', or the format of 'start' and 'end', leaving most parameters semantically unclear.

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

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

The description clearly states 'Read schedule/agenda in Dietbox' and specifies the 'list' action with filtering by date range/patient, distinguishing it from the sibling 'dietbox_agenda_summary' which handles today's overview.

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 this tool (for listing agenda items) versus the summary sibling, and mentions bulk support for batched execution. However, it does not explicitly state when not to use it or provide 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 readOnlyHint=true and destructiveHint=false. Description adds that it supports batch execution via patient_ids. However, it does not disclose authorization needs, rate limits, or potential side effects. 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 short but contains redundancy. 'Actions: list... summary...' followed by '[Flattened action: summary]' causes confusion. It front-loads the purpose but 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?

With no output schema and 6 parameters, the description lacks details on return format, pagination, or what the summary includes. 'today's overview' is vague. The tool feels underspecified for an AI agent to invoke confidently.

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 that start/end filter by date range, patient_id/patient_ids filter by patient, and timezone sets the timezone. However, the 'account' parameter is unexplained, and date formats are unspecified. Some value added 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 'Read schedule/agenda in Dietbox' with actions list and summary, and specifies 'Flattened action: summary'. This differentiates from sibling tools like dietbox_agenda_list (list action) and dietbox_agenda_write (write). The verb-resource pair is specific.

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 actions and bulk support but does not explicitly state when to use this tool versus alternatives like dietbox_agenda_list. No guidance on prerequisites or context. It implies filtering but lacks 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=false and destructiveHint=false, consistent with creation. The description adds default timezone and valid tipo values but lacks detail on side effects, auth requirements, or response 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?

Four sentences, front-loaded with purpose, no unnecessary fluff. Minor improvement possible by grouping parameter 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?

With 10 parameters (2 required) and no output schema, the description covers key aspects like bulk support but leaves many optional parameters undocumented, which could mislead 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%, so the description must compensate. It explains start/end as ISO datetime strings, timezone default, and valid tipo values, but omits explanations for titulo, account, todo_dia, descricao, patient_id.

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 a new event/appointment in the Dietbox agenda.' It uses a clear verb-resource pair and distinguishes from sibling tools like dietbox_agenda_list and dietbox_agenda_summary.

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 creating agenda events but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.

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 destructiveHint=true. The description adds 'Ação irreversível' (irreversible action) and bulk support, providing some additional context but not extensive behavioral details beyond what annotations convey.

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

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

The description is extremely concise with two short sentences, no fluff, and front-loaded with the core purpose. 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?

Despite simplicity, the description lacks guidance on how to use bulk parameters (e.g., whether patient_ids alone deletes all linked anamneses), the role of the account field, and return behavior. With no output schema, more detail is needed for effective 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%, meaning no parameter descriptions in the schema. The description only names 'anamnesis_ids' and 'patient_ids' for bulk execution but does not explain the purpose of each parameter (e.g., account, patient_id, anamnesis_id) or their relationships. Missing critical semantics.

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

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

The description clearly states 'Remove uma anamnese do Dietbox' (remove an anamnesis from Dietbox), specifying the verb and resource. It distinguishes from sibling tools like get, list, write by focusing on deletion. Bulk support is also mentioned.

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 bulk support but does not provide any guidance on when to use this tool versus alternatives, such as when to use write_update instead of delete. No explicit when-not or comparison with other 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 the tool as read-only, idempotent, and non-destructive. The description adds context about actions (list, get, get_latest) and bulk execution, which is useful but does not fully disclose behavior like pagination limits, error handling, or action resolution logic. 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 relatively concise at five sentences, but the inclusion of both 'Actions: ...' and 'Flattened action: get' creates redundancy and confusion. The core purpose is front-loaded, which is good, but the structure could be 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 the high number of parameters (8), no output schema, and combined actions, the description is insufficient. It does not explain how to invoke each action, what parameters are required for each, or what the output format looks like. Annotations cover safety but not 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 add meaning. It suggests parameters relate to actions (e.g., patient_id for list, anamnesis_id for get, patient_ids for bulk), but it does not explicitly map parameters or explain 'search', 'account', or 'skip'/'take' beyond implicit pagination. Incomplete semantics for 8 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 the tool reads anamnesis records, which is a clear verb+resource. However, it lists three actions (list, get, get_latest) and mentions a flattened action 'get', creating ambiguity about the tool's exact behavior. It partially distinguishes from siblings but mixes multiple purposes.

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 minimal guidance on when to use this tool versus the specific sibling tools like dietbox_anamnese_list and dietbox_anamnese_get_latest. It mentions bulk support but does not explain how to choose between actions or when to prefer this general read tool over specialized ones.

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 and idempotentHint, which the description aligns with by stating 'Read'. The description adds context about bulk support via patient_ids and anamnesis_ids, 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 short with three sentences, but the inclusion of the 'Actions' list and flattened action note adds slight redundancy. Overall, it is efficient and 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?

No output schema exists, and the description does not specify return format or pagination behavior for get_latest. It mentions list is paginated but not get_latest. Bulk support semantics are unclear (e.g., returns multiple latest records?). This leaves gaps for a tool with 8 parameters.

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

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

With 0% schema coverage, the description partially compensates by explaining that patient_ids and anamnesis_ids are for batched execution. However, it does not clarify other parameters like skip, take, search, account, patient_id, or anamnesis_id, leaving their roles ambiguous.

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 anamnesis records and specifies the flattened action as get_latest, distinguishing it from dietbox_anamnese_list (list all) and dietbox_anamnese_get (by ID). The name 'get_latest' further clarifies the purpose.

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

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

The description mentions actions but does not explicitly state when to use this tool versus alternatives like list or get. It implies usage for the latest record per patient but lacks 'when not to use' or explicit 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 readOnly/idempotent/destructive hints. The description adds pagination and bulk support details, but the conflicting action description undermines trust. No permissions or side effects are disclosed, but the core safety profile is covered by 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 relatively short but includes a redundant 'Flattened action: list' line that adds noise. The structure could be clearer by focusing on the primary list functionality and dropping the misleading action enumeration.

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

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

For a tool with 8 parameters and no output schema, the description fails to explain how to invoke different actions, the expected response format, or clarify the bulk vs single-record distinction. The multi-action promise is unfulfilled by the schema, making the description incomplete for effective 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 0% schema description coverage, the description must explain parameters. It only hints at 'skip/take' (pagination) and 'patient_ids/anamnesis_ids' (bulk). The meaning of 'search', 'account', 'patient_id', and 'anamnesis_id' remains unexplained, leaving significant 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 states it reads anamnesis records, but it ambiguously lists multiple actions (list, get, get_latest) while claiming to be flattened to 'list'. This creates confusion about the tool's core function, especially given dedicated sibling tools for get and get_latest.

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

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

No guidance is provided on when to use this tool versus the separate get/get_latest siblings. The mention of multiple actions without clear usage context, combined with the flattened annotation, could mislead an agent into thinking it performs all actions when it likely only lists.

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 minimal (all false). Description adds return value {id} and bulk support, but does not disclose side effects, permissions, or failure modes beyond what annotations imply.

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 poorly structured, mixing create and update actions and adding a confusing 'Flattened action' note and bulk support mention. It could be more 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 10 parameters and no output schema, the description covers basic usage but lacks details on bulk execution behavior, error handling, prerequisites, and interaction with other similar tools.

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

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

With 0% schema description coverage, the description compensates by naming key parameters (patient_id, anamnesis_id, etc.) and explaining required ones. However, it does not describe all 10 parameters or their allowed values in detail.

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 an anamnesis, but the presence of a sibling tool 'dietbox_anamnese_write_update' and the note 'Flattened action: create' creates ambiguity. The purpose is not fully 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?

No explicit guidance on when to use this tool vs the sibling write_update tool. Only lists required fields per action but no context for choosing between create and update or alternative 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?

With no annotations providing behavioral details, the description adds value by disclosing that updates overwrite existing fields and that bulk execution is supported. It does not contradict annotations, and the overwrite behavior is clearly stated. Missing details on error conditions or rate limits, but sufficient for a write tool.

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

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

The description is moderately concise but includes a mix of languages (Portuguese/English) and a confusing 'Flattened action: update' note. The bullet-point structure helps, but some redundancy and unclear phrasing reduce efficiency.

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 (10 parameters, nested objects, bulk support, dual actions), the description provides a solid overview and return format. However, it omits details on some parameters (e.g., 'data', 'account'), error handling, and lacks an output schema reference, leaving some 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?

The description explains the roles of key parameters (patient_id, anamnesis_id, descricao, texto_livre, tipo, overrides) and distinguishes required vs optional per action. Despite 0% schema description coverage, it adds significant meaning beyond the raw schema. However, parameters like 'data' and 'account' remain unexplained.

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

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

The description clearly states the tool creates or updates an anamnesis (health history questionnaire), specifying both verbs and the resource. It distinguishes from the sibling 'dietbox_anamnese_write_create' by combining both actions, 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 explains when to use create vs update based on provided IDs (patient_id for create, anamnesis_id for update) and mentions bulk support. However, it does not explicitly contrast with the sibling tool for create-only scenarios or provide exclusions, leaving some ambiguity.

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

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

The description explicitly states 'This is irreversible,' adding context beyond the destructiveHint annotation. It also mentions bulk support. No information contradicts annotations.

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

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

The description is extremely concise: two sentences without wasted words. The first states purpose and irreversibility; the second introduces bulk capability.

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 basic purpose and bulk support but lacks details on return behavior, partial success in batch, or required permissions. For a delete tool with batch capability, more context would be beneficial.

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 should explain all parameters. It clarifies anthropometry_id (required) and anthropometry_ids for batch, but fails to mention the 'account' parameter, leaving it undocumented.

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

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

The description clearly states the verb 'Delete' and the resource 'anthropometric evaluation from Dietbox', and mentions bulk support. This distinguishes it from sibling tools like dietbox_antropometria_get, list, write by specifying the action and resource.

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

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

The description implies usage when deleting anthropometric evaluations, and explicitly mentions bulk support for batched deletion. However, it does not provide exclusions or alternatives, leaving the agent to infer when not to use this tool compared to other delete tools.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about pagination, filtering, and bulk operations, but does not clarify the 'Flattened action: get' concept or detail response behavior across different actions.

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 key information front-loaded. It covers purpose, actions, parameters, and special features in a few sentences, though the 'Flattened action: get' line 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?

Given the complexity (8 parameters, multiple actions, no output schema), the description provides a workable overview but lacks details on how the tool selects among list/get/get_latest actions and what distinguishes this from sibling tools. The bulk support note is helpful but incomplete for full 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 partially compensates by linking skip/take to pagination, tipo to filtering, and anthropometry_id/patient_ids to get/bulk. However, it omits explanation of account and the difference between patient_id and patient_ids, leaving gaps for the agent.

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

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

The description clearly states the tool reads anthropometric evaluations and lists specific actions (list, get, get_latest) with brief details. However, it does not fully distinguish from separate sibling tools like dietbox_antropometria_list and dietbox_antropometria_get_latest, which may cause confusion about when to use this combined version.

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 batch execution using patient_ids and anthropometry_ids, indicating when to prefer this tool over singular requests. However, it does not explicitly state when not to use it or compare with dedicated list/get_latest tools, leaving the agent to infer 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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by mentioning bulk support (patient_ids, anthropometry_ids) for batched execution, which is beyond what annotations provide.

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

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

The description is relatively short but includes redundancy ('Actions: list... get... get_latest... [Flattened action: get_latest]'). Information is front-loaded, but could be 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?

Despite having 8 parameters and no output schema, the description fails to explain key parameters like skip/take (pagination), tipo, account, or the relationship between patient_id and patient_ids. Only batch execution is covered, leaving the tool's full capability under-documented.

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

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

With 0% schema description coverage, the description adds meaning only for patient_ids and anthropometry_ids (batch parameters). Other parameters like skip, take, tipo, account, patient_id, anthropometry_id are unexplained, 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 that the tool reads anthropometric evaluations and specifically indicates that 'get_latest' returns current measurements. It distinguishes the action from 'list' (paginated, filter by tipo) and 'get' (by ID), providing a specific verb and resource.

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

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

The description implies when to use each action (list, get, get_latest) but does not explicitly state exclusions or alternatives. It mentions bulk support for batched execution, offering some guidance on usage context.

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

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

Annotations already confirm read-only, idempotent, non-destructive behavior. The description adds value by specifying pagination, tipo filtering, and bulk execution via patient_ids and anthropometry_ids, which are not in 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 fairly concise and front-loads the main purpose. The listing of separate actions adds some redundancy, but overall it is structured and brief.

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

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

Without an output schema, the agent needs description of return values. The mention of 'weight, height, BMI, body composition' gives some hint, but not comprehensive. The action list may mislead. Overall, incomplete for a tool with 8 parameters and multiple action hints.

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 skip/take, tipo, and the bulk array parameters, but leaves 'account', 'patient_id', and 'anthropometry_id' unexplained. Partial 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 'Read anthropometric evaluations' and lists actions. It distinguishes from sibling tools like dietbox_antropometria_get and dietbox_antropometria_get_latest, but the inclusion of get and get_latest as actions within a list tool creates minor 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 implies usage for reading evaluations but does not explicitly state when to use this tool versus the separate get or get_latest siblings. It mentions bulk support but lacks guidance on 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 provide only basic hints (readOnlyHint=false, etc.). The description adds behavioral details: bulk support, default values, unit ranges, and that measurement fields default to null. 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 highly concise with three focused sentences. It front-loads the core purpose and then adds necessary detail. No extraneous 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?

Given no output schema and 8 parameters with 0% schema coverage, the description covers required fields, types, and bulk support. However, it lacks details on what happens on success/failure, and the relationship between patient_id and patient_ids is ambiguous.

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 adds meaning for weight/height ranges, type enum, and notes that measurement fields default to null. However, it ignores date, account, description, and does not fully clarify patient_ids vs patient_id.

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 starts with 'Create a new anthropometric evaluation', specifying the exact verb and resource. It clearly distinguishes from sibling tools like get, list, delete, and get_latest.

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 lists required fields (patient_id, weight, height) and type options, and mentions bulk support. It provides context but does not explicitly state when not to use or compare to alternatives.

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

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

The annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by clarifying bulk execution capability ('Bulk support: accepts patient_ids for batched execution') and the flattened action mode. This goes beyond what annotations provide, though rate limits or auth requirements are 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 relatively short but contains redundant elements like '[Flattened action: list]' and a bullet-like list. The structure is adequate, but the dual action (list and messages) could be more clearly separated. Some sentences add minimal 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 the 5 parameters and no output schema, the description covers read operation, filtering options, and bulk support. However, it lacks details on pagination behavior (take parameter), parameter interactions (e.g., patient_id vs patient_ids), and output format. For a read tool with no output schema, this is sufficient but not 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?

Schema coverage is 0%, so the description must explain parameters. It implies patient_id and unread via 'filter by patient/unread', and explicitly mentions patient_ids for bulk. However, it does not describe 'take' (pagination) or 'account' (likely platform account). Only 3 of 5 parameters are partially explained, 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 'Read chat conversations in Dietbox' and lists actions (list conversations, get messages), clearly identifying the tool as a read operation on chat data. It distinguishes from siblings like dietbox_chat_messages (for specific patient history) and dietbox_chat_write (write). However, the dual action description (list + messages) slightly blurs the exact 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 does not explicitly state when to use this tool versus alternatives. It mentions bulk support and filtering by patient/unread, but lacks guidance on when to prefer this over dietbox_chat_messages or dietbox_chat_write. No 'when not to use' or alternative tool suggestions 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 declare readOnlyHint=true and idempotentHint=true, so safety is clear. Description adds bulk support and action flattening, but the action selection mechanism (via parameters) is not explained, reducing 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?

Concise with two main sentences and a note. Front-loaded with purpose. No wasted words.

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

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

For a tool with 5 parameters and no output schema, the description is incomplete. It does not clarify how to trigger 'list' vs 'messages' actions, nor explain the 'flattened action' concept, leaving 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 has 0% description coverage. Description mentions patient_id, patient_ids, and unread for filtering, but omits take and account. Insufficient detail for 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 clearly states the tool reads chat conversations and lists actions (list conversations, get message history). However, it does not explicitly distinguish from sibling dietbox_chat_list, leaving some 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 guidance on when to use this tool versus siblings like dietbox_chat_list or dietbox_chat_write. The description lacks context or exclusions for alternative 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?

The description only indicates a write operation. It does not disclose any behavioral traits beyond what annotations imply (e.g., whether authentication is required, if the message is persisted, or if there are any side effects like notifications). Annotations are neutral, so description carries the burden but fails to provide meaningful 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 a single brief sentence, which is concise and front-loaded. However, it could be slightly expanded to include usage notes without losing conciseness, but as is, it is efficient.

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

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

The tool lacks an output schema, so the description should ideally mention return types or error conditions. It does not. Given the sibling tools and the complexity of sending a message, the description is incomplete for an agent to use effectively.

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 parameters have no descriptions (0% coverage). The description only hints at the 'data' parameter ('Pass message data as a JSON string'), but does not explain its format or the 'account' parameter. This leaves the agent with insufficient information to correctly construct inputs.

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 ('Send a chat message') and the target ('a patient in Dietbox'). It distinguishes this tool from sibling tools like dietbox_chat_list (list messages) and dietbox_chat_messages (get messages) by specifying the write operation.

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

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

No guidance on when to use this tool versus alternatives (e.g., when to use dietbox_chat_write vs dietbox_agenda_write). No prerequisites or when-not-to-use conditions are mentioned, leaving the agent to infer context from the tool name alone.

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 (readOnlyHint=true) and idempotent (idempotentHint=true). The description adds behavioral context by specifying that the tool returns progress data (completion percentages, streaks, recent activity) and supports batched execution via patient_ids, which 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 concise with two sentences. The first sentence front-loads the core purpose and deliverables, and the second adds the key behavioral nuance (bulk support). Every word earns its place.

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

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

Given 4 parameters and no output schema, the description is somewhat incomplete. It lacks details on parameter usage (e.g., account, timezone) and return structure. However, the annotations cover safety, so the description is minimally viable 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?

Schema description coverage is 0%, so the description must compensate. It only hints that patient_ids is for bulk support but does not explain account, timezone, or the relationship between patient_id and patient_ids. This provides minimal added meaning.

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

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

The description clearly states 'Get goal progress for a Dietbox patient' with specific data types (completion percentages, streaks, recent activity) and mentions bulk support, distinguishing it from sibling tools like dietbox_list_goals.

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

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

No guidance on when to use this tool versus alternatives (e.g., dietbox_list_goals) or when not to use it. The description only states functionality without context for 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?

Annotations already declare readOnlyHint=true, so additional behavioral disclosure is minimal. Description confirms it is a read operation and lists the returned data, 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?

One sentence lists the tool's purpose and output fields, but omits crucial parameter information. While concise, it sacrifices completeness.

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 low complexity (one optional parameter, no output schema), the description fails to define the 'account' parameter or elaborate on the return structure beyond a few fields. This is insufficient for correct tool 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?

Description does not mention the 'account' parameter at all. With 0% schema coverage, the description fails to explain the meaning or usage of this parameter, leaving the agent without necessary context.

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

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

Description clearly states the tool gets the nutritionist's professional profile and lists returned fields (CRN, specialties, etc.). It distinguishes from siblings like dietbox_get_profile, though it doesn't clarify whether 'nutritionist' refers to the authenticated user or a specific account.

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

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

No guidance on when to use this tool versus alternatives. Does not explain if the optional 'account' parameter filters for a specific nutritionist or defaults to the current profile.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's contribution is limited. It adds specific return fields ('name, email, subscription plan, features'), but does not disclose behavioral details such as authentication requirements, rate limits, or any potential side effects. With annotations covering safety, a score of 3 is appropriate.

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

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

The description is a single, front-loaded sentence of 12 words. Every word adds value, and there is no redundancy. It efficiently conveys the essential purpose and returned fields.

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 tool with one optional parameter and no output schema, the description lacks completeness. It does not clarify the meaning of the 'account' parameter or the scope of the profile (e.g., own profile vs. another nutritionist's). While annotations cover safety, the description leaves ambiguity that could lead to incorrect 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?

The input schema has an optional parameter 'account' with 0% description coverage. The description does not explain the purpose of this parameter, whether it is needed to fetch another nutritionist's profile, or if it defaults to the authenticated user. This is a significant gap for a simple tool, as the parameter semantics are entirely 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 the tool gets the nutritionist's Dietbox profile and lists specific fields (name, email, subscription plan, features). It uses the specific verb 'Get' and names the resource, making the purpose unambiguous. While there is a sibling tool 'dietbox_get_nutritionist', the description differentiates by specifying 'Dietbox profile' and the fields returned.

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 no guidance on when to use this tool versus alternatives like 'dietbox_get_nutritionist' or other profile-related tools. There are no explicit usage contexts, prerequisites, or exclusions. The agent must infer from the field list, which is insufficient.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by specifying the returned fields (id, email, label, is_default) and the behavior of the default flag. No contradictions, but does not cover potential edge cases like pagination.

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

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

Three sentences, no wasted words. First sentence states purpose, second details return values, third provides cross-tool context. 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?

For a simple list tool, the description fully covers what the tool returns, how to interpret results (is_default flag), and how it integrates with sibling tools. No output schema needed as the description suffices.

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 one optional 'account' parameter with 0% description coverage. The description does not clarify what this parameter does in this tool (e.g., filtering). It only mentions the parameter in the context of other tools, leaving ambiguity for agents.

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 starts with 'List all Dietbox accounts linked to this install,' clearly stating the verb (list) and resource (accounts). It distinguishes itself from sibling tools as the only account listing tool, with specific return fields mentioned.

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 critical context about the 'is_default' flag and how it affects usage of other tools. While it doesn't explicitly state when not to use it, the context is clear and helpful.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the bulk support behavior and mentions showing photos/comments, but does not disclose pagination details, authentication requirements, or error scenarios. The added value over annotations 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 two sentences, front-loaded with the primary purpose, and adds the bulk support detail without waste. 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?

For a tool with 6 parameters and no output schema, the description covers the core functionality and bulk support but omits parameter semantics (date format, skip/take usage, output details). It is adequate but leaves gaps that an agent might need to fill through trial and error.

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

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

Schema description coverage is 0%, meaning no parameter descriptions exist. The description mentions the date context and bulk support (patient_ids) but does not explain other parameters (skip, take, account, patient_id vs patient_ids). With low coverage, the description should compensate more; it provides only minimal guidance.

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

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

The description clearly states the tool lists food diary entries for a Dietbox patient on a specific date, specifying the content (food, photos, comments). This is a specific verb+resource combination that distinguishes it from sibling tools like dietbox_antropometria_list or dietbox_patient_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 via patient_ids, giving some context for batch usage. However, it does not explicitly state when to use this tool versus alternatives (e.g., dietbox_meal_plan for meal plans), 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 declare read-only, idempotent, non-destructive. Description adds filter context but no additional 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?

Single sentence, 12 words, efficient and to the point. However, could include more information without becoming verbose.

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, and description does not describe return fields. For a list tool, agent needs to know what data is returned. Parameter meanings are partially implied 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?

Schema coverage is 0%. Description mentions filtering by date and status but does not explain which schema parameters correspond (e.g., 'paid' for status, 'start_date'/'end_date' for date). No details on 'account' or 'category'.

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 specific verb (list) and resource (financial transactions), mentions types (payments, receivables) and filter criteria (date, status). Distinguishes from sibling tool dietbox_list_accounts.

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

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

No guidance on when to use this tool versus alternatives (e.g., dietbox_list_accounts for accounts). No mention of prerequisites or exclusion 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 destructiveHint=false. Description adds bulk support context but no new behavioral traits beyond what annotations imply.

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: first states purpose, second adds bulk support. No waste.

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 purpose and bulk capability but lacks pagination details (skip/take defaults) and return format. Adequate but with 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 coverage is 0%, so description must add meaning. It explains patient_ids for bulk but ignores skip, take, account parameters, leaving pagination and account undocumented.

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

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

Description clearly states it lists nutrition/health goals for a Dietbox patient, specifying types (weight targets, habit goals, custom objectives) and mentions bulk support. This distinguishes it from siblings like dietbox_get_goal_progress.

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

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

Description implies usage: for single patient use patient_id, for multiple use patient_ids. However, no explicit when-not or alternatives to other list tools.

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

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

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description reinforces read-only with detailed upstream limitation, adds bulk execution context, and 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?

Core purpose is front-loaded. The upstream limitation note is lengthy but valuable. Structure is clear with separate sections and examples.

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

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

Despite no output schema, description details return structure (meals with title, time, text, observacao, weekday flags). Also covers write limitation and bulk support, making it complete 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 coverage is 0%. Description explains patient_ids for bulk but does not clarify relationship between patient_id and patient_ids or account field. 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 retrieves the active meal plan for a patient, listing meals with details. It explicitly distinguishes from prescriptions, ensuring correct selection.

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

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

The description provides explicit guidance: contrasts with prescriptions, indicates use for food/meal plans, mentions bulk support, and explains why no write tool exists (upstream limitation).

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 destructiveHint=true; description adds 'Irreversible' and bulk support, reinforcing but not substantially expanding behavioral context.

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

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

Two sentences with key information front-loaded; no redundant language.

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 details on authentication, cascading effects, or return values, which are important for a destructive tool with no output schema.

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

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

With 0% schema coverage, description only explains patient_ids for batch use, leaving required patient_id and optional account undocumented.

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

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

Clearly states it permanently deletes a patient from Dietbox, distinguishing it from sibling tools like patient_get, patient_list, and patient_write_update.

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?

Mentions bulk support but does not specify when to use this tool versus alternatives or any prerequisites or exclusions.

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 (readOnlyHint=true, destructiveHint=false) already indicate safe read. Description adds bulk execution but no extra behavioral context (e.g., pagination behavior, data scope). 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?

Three sentences, no fluff. Front-loaded with core purpose. Could be more structured but effective for a read tool.

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

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

With 8 parameters, no output schema, and rich sibling set, description lacks important details (e.g., parameter formats, return structure). Incomplete for confident agent 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?

Only 'search' and 'patient_ids' are mentioned in description. Remaining 6 parameters (skip, take, order, account, is_active, patient_id) are unexplained, and schema coverage is 0%. Does not compensate for missing schema descriptions.

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

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

Description clearly states 'Read patients in Dietbox' and enumerates actions (list, get) and bulk support. It distinguishes reading from writing but does not explicitly differentiate from sibling 'dietbox_patient_list' which may 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?

No guidance on when to use this tool versus alternatives (e.g., dietbox_patient_list, dietbox_patient_get_latest). Does not specify prerequisites or preferred 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?

Annotations already declare readOnlyHint and idempotentHint, so the description's main addition is the bulk execution note and flattened action indication. The description adds some context beyond annotations but could be more explicit about pagination and search 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 concise at three sentences, but includes a confusing meta comment '[Flattened action: list]' that adds little value. It could be more structured, e.g., separating list and get descriptions 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 is provided, and the description does not explain what the tool returns for list vs get. With 8 parameters and no parameter descriptions, the description is incomplete for an agent to use the tool effectively without guessing.

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

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

With 0% schema description coverage, the description should explain parameters. It mentions search by name and bulk support via patient_ids, but fails to explain skip, take, order, account, is_active, patient_id, and their interactions. The agent must infer from parameter names alone.

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

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

The description clearly states the tool is for reading patients from Dietbox, specifying the two actions: list (paginated, search by name) and get (full detail). It distinguishes from sibling write and delete tools by emphasizing read-only nature.

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 that list is for multiple patients and get for a single patient, but does not explicitly say when to use each or provide alternatives. It mentions bulk support with patient_ids, but no direct comparison to dietbox_patient_get or other 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?

Discloses important behavioral details beyond annotations: phone normalization to E.164, gender conversion to boolean, and the possibility of HTTP 400 errors if phone format is incorrect. No contradiction with annotations.

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

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

The description is well-structured with separate lines for actions, normalization, and references, but includes some redundancy (Portuguese/English mix) and an unclear 'Flattened action: create' line, slightly reducing 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?

Covers the main behavioral aspects (create vs update, phone handling, gender, bulk support) and references the delete tool, missing details on some optional parameters and return values, but sufficient for agent usage given no output schema.

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

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

Adds meaning beyond the schema for several parameters (Gender, Phone/MobilePhone, Name, patient_ids) but does not cover all 12 parameters (e.g., Cpf, Email, Birthday, IsActive). Given 0% schema description coverage, the description compensates well for key parameters.

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

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

The description clearly states 'Create or update patients in Dietbox', distinguishes between create and update actions, and mentions the sibling tool for deletion, making its 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?

Explicitly explains when to use create vs update (create requires Name, POST; update uses PATCH with partial fields), provides context for phone number normalization and gender conversion, and directs users to dietbox_patient_delete for destructive removal.

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 significant behavioral details beyond annotations: gender conversion to boolean, automatic phone normalization to E.164 with examples and error handling, and bulk support. No contradictions with annotations (readOnlyHint=false, destructiveHint=false) are present.

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

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

The description is well-organized with action breakpoints and examples, but includes some redundant text and a mix of Portuguese/English. The note '[Flattened action: update]' adds minor confusion. Overall, it is reasonably concise for a 12-parameter tool.

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

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

Given no output schema and 12 parameters, the description covers the core workflow (create/update, phone normalization, gender, bulk) but omits return values and some parameter roles (e.g., patient_id for update). It provides enough context for typical 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 description coverage, the description adds essential meaning for key parameters (Name, Gender, Observation, Phone, MobilePhone, patient_ids), including value formats and conversion logic. However, other parameters like Cpf, Email, account, etc., lack elaboration.

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

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

The description clearly states it creates or updates patients, specifying HTTP methods (POST for create, PATCH for update) and contrasts with the deletion sibling (dietbox_patient_delete). It distinguishes between create and update actions, making the tool's scope 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 context for when to create vs update (Name required for create, partial fields for update) and mentions bulk execution. However, it does not contrast with the similar sibling dietbox_patient_write_create, leaving potential confusion for the agent.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds context about actions (list, get, list_models) and bulk support, but does not explain pagination, rate limits, or response structure. Contributes beyond annotations but not substantially.

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 short but includes a confusing action list and '[Flattened action: get]'. The purpose is front-loaded, but the mixed messages reduce clarity. Could be more concise and consistent.

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 and 0% parameter coverage. The description does not mention return values, pagination behavior, or how to interpret the results, leaving significant gaps for an 8-parameter 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 description coverage is 0%. Description only hints at 'patient_ids' and 'prescription_ids' for bulk execution. The other six parameters (skip, take, search, account, patient_id, prescription_id) are left unexplained, placing the burden on the schema which lacks descriptions.

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

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

Clearly states it reads prescriptions in Dietbox and distinguishes from meal plans (sibling tool). However, the listing of three actions within a 'get' tool and the '[Flattened action: get]' note create confusion about the exact 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?

Explicitly mentions when to use an alternative tool (dietbox_meal_plan for food plans). Also notes bulk support for batched execution, but lacks guidance on when to use individual vs. batch or 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about bulk support and multi-actions, but does not disclose additional traits like auth requirements, rate limits, or error 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 brief and front-loaded with key information. However, the bracketed note '[Flattened action: list]' adds unnecessary jargon that may confuse the agent, reducing clarity slightly.

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

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

For a tool with 8 undocumented parameters and no output schema, the description lacks crucial details such as pagination behavior, search functionality, required parameters, and distinction from sibling tools. Significant information is missing.

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

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

With 0% schema coverage, the description must compensate. It explains patient_id/prescription_id and their bulk counterparts, but completely omits skip, take, search, and account parameters, leaving them ambiguous.

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 supplement/herbal medicine prescriptions and explicitly differentiates from meal plans, naming the alternative tool dietbox_meal_plan. It lists three actions (list, get, list_models) defining the scope precisely.

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 an explicit exclusion for meal plans and directs to dietbox_meal_plan. It outlines actions and bulk support, but does not clarify when to use this combined tool versus the dedicated siblings dietbox_prescription_get and dietbox_prescription_list_models.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description confirms it is for reading and mentions batch execution, adding some behavioral context but not significantly 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 compact (4 sentences) with clear front-loading of purpose, then actions, flattened action, and bulk support. No redundant 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?

Given the tool has no output schema, 0% param descriptions, and complex input with arrays, the description should explain return values and parameter usage. It fails to do so, leaving the agent guessing about response format and 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?

Schema description coverage is 0%, so the description must compensate. It only mentions patient_ids and prescription_ids for bulk support, ignoring the other 6 parameters (skip, take, search, account, patient_id, prescription_id). This is insufficient for an 8-parameter 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 it reads supplement/herbal medicine prescriptions and explicitly distinguishes from meal plans by directing to dietbox_meal_plan. It specifies the actions (list, get, list_models) and clarifies the flattened action is list_models for reusable 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 provides a clear alternative for meal plans (use dietbox_meal_plan) but does not differentiate from sibling tools dietbox_prescription_get or dietbox_prescription_list. It mentions bulk support but no guidance on when to use this tool versus those for individual prescriptions.

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 write operation, merging of title/patient_id into data, and bulk support. However, does not mention potential side effects or response format; annotations already indicate non-read-only and non-destructive.

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 sentences, each adding value: purpose/sibling, required fields, data param, bulk support. 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?

Missing details on response format, constraints on data structure, and account param. Bulk support is mentioned but not explained in terms of usage or conflict with patient_id. Portuguese phrases may reduce clarity for non-Portuguese agents.

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?

Explains title (required with error message), patient_id (required), data (JSON string for payload), and patient_ids (bulk). Account param is undocumented; with 0% schema coverage, description compensates fairly 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 'Create a new supplement/herbal medicine prescription in Dietbox' and distinguishes from meal plan tool, making the purpose specific 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?

Provides required parameters (title, patient_id) and error behavior if title missing. Mentions bulk support but lacks explicit when-not-to-use or alternatives beyond meal plans.

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 tool is safe. The description adds that it returns clinical record with medical history and notes and that batch execution is possible. It does not mention error handling or return format, but the safety profile is clear.

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

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

The description is two sentences, front-loaded with the purpose, and includes a separate line for bulk support. No unnecessary words.

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

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

With no output schema and 3 parameters (one undocumented), the description explains the main purpose and bulk ability but lacks detail on account usage, return structure beyond 'medical history, notes', and potential error conditions. It is minimally 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 description must compensate. It explains patient_ids for batched execution, but does not describe the account parameter, the format of patient_id, or the relationship between patient_id and patient_ids (e.g., exclusive or combined). This leaves 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 that the tool retrieves a clinical record (prontuario) including medical history and notes, and mentions bulk support, distinguishing it from sibling tools like dietbox_anamnese_get or dietbox_patient_get.

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

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

The description indicates bulk support but does not explicitly state when to use this tool versus alternatives like dietbox_anamnese_get for specific anamnesis or dietbox_patient_get for patient profile. Usage context is implied, not explicit.

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

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

Annotations indicate not read-only and not destructive. The description adds behavioral details: 'Returns 204 on success' and 'Bulk support: accepts patient_ids'. However, it does not disclose authentication needs, rate limits, or side effects like overwriting existing data. Adequate but not comprehensive.

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

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

Three concise sentences with front-loaded purpose. Every sentence adds value: purpose, text format + return status, bulk support. No wasted words.

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

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

For a simple update tool with 4 parameters and no output schema, the description covers key aspects: action, input format, return status, batch mode. Minor gaps: no mention of error handling, optional parameters like account, or whether it is an upsert. Generally 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 'text' parameter as 'HTML supported' and 'patient_ids' for bulk execution. But it does not describe 'account' or clarify 'patient_id' beyond schema. Partial value added, but gaps remain.

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 'Update' and the resource 'clinical record (prontuario)', which is specific. It distinguishes from siblings by name, but does not explicitly contrast with similar tools like dietbox_anamnese_write or dietbox_prescription_write, leaving some ambiguity.

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

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

No explicit guidance on when to use this tool versus alternatives. It mentions bulk support but does not specify prerequisites (e.g., patient must exist) or exclude cases like creation of new records (tool says 'Update', but could it create?). Lacks context for use.

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 that writes require workspace owner/admin, explains behavior of search (flags installed status), and covers actions like install/uninstall/subscribe without contradicting annotations (readOnlyHint=false). Provides 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 dense paragraph that covers many aspects, but it is slightly verbose and could benefit from bullet points or separation of actions for clarity. Still, it is front-loaded with the core purpose.

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

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

Given 13 parameters, no output schema, and no nested objects, the description is remarkably complete. It covers all 10 actions, usage scenarios, permission requirements, and edge cases like flat-mode clients. An agent has sufficient context to use the tool correctly.

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

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

Despite 0% schema coverage, the description explains the meaning of the 'action' parameter and its enum values, and indirectly describes other parameters like query, limit, mcp_id, tool_id, arguments. Lacks explicit format details for some parameters like 'arguments' JSON structure.

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 the official mcp.ai marketplace catalog, provides a specific verb ('search') and resource ('MCPs/tools'), and distinguishes it from siblings by stating it should be used before external registries.

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

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

Explicitly states when to use this tool ('when the user wants a new capability... use THIS tool (action=search) FIRST'), when not to ('before any external or generic MCP registry'), and provides alternatives like list_tools/invoke for flat-mode clients.

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 (safe to retry) and destructiveHint=false. Description adds little beyond the purpose, not disclosing where feedback goes or side effects. With annotations present, the bar is lower, but more context could be helpful.

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, followed by actionable instruction. No redundant 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?

For a simple feedback tool, it covers the basics but omits what happens after reporting (no output schema) and potential error handling. Adequate but not thorough.

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

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

Schema description coverage is 0%, so description must compensate. It mentions conversation array but does not explain the 'context' parameter or clarify the required 'message'. Only partial 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?

Description clearly states it's for reporting bugs, missing features, or feedback. This distinguishes it from sibling tools which are mostly specific operations (dietbox, authenticate, etc.).

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 instructs to include the conversation array for reproduction, giving clear context for use. No explicit when-not-to-use, but the purpose is self-evident.

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 and idempotentHint, covering safety. The description adds specific content (platform and adapter), but no additional behavioral traits like auth requirements 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?

Single sentence of 9 words, perfectly concise and front-loaded with 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?

For a simple version retrieval tool with no parameters and clear purpose, the description is complete. No output schema is expected for such a straightforward return.

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 no parameters (100% coverage), so baseline 3 is appropriate. The description does not add parameter info, 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 verb 'Show' and the specific resource 'current MCP platform and adapter versions', making the purpose unambiguous and distinct from 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 implies usage for retrieving version information. No explicit when-not-to-use or alternatives are needed given the simplicity, but it lacks explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the returned data (connection status, catalog counts) 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?

Single sentence, zero wasted words. Front-loaded with action and resource, then specifies what is returned.

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 fully explains the return content (state, connections, catalog tool counts). No gaps for a simple informational 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?

No parameters exist, so schema coverage is 100%. The description need not add parameter details; baseline score 4 applies.

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, their connection status, and catalog tool counts. This verb+resource combination is specific and distinguishes it from informational siblings like show_version.

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?

Implied usage as a general overview tool; no explicit when-not or alternative advice, but the context is clear given the read-only nature and sibling tool list.

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