Feegow Clinic

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

Annotations indicate idempotentHint=true and destructiveHint=false. Description adds context about the two authentication methods, the behavior of calling with or without token, and the permanence of config-based auth. 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 a single paragraph with clear, actionable sentences. No unnecessary words. Could be slightly more structured (e.g., bullet points), but remains 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 authentication tool with one optional parameter, the description covers the essential workflow: two login methods, token format, and best practice. No output schema, but the behavior is adequately described.

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

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

Schema has one optional parameter 'token' with no description. Description explains that token is a JWT and clarifies the two scenarios: pass token for session login or omit to get a link. This adds necessary meaning beyond the bare schema.

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

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

Clearly states the verb 'authenticate' and the resource 'MCP.AI for IDE agents'. Distinguishes from siblings by being the only authentication tool among many feegow and other tools. Explains two methods of login: permanent via config header or session via token.

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 the tool (for login) and provides context for two use cases. Does not explicitly mention when not to use, but the purpose is clear and well-scoped.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, indicating safe, idempotent read operation. The description adds behavioral context by detailing response fields (authenticated, pending, connect_url) and explaining different states, going beyond annotations.

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

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

Two sentences, front-loaded with the main action. Every sentence provides essential information without redundancy. Highly concise and well-structured.

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

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

Given no output schema, the description explains key return scenarios (authenticated state, pending array, connect URLs). It covers the necessary context for an agent to interpret results correctly. Complete for a simple status check tool.

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

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

The input schema has zero parameters, and schema description coverage is 100% (trivially). Per guidelines, zero parameters earn a baseline of 4. The description adds no parameter semantics, but none needed.

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

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

The description clearly states the tool 'Returns connection status and URLs', specifying the verb (returns) and resource (connection status). It distinguishes itself from siblings like 'authenticate' by focusing on status rather than performing authentication. Additional details about different response scenarios add clarity.

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

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

The description provides context on when to use the tool by explaining behavior under different conditions (all providers connected vs missing credentials). However, it does not explicitly mention when not to use it or offer alternative tools, leaving some guidance implicit.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by stating 'Read appointments and scheduling data'. The description adds that it finds available time slots, but does not disclose additional behavioral traits like authentication or rate limiting.

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

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

The description is verbose, listing multiple actions irrelevant to this specific tool. It would be more concise and front-loaded by focusing solely on the available_schedule action.

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

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

Given the low schema coverage and no output schema, the description fails to explain how to supply the required parameters via the 'data' field or the expected format. It is incomplete and inconsistent with the actual 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?

The input schema defines only 'data' and 'account' as string parameters with no descriptions, while the description details many parameters like tipo, data_start, data_end, etc. that are not present in the schema. This mismatch misleads the agent about what parameters to provide.

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 includes the specific action 'available_schedule: find available time slots' which clarifies the tool's purpose, but it also lists other unrelated actions (list, statuses, etc.) that are not part of this tool, causing potential confusion. The tool name itself is clear enough.

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 its sibling tools. It only provides parameter requirements for the available_schedule action, but no guidance on alternatives or 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, idempotentHint=true, and destructiveHint=false, which align with the described 'Read' nature. The description adds some parameter details for internal actions but does not disclose additional behavioral traits (e.g., rate limits, side effects) 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 long and contains verbose parameter lists for each action, but the critical information (that this tool is for channels and how to invoke it given the minimal schema) is not front-loaded. The note '[Flattened action: channels]' adds confusion rather than clarity.

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

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

Given the minimal input schema (two string parameters) and no output schema, the description should explain how to use the tool. Instead, it details parameters that do not exist in the schema, making it impossible to correctly invoke the tool based on the description alone. The description is severely incomplete.

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

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

The input schema has only two generic parameters ('data' and 'account') with 0% schema description coverage, but the description lists many action-specific parameters (e.g., data_start, profissional_id) that are not part of the actual schema. The description does not explain how 'data' and 'account' relate to the actions, leaving the agent without guidance on how to populate the real parameters.

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

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

The description lists multiple actions (list, statuses, motives, channels, etc.) but the tool name is 'channels' and the note '[Flattened action: channels]' suggests it is specifically for accessing appointment channels. This ambiguity makes it unclear what the tool actually does, as it duplicates functionality of 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?

No guidance is provided on when to use this tool versus its siblings (e.g., feegow_appointment_list, feegow_appointment_statuses). The description does not differentiate between this tool and others, leaving the agent to guess which tool to invoke.

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, but the description includes 'queue_position: generate queue ticket', which implies a state-changing operation. This contradiction reduces transparency. Additionally, the input schema does not match the described parameters, further obscuring 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 verbose, mixing multiple actions in a single block. It ends with an unexplained '[Flattened action: list]', which is cryptic. Better structure would isolate the primary list action and note that other actions are separate tools.

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 (multiple actions described, rich sibling ecosystem) and minimal input schema (no descriptions, no output schema), the description fails to explain how to use the actual parameters or interpret the flattened action, leaving critical 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 input schema has only 'data' and 'account' with no descriptions (0% coverage). The description extensively lists parameters like data_start, data_end, profissional_id, etc., but these are not in the schema, adding no value to the actual parameters and creating confusion.

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

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

The description lists multiple actions (list, statuses, motives, channels, available_schedule, queue_position) but the tool name is 'appointment_list', suggesting a focused purpose. The description conflates these actions, and many have separate sibling tools, causing ambiguity about the tool's primary function.

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

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

No guidance on when to use this tool versus its siblings (e.g., feegow_appointment_statuses, feegow_appointment_channels). The description lists actions that overlap with existing distinct tools, leaving the agent without clear criteria for tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the descriptor adds no new behavioral information. The description does not disclose rate limits, authentication needs, or other traits beyond what annotations cover.

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

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

The description is long and includes multiple unrelated actions, making it not concise for this specific tool. The 'Flattened action: motives' note is buried at the end, reducing clarity.

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

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

Given the tool's complexity within the appointment suite, the description is incomplete. It does not explain the output format, parameter requirements for motives, or how the tool fits into workflow, leaving agents with insufficient context.

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

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

The input schema has two parameters (data, account) with 0% description coverage. The description does not explain how these parameters relate to the motives action, leaving the agent without guidance on parameter usage.

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

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

The description clearly states that the tool lists cancellation/rescheduling motives, distinguishing it from sibling tools like statuses and channels. However, the description also includes a general statement about reading appointments and scheduling data, which could be seen as broad.

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

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

The description does not provide any guidance on when to use this tool instead of alternatives like feegow_appointment_statuses or feegow_appointment_list. It simply describes the action 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 declare readOnlyHint=true and idempotentHint=true, but the description includes 'queue_position' action that 'generates a queue ticket,' implying a write operation. This contradicts the readOnly hint. No explanation of other behavioral traits.

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

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

The description is verbose and includes multiple actions not relevant to the tool name. It is not front-loaded; the key purpose is buried. Every sentence does not earn 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 the minimal schema and absence of output schema, the description fails to explain how to use the actual parameters (data and account). It provides no context on return values or behavior beyond listing unrelated actions.

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

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

The input schema has only two parameters (data, account) with 0% description coverage. The description lists many parameters for various actions (e.g., data_start, profissional_id) that are not in the schema. This misleads the agent about what parameters are actually required.

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 includes multiple actions (list, statuses, motives, channels, available_schedule, queue_position) but the tool name specifically suggests queue_position. The ending says '[Flattened action: queue_position]' which is confusing. It does not clearly state what the tool does in relation to its name.

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 siblings. The description lists parameters for actions but does not differentiate this tool from similar sibling tools like feegow_appointment_available_schedule or feegow_appointment_list.

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

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

The description claims to support actions with many parameters (data_start, profissional_id, etc.), but the actual input schema only has two string fields ('data' and 'account'). This contradiction makes the tool's real behavior opaque and misleading.

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

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

The description is excessively long and contains a list of actions that are irrelevant to the tool's actual functionality (based on the schema). The final note '[Flattened action: statuses]' suggests oversimplification, but the overall structure is poor and wastes space.

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 mismatch between the described functionality and the minimal schema, the description fails to provide a complete and accurate picture. It does not explain how the tool works with only two parameters, leaving the agent without actionable guidance.

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

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

Schema description coverage is 0% and the description lists numerous parameters (e.g., data_start, data_end, profissional_id) that are not present in the schema. This misleads the agent into thinking it can pass those parameters, leading to inevitable errors.

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 'Read appointments and scheduling data in Feegow.' which is broad and does not match the tool name 'feegow_appointment_statuses'. It lists multiple actions (list, statuses, motives, etc.) that are likely handled by other sibling tools, causing confusion about the actual 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?

No guidance is given on when to use this tool versus its siblings (e.g., feegow_appointment_list, feegow_appointment_channels). The description lists actions that appear to belong to other tools, making it impossible to determine when this specific tool is appropriate.

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

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

Annotations show readOnlyHint=false, destructiveHint=false, which are consistent with a cancel operation. The description adds that cancel is 'reversible status flip', which is helpful. However, the massive mismatch between described parameters (detailed lists) and actual schema (only data and account) undermines transparency.

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

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

The description is excessively long (multiple action cases) for a tool that likely only cancels. Important info is buried, and irrelevant details for other actions are included. Not concise or 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?

Though the tool appears complex (multiple actions implied), the actual schema has only 2 params with no output schema. The description fails to explain the schema mismatch, leaving an agent confused about what parameters to use. Incomplete and misleading.

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 does not explain the actual parameters ('data' and 'account') at all. Instead, it lists many parameters for hypothetical actions that do not match the schema. No semantic value added for the real parameters.

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

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

The description lists multiple actions (create, cancel, reschedule, update status) but the tool name and sibling tools strongly indicate it is for cancel only. The flattened action '[cancel]' contradicts the body. Purpose is vague and not specific to the tool's role.

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

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

No explicit when-to-use guidance. The description suggests the tool can perform any action, but sibling tools for other actions exist, creating confusion about when to use this vs. others.

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 readOnlyHint=false and destructiveHint=false. The description adds context that cancellation is a reversible status flip, not hard delete. However, the description fails to align with annotations regarding the scope of actions (create vs. all).

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

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

The description is verbose and mixes multiple actions, but it is structured with bullet points and optional fields. However, it could be more concise by focusing on the single intended action (create) and referencing siblings for others.

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 schema poverty and complexity, the description attempts to be complete but fails due to contradictions with sibling tools and the schema. The output schema is absent, so return values are not 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?

The input schema has 0% description coverage with only 'data' and 'account' parameters. The description compensates by listing many action-specific parameters, but these do not match the schema, leading to confusion about which parameters are actually required or available.

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 claims the tool can create, cancel, reschedule, or update status, which contradicts the existence of sibling tools dedicated to cancel, reschedule, and update status. The phrase '[Flattened action: create]' adds confusion, as the description itself describes multiple actions. This misalignment makes the purpose unclear.

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

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

No guidance is provided on when to use this tool versus its siblings (e.g., feegow_appointment_write_cancel). The description lists multiple actions without indicating which scenario warrants this tool over another.

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). The description adds some context: cancellation is a reversible status flip, not a hard delete. However, it does not disclose authentication needs, rate limits, or side effects for other actions. 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 verbose with bullet points for multiple actions, but the tool name suggests a single action. The 'Flattened action: reschedule' contradicts the listed actions. The structure is not tailored to this specific 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 the complexity of multiple actions and many parameters, the description fails to explain how to invoke the tool correctly. The schema does not support the described parameters, making the description useless for proper invocation. 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?

The description lists many parameters (e.g., local_id, paciente_id) for each action, but the input schema only has 'data' and 'account' with no descriptions. This mismatch is highly misleading; the agent cannot map described parameters to actual schema properties.

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 claims to handle create, cancel, reschedule, and update_status, but the tool name is 'reschedule' and sibling tools exist for each specific action. This ambiguity confuses the tool's actual purpose. The 'Flattened action: reschedule' hint adds contradiction.

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 sibling tools like feegow_appointment_write_cancel or feegow_appointment_write_create. The description does not differentiate use cases or provide 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 provide basic hints (readOnlyHint=false, destructiveHint=false). The description adds that cancel is 'reversible status flip, not a hard delete.' However, it does not disclose authentication needs, rate limits, or other side effects 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 moderately structured with bullet points per action, but is verbose in listing optional parameters repeatedly. The 'Flattened action: update_status' note adds confusion. 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?

Given no output schema and minimal input schema, the description covers actions and parameters well but lacks integration with the actual API signature (e.g., how to structure the 'data' field). Missing return value info and error handling, so incomplete for practical invocation.

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

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

With 0% schema description coverage, the description carries full burden. It lists required/optional parameters per action and gives format hints (e.g., data in DD-MM-YYYY). However, it does not explain how to map these to the actual schema's 'data' string property, leaving a gap.

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

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

The description clearly states the tool can create, cancel, reschedule, or update status of appointments, listing actions with parameters. It distinguishes from sibling tools like feegow_appointment_write_cancel by offering a consolidated interface. However, the name 'update_status' is narrower than the actual scope.

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

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

The description provides detailed parameter lists per action but does not explicitly guide when to use this tool versus the sibling tools for individual actions (e.g., feegow_appointment_write_create). No exclusions or alternatives are mentioned.

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

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

Annotations already indicate readOnly, idempotent, and not destructive. The description adds filter details 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?

The description is structured with bullet points but includes extraneous details like both actions and a note about 'Flattened action'. It 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?

Given no output schema and low schema coverage, the description fails to explain return values or how to use the 'data' and 'account' parameters. It also does not clarify the mismatch between the listed filters and actual 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?

The input schema has two parameters 'data' and 'account' with no descriptions, and the description does not explain them. It instead lists filters that are not in the schema, providing no help for the actual parameters.

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

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

The description states 'Read benefit card data' and lists two actions with filters, making the purpose clear. However, it includes both list_contracts and list_plans while the tool is specifically for list_contracts, causing slight ambiguity.

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

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

No guidance on when to use this tool versus the sibling 'feegow_benefit_card_list_plans' or other contexts. The description lacks explicit when-to-use and when-not-to-use information.

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, so basic safety is covered. The description adds minimal context ('Read') beyond annotations, but does not provide additional behavioral details like pagination or authorization.

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 includes extraneous mention of list_contracts, which may not belong to this tool. Front-loaded with 'Read benefit card data' but lacks focus.

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

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

Given only 2 parameters with no schema descriptions and no output schema, the description should explain the parameters and return format. It fails to do so, and the listed filters do not correspond to the actual 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?

Input schema has 2 parameters (data, account) with 0% coverage. Description lists filters (page, perPage, id) that do not match schema parameters, causing confusion. No useful meaning added to actual parameters.

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

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

The description states 'Read benefit card data' but is ambiguous whether it lists contracts and plans or just plans, given the name and '[Flattened action: list_plans]' note. It does not clearly distinguish from the sibling tool 'feegow_benefit_card_list_contracts'.

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

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

No explicit guidance on when to use this tool versus alternatives like 'feegow_benefit_card_list_contracts'. The description simply lists actions without 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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that create_contract requires a 'full body with contract, recurrence, people arrays,' but does not disclose behavior like auth requirements, side effects, or error handling.

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

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

The description is moderately concise but includes redundant listing of actions that could be split into separate tool definitions. The flattened action note is helpful, but overall structure could be tighter.

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

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

Given the minimal input schema and absent output schema, the description provides enough context for a simple create action but lacks details on prerequisites, error states, or expected return format.

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

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

Input schema has 0% description coverage, but the description partially compensates by explaining that for create_contract the data string should contain 'contract, recurrence, people arrays.' The account parameter is not explained, leaving ambiguity.

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

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

The description specifies the tool is for writing benefit card operations, and the flattened action indicates the specific operation for this instance (create_contract). However, it lists multiple actions (update_contract, create_plan, update_plan) which could cause confusion with sibling tools like feegow_benefit_card_write_create_plan.

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 siblings such as feegow_benefit_card_write_create_plan or feegow_benefit_card_write_update_contract. The description does not differentiate between similar write operations, leaving the agent without clear selection 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 confirm a write operation (readOnlyHint=false) but the description only states 'create benefit plan' without disclosing side effects, idempotency, or error conditions. No additional behavioral context beyond the obvious.

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

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

The description includes extraneous actions for a tool that seems to focus on create_plan. The '[Flattened action: create_plan]' note is confusing. Could be streamlined to focus on the actual action.

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

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

The description fails to provide a complete understanding. It lacks details on the required format of 'data', what each plan field means, and what the response looks like. With no output schema, this is insufficient for an agent to invoke correctly.

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

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

Schema coverage is 0%, so the description must explain parameters. It lists fields for create_plan (name, membershipValue, etc.) but does not clarify how they map to the 'data' string parameter. The two parameters 'data' and 'account' are not explained.

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

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

The description lists multiple actions (create_contract, update_contract, create_plan, update_plan) but the tool name and '[Flattened action: create_plan]' suggest it is specifically for creating a plan. This ambiguity hurts clarity relative to sibling tools like feegow_benefit_card_list_plans and feegow_benefit_card_write_update_plan.

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

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

No explicit guidance on when to use this tool vs alternatives such as create_contract or update_plan. The description does not mention prerequisites, exclusions, or context for choosing 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 mark the tool as non-readOnly and non-destructive. The description adds 'write benefit card operations' but fails to disclose side effects, idempotency, or behavior of individual actions (e.g., whether updates are partial or full replacement).

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 redundant action listings and an ambiguous flattened action note. It could be clearer and more focused on the intended action.

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

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

The description lacks critical information: how to select an action, the format of the 'data' string, return values, and error conditions. Given the presence of sibling tools and the complexity of the domain, the description is insufficient.

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

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

The schema has two parameters, 'data' and 'account', with no descriptions in the schema (0% coverage). The description briefly mentions 'Full body with contract, recurrence, people arrays' for create_contract but does not explain the structure of 'data' for other actions, nor the role of 'account'.

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

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

The description lists multiple actions (create_contract, update_contract, create_plan, update_plan) but the tool name and final note indicate it's for update_contract. This ambiguity obscures the specific purpose and conflicts with sibling tools that specialize in each action.

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

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

No guidance is provided on when to use this tool versus sibling tools like feegow_benefit_card_write_create_contract or feegow_benefit_card_write_update_plan. The description does not clarify which action to choose or how to specify 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 are present but basic (no readOnly, destructive hints). The description adds little beyond stating 'write operations' – no details on side effects, authorization needs, or what 'benefit card' means. With annotations covering safety profile minimally, the description should compensate but does not.

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

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

The description is relatively concise but structurally confusing. It lists four actions then appends '[Flattened action: update_plan]', which contradicts the earlier listing. This wastes space and reduces clarity.

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

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

The tool handles multiple operations with no output schema, no error or return information, and incomplete parameter explanations. Given the complexity and zero schema coverage, the description should provide more context, such as the format of the 'data' parameter for each action.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions JSON bodies for actions but does not link to the 'data' and 'account' parameters. The description does not clarify what these parameters contain (e.g., is 'data' the JSON string for the action?). This is insufficient.

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

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

The description lists multiple actions (create_contract, update_contract, create_plan, update_plan) but the title and final line 'Flattened action: update_plan' suggest a primary focus. This creates ambiguity about the tool's actual purpose, making it unclear whether it handles multiple operations or just plan updates.

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 sibling tools like feegow_benefit_card_write_create_plan or update_contract. The description does not differentiate use cases or indicate prerequisites, leaving the agent to infer from names 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 set readOnlyHint=true, so the description's 'Read' aligns. However, the description lists three parameters that are not present in the actual input schema (data, account), creating a mismatch. This misrepresentation of how to invoke the tool significantly reduces transparency.

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

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

The description is concise with two sentences. The first sentence states the purpose, and the second lists required fields. Despite the content issue, the structure 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?

For a read operation with required parameters and no output schema, the description should explain how to construct the input. It fails to address the mismatch between listed parameters and the actual schema, leaving the agent with insufficient guidance for correct 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?

Schema description coverage is 0%, so the description must clarify the parameters. It lists billing_type_id, insurance_id, and billing, but the schema only has 'data' and 'account'. The description fails to map these to the actual schema, making it unclear how to provide the required 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 it reads insurance billing guides, which distinguishes it from write siblings like feegow_billing_write_create and feegow_billing_write_edit. The verb 'Read' and resource 'insurance billing guides (guias)' are specific and clear.

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

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

The description lists required parameters (billing_type_id, insurance_id, billing) but does not explicitly state when to use this tool versus alternatives. However, the read-only nature is implied by the description and annotations, providing some usage 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 provide no readOnly or destructive hints, so description must clarify mutation behavior. It says 'create or edit' but doesn't describe side effects, idempotency, permission requirements, or what happens on duplicate creation. The flattened action note adds ambiguity rather than clarity.

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

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

The description is short but poorly structured. It redundantly lists actions and then adds a contradictory flat comment. The layout is not front-loaded; the key takeaway (flattened action) is at the end. Space could be used more effectively to explain the single actual action and parameter structure.

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

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

With low schema coverage and no output schema, the description should fully compensate. It does not explain the 'data' parameter format, the 'account' parameter's purpose, or what the tool returns. For a mutation tool, this is critically incomplete, leaving the agent unable to correctly invoke it.

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 two parameters (data, account) with 0% description coverage. Description adds meaning by mentioning JSON data for create and specific fields (billing_id, billing_type_id) for edit, but these fields are not reflected in the schema's parameter list. This creates confusion and misalignment between description and actual interface.

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

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

The description states 'Create or edit insurance billing guides', which is specific but confusing because a sibling tool 'feegow_billing_write_edit' exists for editing. The purpose is somewhat clear for creation, but the inclusion of editing blurs the distinction without clear differentiation.

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

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

No explicit guidance on when to use this tool versus the separate edit tool. The description lists create and edit actions, but the input schema lacks an action field, making it unclear how to invoke edit. The final '[Flattened action: create]' suggests only create is actually supported, contradicting the earlier instructions.

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 and the description does not add behavioral context beyond indicating write operations. No disclosure of side effects, permissions, or rate limits. With no annotations providing safety details, the description fails to compensate.

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 but includes a confusing 'Flattened action: edit' line that undermines clarity. It front-loads the action list but fails to resolve ambiguity. Could be more concise and structured.

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

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

Given the schema does not include a mode parameter and the description implies two distinct actions, the lack of clarity on how to specify the action leaves the tool incomplete. No output schema, no error or return value information.

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 mentions parameters like 'billing_id', 'billing_type_id', and 'attribute to edit' that do not exist in the input schema (only 'data' and 'account'). This contradiction misleads the agent about how to invoke the tool. Schema coverage is 0%, and the description adds incorrect 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 states it can create or edit insurance billing guides, but the note 'Flattened action: edit' creates confusion. It distinguishes create vs edit but the schema does not reflect the required parameters for each action, making the purpose unclear.

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

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

No explicit guidance on when to use this tool versus the sibling 'feegow_billing_write_create'. The mention of both create and edit actions without clear delineation misleads the agent. No when-not-to-use information.

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 a safe read operation. Description adds 'Read clinic company info' consistent with annotations, but doesn't disclose any additional behavioral traits like output format or pagination. 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 short but includes extraneous information about list_units, which is better left to the sibling tool. The flattening note is helpful but the mixed focus reduces clarity. Could be more concise by only describing list_locals.

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

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

Given the simple schema (3 params, no output schema), a clear description should suffice, but the ambiguity about the actual action and parameter roles leaves the agent unsure about what the tool returns and how to use parameters correctly.

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

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

With 0% schema coverage, the description must explain parameters. It mentions 'Optional: endereco, cep' but only in context of list_units, not list_locals. The 'account' parameter is not explained at all. This provides insufficient meaning for the agent to correctly invoke the 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?

Description states 'Read clinic company info' but then lists two actions (list_units and list_locals) while the tool name suggests list_locals. The final 'Flattened action: list_locals' clarifies the intended action, but the inclusion of list_units creates ambiguity and conflates with sibling tool feegow_company_list_units.

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 siblings like feegow_company_list_units. The description even mentions list_units as a possible action, potentially leading an agent to use this tool for unit listing instead of the dedicated sibling.

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. The description adds 'Read clinic company info', but also includes an action (list_locals) that belongs to a separate tool, potentially misleading the agent about 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 short but includes redundant mention of an action that belongs to another tool. It could be more focused on 'list_units' only, reducing clarity.

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

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

With 3 undocumented parameters and no output schema, the description fails to explain what the tool returns or how parameters affect results. It also introduces irrelevant functionality (list_locals), making it incomplete.

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

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

Schema coverage is 0%. The description only notes 'Optional: endereco, cep' without explaining their meaning or usage. The 'account' parameter is not mentioned at all, adding minimal value over the schema.

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

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

The description mentions two actions ('list_units' and 'list_locals'), but the tool name indicates only 'list_units'. This blurs purpose and fails to distinguish from the sibling tool 'feegow_company_list_locals'.

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 vs alternatives. The description does not mention the sibling tool or exclude cases, leaving the agent uninformed about appropriate context.

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

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

Annotations already declare read-only, non-destructive, idempotent. Description adds batch execution capability via 'unidade_ids', providing useful behavioral context beyond annotations.

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

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

Two focused sentences, first covers purpose and key parameters, second adds bulk feature. No wasted words, easy to scan.

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, required/optional parameters, batch support. Lacks details on output format or pagination, but for a simple list tool with good annotations, it's adequate.

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

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

Describes ativo (with values explained), unidade_id (optional), and unidade_ids (bulk). However, the 'account' parameter is not mentioned, leaving its purpose unclear. With 0% schema coverage, the description partially compensates.

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?

States 'List employees in Feegow' clearly identifying the action and resource. While it doesn't explicitly differentiate from sibling list tools, the resource name 'employee' is distinct.

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 parameter requirements (ativo) but no guidance on when to use this tool versus sibling list tools for other entities. No exclusionary 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 include destructiveHint=true, indicating irreversibility. The description adds 'All are irreversible,' which reinforces but doesn't substantially expand beyond the annotation. The mention of unrelated actions introduces slight confusion, but there is 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 short but includes extraneous listing of other actions not relevant to this specific tool. The flattened action note is helpful. Some noise could be removed without losing meaning.

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 minimal description, the tool lacks information on return values, error conditions, or side effects beyond irreversibility. For a destructive operation, more context (e.g., what happens to related data) is needed for safe use.

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

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

Schema coverage is 0%, and the description provides no explanation of the parameters 'data' and 'account'. The agent must infer their purpose (likely voucher identifier and account context) without any guidance, risking misuse.

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 cancels a voucher, with a clear flattened action. However, it also lists other actions (remove_invoice, remove_payment) that belong to sibling tools, causing minor confusion. The resource and operation are clear, but differentiation from similar tools is not explicit.

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

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

The description warns that operations are irreversible but provides no guidance on when to use this tool versus sibling delete tools (e.g., feegow_financial_delete_remove_invoice). No context on prerequisites or appropriate scenarios is given.

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

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

Annotations already set destructiveHint=true, and the description adds 'All are irreversible,' which reinforces the destructive nature. This adds minimal extra value beyond annotations, but there is no contradiction. No additional behavioral details (e.g., authentication, side effects) are disclosed.

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 extraneous information by listing multiple actions not relevant to this specific tool. The 'Flattened action' line helps, but the overall structure could be more focused. Some text is not strictly necessary.

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 two unannotated parameters, no output schema, and a destructive nature, the description is insufficient. It does not explain the input requirements, the effect of the action beyond irreversibility, or any expected outcomes. More detail is needed for safe and correct usage.

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

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

The input schema has two parameters (data, account) with 0% coverage (no descriptions in schema). The description does not mention or explain any parameters, leaving the agent without guidance on what values to provide. Given low schema coverage, the description should compensate, but it fails to do so.

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 tool name and description both indicate it removes an invoice. The description explicitly states 'remove_invoice: remove an invoice' and clarifies it is the flattened action. However, the description also lists other actions (remove_payment, cancel_voucher) which may cause confusion, though it does specify the current tool's action.

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

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

No explicit guidance on when to use this tool versus similar siblings like feegow_financial_delete_cancel_voucher or feegow_financial_delete_remove_payment. The description only says it is destructive and irreversible, but does not provide decision criteria or context.

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

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

Annotations already indicate destructiveHint=true. The description adds 'All are irreversible,' which is consistent but adds little beyond the annotation. The description also falsely implies the tool handles multiple action types, which misrepresents its 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 short but includes unnecessary information about other actions. The 'Flattened action' note adds clarity but the overall structure is muddled. It could be more concise by focusing solely on 'remove_payment'.

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 that this is a destructive operation with no output schema and low schema coverage, the description is severely lacking. It does not explain the parameters, the expected input format, or the consequences beyond 'irreversible'. The agent cannot reliably invoke this tool based on the description.

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 two parameters ('data' and 'account'), but the description provides no explanation of their meaning, format, or purpose. With 0% schema coverage, the description must compensate but fails to do so.

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

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

The description lists three actions (remove_invoice, remove_payment, cancel_voucher) but then states '[Flattened action: remove_payment]', creating ambiguity about what the tool actually does. The tool name suggests it is for removing payments only, yet the description broadens the scope incorrectly.

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 vs. sibling tools like 'feegow_financial_delete_cancel_voucher' or 'feegow_financial_delete_remove_invoice'. The description does not help the agent decide which action to invoke.

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 adds minimal behavioral context beyond stating 'Read financial data'. It mentions parameter format (JSON in data field) but omits details like response structure, pagination, or auth requirements.

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 but padded with a long list of unrelated actions and a confusing 'Flattened action' note. It should focus only on this tool, making the current content inefficient and hard to parse.

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

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

Given the lack of output schema and parameter descriptions, the description fails to provide essential context about what the tool returns, how to structure the data parameter, or what an invoice NFSE is. It is inadequate for effective agent 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% and the description only notes that all params are passed as JSON in the 'data' field. There is no explanation of what the 'data' or 'account' parameters represent or what JSON structure is expected for find_invoice_nfse, leaving the agent unable to construct valid 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 only says 'Read financial data in Feegow' and lists many actions including find_invoice_nfse. It does not clarify what an invoice NFSE is or what 'find' means, failing to distinguish from sibling tools like list_invoices. The verb is vague and the resource is not defined.

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 alternatives such as feegow_financial_list_invoices or other search tools. There are no prerequisites, exclusions, or context for appropriate 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe read. The description adds that parameters are passed as JSON in the 'data' field, which is a behavioral detail beyond annotations but not extensive. No contradictions.

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

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

The description is poorly structured: it mixes a generic purpose ('Read financial data'), a list of unrelated actions, a technical note about JSON passing, and a cryptic '[Flattened action: get_dmed]'. It is not concise or 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?

Given the lack of output schema and 0% parameter coverage, the description should provide rich context. However, it fails to explain what DMED is, what data the tool returns, or how to use the parameters effectively. The annotations provide safety info, but the tool's function remains unclear.

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 add meaning. It states 'All params are passed as JSON in the data field', which gives some context but does not explain what 'data' or 'account' parameters represent. The actual parameters remain mostly 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 starts with 'Read financial data in Feegow' but then lists many actions (list_suppliers, etc.), implying this tool does all of them. It does not specifically describe what 'get_dmed' does, leaving the purpose vague. The tool name suggests it retrieves a DMED, but the description offers no clarity.

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

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

No guidance is provided on when to use this tool versus sibling tools like feegow_financial_list_invoices or feegow_financial_search_supplier. The description does not differentiate this action from others, nor does it mention prerequisites or context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it reads financial data, which aligns, but provides no further behavioral details. No contradiction with annotations.

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

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

The description is short but includes an irrelevant list of actions that clutter the purpose. The key information ('[Flattened action: list_categories]') is in a comment-like line. Could be more concise 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, parameters are poorly explained, and there is no description of what the tool returns. For a listing tool, details on output format or pagination would be expected. The description leaves significant 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 compensate. It explains that params are passed as JSON in the 'data' field, which adds some meaning, but the 'account' parameter is unexplained. No details on required structure within the JSON.

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

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

The description opens with 'Read financial data in Feegow' and lists many actions, including list_categories, but does not clearly state that this tool specifically lists categories. The purpose is vague and fails to distinguish from sibling tools like feegow_financial_list_suppliers.

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. Among many financial list siblings, no context is given for when to choose list_categories over other list tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds only 'Read financial data', which is consistent but provides no additional behavioral context beyond annotations.

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

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

Wasteful: includes a long list of unrelated actions that are irrelevant for this specific tool. Could be concise by focusing only on list_cost_centers.

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 simple parameters, but description fails to specify what the tool returns or how to properly invoke it. Incomplete for agent decision-making.

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 two parameters (data, account) with 0% schema description coverage. Description does not explain their meaning or usage, leaving the agent without 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?

Description is generic: 'Read financial data in Feegow' and lists many actions including list_cost_centers, but does not explicitly state that this tool lists cost centers. Purpose is vague and nearly tautological.

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 vs alternatives. The description lumps multiple actions together without differentiation.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that parameters are passed as JSON in the 'data' field, which offers some behavioral insight, but lacks details like pagination or response format.

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

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

The description is part of a large block listing many actions, making it verbose and unfocused for this specific tool. It includes irrelevant actions and a flattened action label, wasting space.

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

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

The tool is simple (list credit card brands) but lacks output schema and parameter details. The description does not provide enough information for an agent to correctly invoke the tool, as the structure of the 'data' JSON is unknown.

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 but fails. It only states that 'All params are passed as JSON in the 'data' field' without specifying what fields go into that JSON. The 'account' parameter is also 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 tool name clearly indicates it lists credit card brands, but the description is generic ('Read financial data in Feegow') and lumps many actions together without specifying what this tool does individually.

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 the many sibling financial list tools (e.g., list_categories, list_cost_centers). The description does not differentiate or provide context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which adequately indicate safe read behavior. The description adds a minor behavioral detail ('All params are passed as JSON in the data field') but does not contradict annotations. No additional behavioral traits are disclosed, so a 3 is appropriate.

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

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

The description is not concise. It includes a long list of unrelated actions (e.g., list_suppliers, search_supplier) that are not relevant to this tool. The only relevant part is the final line '[Flattened action: list_current_accounts]', but the bulk of the description is clutter, wasting space and confusing the agent.

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 many sibling financial list tools and the lack of output schema, the description fails to provide complete context. It does not specify what data is returned (e.g., account IDs, names, balances) or how to interpret results. The agent cannot confidently use this tool without additional external knowledge.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It vaguely states that all params are passed as JSON in the 'data' field, but does not describe what 'data' or 'account' contain or how they affect the call. This provides almost no semantic value beyond the schema.

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

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

The description is vague and mixes multiple actions into one tool. It says 'Read financial data in Feegow' and lists many actions, but the specific action for this tool is 'list_current_accounts' as indicated only in the flattened action tag. This does not clearly state the tool's specific purpose and fails to distinguish it from sibling tools like feegow_financial_list_categories or feegow_financial_list_invoices.

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 alternatives. With many sibling financial list tools, the agent has no basis to choose this one over others. The description does not mention any preconditions, context, or scenarios 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe reading. The description adds 'Read financial data' but no further behavioral details 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 cluttered with a long list of unrelated actions that are not part of this tool. It could be a single sentence: 'List invoices. Params are passed as JSON in the data field.' Current version wastes space.

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 2-parameter read tool, the description should explain what list_invoices does (e.g., filters, pagination) and the meaning of parameters. It fails to provide this, leaving the agent underinformed.

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 says 'All params are passed as JSON in the data field', which clarifies the data parameter but not the account parameter. No explanation of expected JSON structure or parameter purpose.

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

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

The tool name 'feegow_financial_list_invoices' clearly indicates it lists invoices, but the description includes many other actions (list_suppliers, etc.) making the purpose ambiguous. The '[Flattened action: list_invoices]' helps, but the rest is confusing.

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 vs alternatives like feegow_financial_list_suppliers. The description does not differentiate it from siblings.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that 'All params are passed as JSON in the data field,' which is a useful behavioral hint about parameter encoding, but it does not explain the account parameter or return behavior. 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 includes a lengthy list of unrelated actions, which is noise for this specific tool. The core information about list_private_tables is buried and the listing wastes space. A concise, focused description would be more helpful.

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?

There is no output schema and the description lacks return value details or behavior for a list operation. Parameter meanings are vague, and the tool's expected response format is unaddressed, leaving the agent without crucial context.

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

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

Schema coverage is 0%, so the description must compensate. It says 'All params are passed as JSON in the data field,' implying the data string contains nested parameters, but it does not clarify the meaning or content of either the data or account parameters. This is insufficient for an agent to construct valid input.

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 'Read financial data in Feegow' which is generic, but the tool's name 'feegow_financial_list_private_tables' and the flattened action at the end 'list_private_tables' clarify its specific purpose. However, the inclusion of many other actions in the list causes ambiguity and detracts from the primary function.

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

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

No guidance is provided on when to use this tool versus sibling tools like list_suppliers or list_categories. The description lists many actions but does not differentiate this tool's role.

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, which align with the description's 'Read financial data'. The description adds no further behavioral context (e.g., what data is returned, pagination, authentication needs). Since annotations cover safety, the description meets minimum expectations but adds little value.

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

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

The description includes a long list of unrelated actions (list_suppliers, search_supplier, etc.) that bloat the text and distract from the tool's actual purpose. The key information ('list_sales') is buried at the end. This is not concise; it could be trimmed to focus on the current 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?

Despite annotations providing safety context, the description lacks details on how to use the parameters (data JSON format, account meaning) and what the tool returns. For a simple read operation, an agent needs guidance on input structure and expected output, both missing. The description is insufficient for confident invocation.

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

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

With schema description coverage at 0%, the description must compensate, but it only says 'All params are passed as JSON in the "data" field.' This hints at how to pass parameters but doesn't specify the required JSON structure for 'list_sales' (e.g., filters, date ranges). The 'account' parameter is unexplained. The added value is minimal.

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 a generic 'Read financial data in Feegow' and lists many actions, not focusing on listing sales. Only the final line '[Flattened action: list_sales]' clarifies the tool's specific purpose, but it doesn't explain what 'list_sales' does (e.g., returns sales records). The purpose is vague and relies heavily on the tool name.

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 feegow_financial_list_invoices or feegow_financial_list_vouchers. There is no mention of prerequisites, filters, or contexts where list_sales is appropriate. The description fails to help an agent choose this tool over alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds that params are passed as JSON in 'data' but creates confusion by listing unrelated actions. Does not clarify behavior specific to list_suppliers.

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 long and includes a list of actions not relevant to this tool. Could be shortened to 'List suppliers. Pass parameters as JSON in data field.' Wastes space.

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, no description of return format or filters. Tool is a simple list but description provides no useful context beyond the name.

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

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

Schema coverage is 0%, so description must compensate. Only says 'All params passed as JSON in data field' – no explanation of what params list_suppliers expects or what account is for. Adds no meaningful 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?

Description opens with generic 'Read financial data' instead of stating specific purpose. Lists many actions including list_suppliers, then notes flattening to list_suppliers, but does not clearly state what this tool does. Vague and tautological.

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 list_suppliers vs sibling tools like search_supplier. Does not specify prerequisites or context.

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

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

Annotations already indicate readOnlyHint=true. The description adds 'Read financial data,' which aligns but does not enhance 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 cluttered with a list of unrelated actions and a flattened action note. It is not front-loaded with the tool's main purpose.

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

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

With 2 parameters, no output schema, and the description adding almost no value, the tool is severely underdocumented for effective agent use.

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

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

The description notes that 'All params are passed as JSON in the data field,' but schema coverage is 0% and no specifics about the data format or account parameter are given.

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

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

The description lists many actions and says 'Read financial data,' but fails to specifically state that this tool lists transfers. The purpose is unclear and misleading.

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. Sibling tools like feegow_financial_list_invoices are similar, but no differentiation is provided.

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

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

Annotations already indicate readOnlyHint, destructiveHint, idempotentHint. The description adds minimal behavioral context beyond noting that params are passed as JSON in the 'data' field.

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 cluttered with an irrelevant list of other actions, making it verbose and unfocused. It should only describe the current 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?

For a tool listing vouchers with no output schema and many siblings, the description provides no information about return data, pagination, or what a voucher is.

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

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

Schema coverage is 0%, and the description does not explain what the 'data' or 'account' parameters represent. Saying 'all params are passed as JSON in the data field' is insufficient.

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

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

The description lists many actions including list_vouchers but does not clearly state that this tool specifically lists vouchers. It says 'Read financial data' and includes a generic list, making the purpose ambiguous.

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 given on when to use this tool vs similar list tools like feegow_financial_list_invoices. The description lacks 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 mark the tool as read-only and idempotent. The description adds that parameters are passed as JSON in the 'data' field, which is helpful, but it misrepresents the tool's scope by listing multiple unrelated actions, 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?

The description includes a long list of actions that are not relevant to this tool, making it cluttered. The key information ('Flattened action: search_supplier') is buried at the end. A concise description focused on the single action is needed.

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 fails to explain what 'search_supplier' does, what it searches by, or what it returns. With no output schema and low parameter documentation, the tool is poorly defined.

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 explains that all params are passed as JSON in the 'data' field, adding meaning beyond the schema. However, it does not specify the structure of that JSON for 'search_supplier', and the 'account' parameter is not explained.

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

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

The description is broad ('Read financial data in Feegow') and then lists many actions, but the tool name and flattened action indicate it is specifically for 'search_supplier'. This creates confusion about the tool's actual purpose and does not clearly state that it searches for suppliers.

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 alternatives like 'feegow_financial_list_suppliers'. The description lacks context on scenarios 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 indicate this is a write operation (readOnlyHint false). The description adds minimal extra context about what it does (associate account) but does not disclose side effects, permissions, or reversibility.

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

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

The description is verbose, listing many irrelevant actions for this specific tool. The essential information (associate_account) is buried at the end. Each sentence should earn its place, but most are noise.

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

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

No output schema and 0% schema coverage. The description fails to explain the format of 'data' and 'account', what 'association' means, or the result of the operation. Incomplete for safe 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?

Schema coverage is 0%, so description must compensate. It mentions parameters 'account' and 'association', but the schema only has 'data' and 'account'. This mismatch could confuse agents about the required 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 tool name and last line specify associate_account, and the description states 'associate financial account to patient'. However, the description is a generic list of many write actions, diluting focus. Sibling differentiation is weak; the agent may confuse this with other financial write 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 tells the agent to use feegow_financial_delete for destructive removals, providing a clear exclusion. But no guidance on when to use this specific associate_account tool versus other financial write tools like feegow_financial_write_pay_invoice.

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 (non-read-only, non-destructive). Description mentions 'write financial operations' but does not disclose specifics like authentication requirements, side effects of each action, or rate limits. For a tool with many actions, the lack of detail reduces transparency.

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

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

Description is a bullet list of actions but repeats information from the tool name and siblings. It is not concise for a single-purpose tool; it wastes space listing actions that have their own tools. The flattening note is confusing.

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 0% schema description coverage and no output schema, the description should provide complete guidance. It does not explain return values, how to invoke a specific action, or what the 'data' parameter expects. The tool is 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?

Schema has 0% description coverage. Parameters 'data' and 'account' are not explained. Description lists actions but does not link them to parameters or specify required format or structure of 'data'. This fails to add meaning beyond the bare schema.

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

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

Description lists multiple actions (associate_account, update_nfse, etc.) rather than focusing on create_invoice as the tool name implies. The '[Flattened action: create_invoice]' note suggests it is supposed to be for create_invoice, but the description is overbroad and contradicts the intended 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?

Only provides guidance to use feegow_financial_delete for destructive removals. Does not explain when to use this aggregate tool over the many dedicated sibling tools for individual actions (e.g., feegow_financial_write_create_invoice_by_appt, feegow_financial_write_pay_invoice).

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but description provides no additional behavioral context (e.g., side effects, idempotency). It merely repeats the action name without details like required permissions or effect on appointments.

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

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

The description is verbose, listing all actions from a parent tool. The flattened action note at the end is helpful, but the bulk is unnecessary and obscures the specific functionality.

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

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

Given the complexity of a write operation with two undocumented parameters, the description lacks details on input format, return values, or prerequisites. It provides only a minimal purpose statement.

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 2 parameters (data, account) with 0% coverage. Description does not explain what 'data' or 'account' mean, leaving the agent without guidance on how to structure 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 explicitly states 'create invoice from appointment' for the flattened action, which clearly defines the tool's purpose. However, the initial generic line 'Write financial operations in Feegow.' and the long list of actions add noise, slightly reducing clarity.

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

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

No explicit guidance on when to use this tool versus alternatives like feegow_financial_write_create_invoice. The list of actions implies differentiation by action name, but there is no direct comparison or condition 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?

Annotations indicate non-read-only and non-destructive, but the description adds no behavioral details like side effects, authorization, or error handling. The note about destructive removals references another tool, not this one.

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

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

The description is overly long, listing all possible actions despite being flattened to create_voucher. The key information is buried at the end, not 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?

Incomplete for a write operation: no details on request payload, expected behavior, or response format. Without output schema or parameter descriptions, the agent cannot invoke it correctly.

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

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

With 0% schema coverage, the description fails to explain what the 'data' and 'account' parameters represent. It only mentions actions but not the parameter structure or required format for create_voucher.

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

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

The description lists multiple actions with a note 'Flattened action: create_voucher', creating ambiguity about the tool's exact purpose. It appears to be a generic write tool but is presented for a single action, confusing the agent.

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 the many sibling write tools (e.g., feegow_financial_write_pay_invoice) or when not to use it. The only alternative mentioned is for destructive removals, which is unrelated.

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, which aligns with 'write financial operations'. But the description adds no additional behavioral details such as idempotency, side effects, or error conditions, relying solely on 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 bloated with a list of unrelated actions that are not part of this tool's function, making it verbose and confusing. The single relevant action (pay_booking) is buried, violating conciseness.

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

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

Given the mismatch between described parameters (6) and schema (2), and no output schema, the description is severely incomplete. The agent cannot determine input format, return structure, or how 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?

The input schema has two parameters (data and account) with 0% coverage, and the description lists six different parameters for pay_booking. There is no explanation of how the schema maps to these parameters, leaving the agent unable to correctly invoke the 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 lists multiple actions but the tool name and final note suggest it's for pay_booking only. This ambiguity obscures the tool's specific purpose, making it unclear whether it handles all listed actions or just one.

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

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

The description provides an exclusion for destructive actions, directing to another tool. However, it fails to clarify when to use this tool versus other financial write tools (e.g., feegow_financial_write_create_invoice) and the listed actions create confusion about scope.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds little beyond listing actions. It does not disclose side effects, permissions, or the nature of the pay_invoice operation (e.g., whether it changes invoice status irreversibly).

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 unnecessarily long, listing multiple irrelevant actions. The key information (pay_invoice) is buried. The ending note is confusing. It could be condensed to a single sentence focusing on the flattened action.

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

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

For a mutation tool with 2 unnamed parameters and no output schema, the description fails to explain how to use the parameters, the expected format, or the result. Agents lack necessary context to invoke 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?

Input schema has two parameters (data, account) with 0% description coverage. The description only mentions parameters for pay_booking, not for pay_invoice, and provides no context on what 'data' or 'account' should contain. No meaning added beyond the schema.

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

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

The description lists multiple actions (associate_account, update_nfse, pay_invoice, etc.) under a tool named for paying an invoice, causing confusion. The final note '[Flattened action: pay_invoice]' suggests it should be specific, but the description does not clearly state the tool's sole purpose of paying an invoice.

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 gives negative guidance ('For destructive removals use feegow_financial_delete'), but lacks explicit when-to-use or alternatives among the many sibling write tools. No context on triggers or prerequisites for using this tool over others.

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?

While the description mentions specific parameters for pay_booking, it does not explain how the 'data' parameter encodes actions or what the expected behavior for each action is. The input schema contradicts the described parameters, undermining trust.

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

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

The description is structured as a list of actions with brief details, which is clear for the actions themselves. However, the '[Flattened action: update_nfse]' note is extraneous and adds noise.

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

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

Given the lack of output schema and the complexity of actions, the description is severely incomplete. It does not explain how to specify actions via the 'data' parameter, handle errors, or interpret results. The proliferation of sibling tools suggests this composite is redundant.

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 zero description coverage, and the description's parameter hints (e.g., 'association' for associate_account) do not match the schema's parameters (only 'data' and 'account'). This mismatch creates confusion rather than clarity.

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

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

The description lists multiple actions under 'Write financial operations', but the tool name and the '[Flattened action: update_nfse]' note create confusion about its primary purpose. It fails to distinguish from sibling tools that cover the same individual actions, such as feegow_financial_write_create_invoice.

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 provides exclusion for destructive removals, but does not clarify when to use this composite tool versus the existing specialized write tools. The presence of sibling tools with identical action names makes the guidance misleading.

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 minimal info (readOnlyHint false, destructiveHint false). The description does not add behavioral details like idempotency, side effects, or return 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 a list of actions with a confusing final line '[Flattened action: update_voucher]'. It is not concise and lacks clear structure for a single 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?

The description fails to explain how to select an action or provide required fields for each. With no output schema and low parameter coverage, the agent lacks essential information.

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?

Both parameters (data, account) have 0% schema description coverage. The description does not explain their meaning, format, or how they map to the listed actions.

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

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

The description lists multiple actions (associate_account, update_nfse, etc.) but the tool name and final line indicate it is for 'update_voucher'. The purpose is ambiguous and conflicts with sibling tools like feegow_financial_write_create_voucher.

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 vs. sibling write tools. Only a mention to use feegow_financial_delete for destructive removals, but no context for selecting among the listed actions.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying that it lists all accepted plans, including sub-plans, and highlights batch execution via unidade_ids. 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?

Two sentences with no extraneous information. Front-loaded with purpose and action, then adds batch detail. Every sentence earns its place.

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

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

No output schema exists, and the description does not describe the response format (e.g., fields like plan name, sub-plans, ID). Also lacks error conditions or prerequisites. For a read tool with no schema guidance, this is insufficient.

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

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

With schema description coverage at 0%, the description should explain all parameters. It covers unidade_id and unidade_ids but does not mention the 'account' parameter. This omission limits the agent's ability to use the tool correctly.

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

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

The description clearly states it lists accepted insurance plans and sub-plans, using a specific verb-resource combination. It distinguishes from sibling tools like feegow_professional_insurance (professional-level) and feegow_procedure_insurance_list (procedure-level) by focusing on plans.

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 optional filter by unidade_id and bulk support, but does not explicitly state when to use this tool over alternatives, nor provide any exclusion criteria. Usage is implied but not fully guided.

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

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

Annotations already indicate readOnlyHint and idempotentHint; description adds return fields but doesn't disclose parameter filtering behavior or 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?

Single, short sentence with key information front-loaded; 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?

Adequate for a simple listing tool but missing parameter semantics and return structure (e.g., array or object). Not fully complete 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?

The sole optional parameter 'account' has no description in schema, and the description provides no explanation of its purpose or effect. Schema coverage is 0%, and description fails to compensate.

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 'List Feegow API connections (clinics) linked to this install' with specific fields id, label, name. Distinguishes from sibling tools that operate on patients, appointments, 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?

Implied usage context (listing accounts before using other feegow tools) but no explicit when-to-use or when-not-to-use guidance or alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds limited behavioral context. It does provide a date format hint (DD-MM-YYYY), but no details on pagination, rate limits, or return format.

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

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

Single, concise sentence that efficiently conveys the tool's action and key filter options. 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?

Despite low complexity, the description is incomplete due to the mismatch between listed filters and actual schema. No output schema exists, and the return structure is unmentioned.

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 lists filter parameters (bloqueio_id, date_start, etc.) that are not present in the input schema (which has 'data' and 'account'). It fails to explain the actual schema parameters and creates confusion with the mismatch.

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 lists schedule locks/blocks in Feegow and lists intended filter parameters. However, the input schema does not contain those parameters, which could confuse an agent. Purpose is specific 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?

No guidance on when to use this tool versus alternatives. Does not specify prerequisites or exclusions. The description only states what it does without 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 (readOnlyHint, idempotentHint, destructiveHint) indicate safe read-only operation. Description adds that the download URL is valid for 20 minutes, which is useful behavioral context beyond annotations.

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

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

The description is not concise; it lists three actions (list, get_file, search) and a cross-reference for creation, when only get_file is relevant. The flattened action note is helpful but the extra information distracts and makes the description longer than necessary.

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 annotations, the description lacks sufficient detail about parameters and return values. No output schema exists, so the description should explain what the tool returns, but it only mentions a download URL with expiry. Missing parameter semantics reduce completeness.

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

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

With 0% schema coverage, the description must explain parameters. It mentions 'lab_report_id' for get_file, but the schema has only undocumented 'data' and 'account' parameters. The description does not clarify what these parameters represent or how to use them.

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 is for reading medical/lab reports and specifies the get_file action (get download URL). However, it also includes unrelated actions (list, search) for the same tool, causing ambiguity about the tool's 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?

No explicit guidance on when to use this tool versus siblings like feegow_medical_report_list or feegow_medical_report_search. The description mentions 'For creating a report use feegow_medical_report_write', but does not differentiate between get_file and the other read actions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it is a read operation and mentions the 20-minute validity for get_file, but that pertains to a different action. For the actual list action, no additional behavioral details (e.g., pagination, limits) are given.

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 sized but includes redundant action descriptions and a note about flattening. It front-loads the purpose but could be streamlined to focus only on the list action, as indicated by 'Flattened action: list'.

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 a minimal input schema (2 unannotated parameters) and no output schema. The description fails to explain the actual parameters (data, account) and does not cover return values or behavior. It describes actions that are not fully supported, leaving the tool's usage unclear.

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 two unspecified parameters (data, account) with 0% schema description coverage. The description lists parameters for the actions (start_date, end_date, patient_id for list) that do not match the actual schema. Thus, the description provides no meaningful information about the tool's parameters.

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

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

The description states 'Read medical/lab reports (laudos) in Feegow' providing a clear verb and resource. It distinguishes from the creation tool by referencing feegow_medical_report_write. However, listing multiple actions (list, get_file, search) with a note 'Flattened action: list' creates ambiguity about the tool's actual 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 states 'For creating a report use feegow_medical_report_write', indicating when not to use this tool. Also implies that get_file and search have dedicated sibling tools (feegow_medical_report_get_file, feegow_medical_report_search), providing clear 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 readOnlyHint=true and destructiveHint=false, establishing the tool as safe and read-only. The description adds context about reading reports and a 20-minute URL validity for get_file, but the multiple-action list creates uncertainty about actual 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 includes extraneous actions and a cryptic '[Flattened action: search]' note. It is not concise; bullet points help structure but list details that may not belong to this tool, making it longer than necessary.

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 sparse schema (2 generic params, 0% coverage) and implied multi-action complexity, the description is highly incomplete. It does not clarify how to invoke each action via the provided schema, leaving the agent without actionable guidance.

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 only two parameters (data, account) in the schema, the description fails to explain their meaning or map them to the listed actions. It instead introduces unrelated parameters (start_date, end_date, etc.) that are not in the schema, adding confusion.

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

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

The description states 'Read medical/lab reports' but then lists three actions (list, get_file, search), contradicting the tool name 'search' and the final note '[Flattened action: search]'. This ambiguity obscures the tool's actual 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 suggests using feegow_medical_report_write for creating reports, but fails to clarify when to use this tool versus sibling tools like feegow_medical_report_list or feegow_medical_report_get_file, and gives no guidance on selecting among the three listed actions.

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

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

Annotations show destructiveHint=false and readOnlyHint=false. The description only says 'register' without disclosing side effects, permission requirements, or behavior such as whether it overwrites existing reports or requires specific authentication. No contradictions with annotations, but minimal added context.

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

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

The description is very short (one sentence plus parameter list) and front-loaded with the action. It is efficient but could benefit from a clearer structure separating required from optional, and it omits crucial details.

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

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

Given the tool has no output schema, 0% schema coverage, and no nested objects, the description is insufficient. It does not explain what the 'data' parameter should look like, what the output is, or any behavioral context (e.g., idempotency, error cases). The provided parameter hints do not cover all schema 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?

The schema has two parameters (data, account) with 0% description coverage. The description mentions fields (agendamento_id, laudo_base64) that presumably go inside the 'data' string, but does not explain the format or the 'account' parameter. This adds some meaning but is incomplete and potentially confusing as the described fields are not schema 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 'Register a new medical/lab report in Feegow' which clearly indicates the action (register) and resource (report). It distinguishes from sibling tools like feegow_medical_report_list (listing) and feegow_medical_report_search (searching). However, the mismatch between described parameters (agendamento_id, laudo_base64) and schema parameters (data, account) slightly reduces clarity.

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

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

The description lists required and optional parameters but provides no guidance on when to use this tool versus alternatives, nor any exclusions or context like prerequisites or post-conditions. There is no mention of 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 indicate readOnlyHint=true and destructiveHint=false, and the description aligns by stating 'Read patients'. It adds behavioral detail on return fields and bulk support, though no contradictions.

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

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

The description is well-organized with a bullet-like list of actions. It is somewhat verbose due to the 'Flattened action: get' note, but remains readable and front-loaded with key details.

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

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

Given 13 parameters and no output schema, the description covers main use cases and return information, but falls short on explaining all parameters. It is largely complete 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?

With 0% schema coverage, the description explains 10 of 13 parameters (offset, limit, telefone, cpf, origem_id, alterado_em, data_aniversario, paciente_id, paciente_ids, origem_ids) but misses photo, account, and programa_saude. This partial coverage earns a 3.

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

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

The description clearly states 'Read patients' and lists three distinct actions (list, get, search_cpf) with specific behaviors. It differentiates from sibling tools like feegow_patient_list and feegow_patient_search_cpf by bundling them into one tool.

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

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

The description provides sub-action guidance but does not explicitly contrast with siblings like feegow_patient_write_create or feegow_patient_list. It lacks when-not-to-use examples, leaving the agent to infer from context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it reads patients, supports bulk arrays, and returns specific fields. Does not contradict annotations, but adds only moderate value beyond them.

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

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

Structured with bullet points for actions, but includes redundant mention of return fields twice. Some extra verbiage like '[Flattened action: list]' may confuse. Could be trimmed without losing meaning.

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, 13 params, no param descriptions in schema. Description explains the three modes and bulk, but lacks guidance on parameter conflicts (e.g., using paciente_id and cpf together) and error behavior. 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 coverage 0%, so description must compensate. It explains some parameters: offset/limit for pagination, filter fields (telefone, cpf, etc.), CPF format, bulk arrays. However, it omits photo, account, programa_saude. Partially covers the 13 parameters, enough to guide basic usage.

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

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

Describes multiple read actions (list, get, search_cpf) clearly with specific verb and resource. However, does not differentiate from sibling tools like feegow_patient_get and feegow_patient_search_cpf, which likely serve the same single operations. Sibling differentiation is missing.

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: use list for paginated queries, get for full detail, search_cpf for CPF lookup. But no explicit guidelines on when to use this combined tool versus separate sibling tools. No exclusions or alternatives mentioned.

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