Feegow Clinic

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

Describes both modes of operation and their permanence, adding context beyond annotations (idempotentHint=true, destructiveHint=false). 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?

One dense paragraph that efficiently covers all necessary information. Could be slightly more structured, but no wasted words.

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

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

Covers both authentication flows and the parameter. Without an output schema, it does not describe return values, but the description is sufficient for an agent to use the tool correctly.

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

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

The single optional 'token' parameter is fully explained: it is a JWT from browser login, and the behavior without it is described. Schema coverage is 0%, so description compensates fully.

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

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

Clearly states the tool is for authentication, explaining the two methods (permanent config vs session token). Distinguishes itself from sibling tools like 'connect' by focusing on access token management.

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

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

Provides explicit instructions on when to use no arguments (to get a login link) vs. with a token (to complete login). Does not explicitly exclude other tools, but context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable detail about return behavior in two scenarios (authenticated vs missing credentials), including specific fields (authenticated, pending, connect_url). 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 clear, front-loaded sentences with no extraneous information. Every sentence provides essential context.

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-only status tool with no parameters and no output schema, the description fully explains what the tool returns in different states. No gaps given the tool's simplicity.

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

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

No parameters exist, so schema coverage is 100%. Description has no need to add parameter information; a baseline of 4 is appropriate.

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

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

The description clearly states the tool returns connection status and URLs, distinguishing between two states (all connected vs missing credentials). This differentiates it from siblings like 'authenticate' and 'marketplace'.

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?

Usage is implied for checking connection status, but no explicit guidance on when to use this vs. siblings like 'authenticate'. 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.

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, which align with the 'find' nature of available_schedule. The description adds no extra behavioral context beyond what annotations provide. No contradictions observed for the main action.

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, including five unrelated actions and extra parenthesis notes, making it twice as long as needed. Key information for available_schedule is buried. It could be cut to one or two sentences.

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

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

Given the schema-parameter mismatch and lack of output schema, the description fails to provide a complete picture. The agent cannot reliably use this tool because the required parameters are not in the schema. Critical context is missing.

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

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

The input schema only has two generic fields ('data', 'account') with 0% description coverage. The description lists detailed parameters (data_start, data_end, tipo, etc.) that do not appear in the schema. This mismatch creates confusion and undermines the agent's ability to invoke 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 mentions 'available_schedule' as one action to find time slots, but also lists many other actions (list, statuses, etc.) that are not related to the tool's name and purpose. This dilutes clarity. The core purpose is discernible but mixed with irrelevant information.

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

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

The description states required and optional parameters for the available_schedule action, offering some usage guidance. However, it does not explicitly differentiate this tool from siblings like feegow_appointment_list or others, nor does it specify 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 declare readOnlyHint=true, but the description includes 'queue_position: generate queue ticket' which is a write operation, creating a contradiction. The description fails to disclose that this tool is read-only despite including mutable actions. No additional behavioral context is added beyond the annotation 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 verbose and includes a long list of actions with parameter examples, but it is poorly structured for a single tool. It front-loads a generic statement, then dumps a detailed list that is more appropriate for multiple tools. Brevity and clarity are sacrificed for comprehensiveness that is not relevant.

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 (2 params) and lack of output schema, the description should explain how to use the tool and what the response looks like. It fails to define 'data' and 'account' or how they relate to the listed actions. The tool is about 'channels' but the description covers many other functions, leaving the agent confused about what this tool actually does.

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 zero description coverage. The description lists many parameters for each action (e.g., data_start, profissional_id) that are not part of the schema, but it never explains what 'data' or 'account' means or how they map to the actual API parameters. No value added for the 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 starts with 'Read appointments and scheduling data in Feegow' which is overly broad. It then lists multiple actions (list, statuses, motives, channels, available_schedule, queue_position) that correspond to different sibling tools. The tool name 'feegow_appointment_channels' suggests a specific function, but the description aggregates many unrelated actions, making the purpose unclear and contradictory to the 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?

The description does not differentiate when to use this tool versus sibling tools like feegow_appointment_list or feegow_appointment_statuses. In fact, it lists those actions as part of this tool, which is misleading. No guidance on when to use vs. alternatives is provided.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description includes actions like 'queue_position' (generate queue ticket) which may be a write operation. This contradicts the read-only annotation. The description does not add useful behavioral context beyond annotations and causes confusion.

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

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

The description is verbose and includes irrelevant actions from other tools. The 'Flattened action: list' note is an attempt to clarify but overall the structure is confusing. It is not concise and front-loads misleading 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 large number of sibling tools for appointment actions (available_schedule, channels, statuses, etc.), the description should clearly define this tool's scope. It fails to do so, mixing responsibilities and not aligning with the schema. The tool is incomplete for its intended purpose.

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 and account) with 0% description coverage. The description lists many parameters for the 'list' action (e.g., data_start, profissional_id) that are not in the schema, and it fails to explain the actual parameters. This mismatch misleads about how to use 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 states 'Read appointments and scheduling data' but lists multiple actions (statuses, motives, channels, available_schedule, queue_position) that are actually separate sibling tools. The final note 'Flattened action: list' suggests the tool is only for listing appointments, but the description conflates purposes, causing confusion.

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

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

No guidance is provided on when to use this tool versus sibling tools like feegow_appointment_statuses or feegow_appointment_available_schedule. The description implies it can perform multiple actions, which is misleading and provides no 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, consistent with a read operation. However, the description includes actions like 'queue_position' which generates a ticket (potentially not read-only), though the final note suggests only 'motives' is active. The internal inconsistency reduces transparency.

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

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

The description is lengthy and includes a bullet list of actions not specific to this tool, making it unhelpful. The structure is poor: a general opening, a list of unrelated actions, and a final note that contradicts the preceding content.

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

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

Despite low schema coverage (0%) and no output schema, the description does not clarify the behavior of the 'motives' action, the meaning of 'data' and 'account', or the expected output. It is incomplete for effective tool use.

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

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

The input schema has only two parameters ('data' and 'account') with no descriptions, and 0% schema description coverage. The description lists many parameters for various actions (e.g., data_start, profissional_id) that are not in the schema, causing a severe mismatch. No explanation is given 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 starts with a broad statement 'Read appointments and scheduling data in Feegow.', then lists multiple actions (list, statuses, motives, etc.), but the tool name is specifically 'feegow_appointment_motives' and ends with '[Flattened action: motives]'. This creates confusion about the tool's actual purpose, making it vague 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 is provided on when to use this tool versus its siblings (e.g., feegow_appointment_statuses, feegow_appointment_channels). The description includes actions not relevant to this tool, further obscuring its use case.

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 states 'generate queue ticket', which implies a write operation. This is a direct contradiction, and the description fails to clarify the tool's true 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 with multiple actions, but the final note '[Flattened action: queue_position]' suggests only one action applies. The irrelevant action list should be removed for 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?

The description fails to explain what the tool actually does, what the data and account parameters mean, or what output to expect. It is incomplete for a tool with a simple schema and 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 input schema has only two parameters (data, account) with 0% schema description coverage. The description lists many unrelated parameters (data_start, data_end, etc.) that are not part of the actual schema, misleading the agent about what is accepted.

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 indicates it is for queue position, but the description lists multiple other actions (list, statuses, etc.), diluting the purpose. It does not clearly state that this tool is only for queue_position, nor does it define that action precisely.

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

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

No guidance on when to use this tool versus sibling tools like feegow_appointment_list or feegow_appointment_available_schedule. The description omits context for selecting 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 declare readOnlyHint=true, but the description includes 'queue_position: generate queue ticket', which implies a write operation. This contradiction misrepresents the tool's behavior, and no additional behavioral context is provided.

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

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

The description is long and lists all sub-actions with parameter details, but it is not concise for a tool ostensibly focused on statuses. The structure is clear but overly verbose for the actual interface.

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 (2 string params), the description is overelaborate on actions not supported by the schema, and it lacks return value information (no output schema). It does not adequately describe how to use the actual 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?

Schema has 2 undocumented parameters (data, account) with 0% coverage. The description does not explain these, and its action-specific parameters (e.g., data_start) are not in the schema, adding 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 (list, statuses, motives, channels, available_schedule, queue_position) but the tool name is 'feegow_appointment_statuses', and it ends with '[Flattened action: statuses]', suggesting it should only cover statuses. This ambiguity undermines purpose 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 on when to use this tool versus its siblings (e.g., feegow_appointment_list, feegow_appointment_channels). The description does not specify constraints or prerequisites 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?

The description notes that cancel is 'reversible status flip — not a hard delete', which adds behavioral context beyond annotations. However, the description is cluttered with behaviors for other actions, reducing clarity for the cancel-specific use.

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, covering four distinct actions when only cancel is relevant. It lacks a focused structure, and the information about other actions is extraneous and wasteful.

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 with zero parameter descriptions and no output schema, the description should explain the 'data' and 'account' fields. Instead, it describes a different set of parameters, failing to provide necessary context for tool invocation.

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

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

The input schema has only two generic parameters ('data' and 'account') with no description, but the description lists many detailed parameters for cancel (e.g., agendamento_id, motivo_id) that do not appear in the schema. This mismatch is misleading and fails to explain 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 lists multiple actions (create, cancel, reschedule, update status) but the tool name and '[Flattened action: cancel]' indicate only cancel. This conflates purposes and doesn't clearly specify the tool's sole function, making it vague and potentially 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 explicit guidance on when to use this tool versus sibling tools (e.g., feegow_appointment_write_create). The description implies usage for cancel but includes instructions for other actions, which could lead to incorrect 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?

Description notes that cancel is a 'reversible status flip — not a hard delete', which is a useful behavioral detail. However, it lacks clarity on what actually happens (e.g., does create actually work? Does it require authentication?). The description's behavior claims are inconsistent with the limited input schema and sibling tools, reducing 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 overly long and repeats information that should be for separate tools. It could be condensed to focus on the create action. The structure is poor, with a confusing mix of actions and a trailing note that contradicts the main text.

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

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

The tool has high complexity (multiple actions described) but the schema provides minimal structure (2 params) and no output schema. The description does not explain the return value or how to interpret results. The mismatch between description and schema leaves the agent without a clear understanding of how to invoke the tool.

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

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

Input schema lists only 'data' and 'account' with no descriptions (0% coverage), while the description details many parameters like local_id, paciente_id, etc. The description adds meaning but is incompatible with the schema. This misalignment means the agent cannot rely on either the schema or description to understand actual required parameters.

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

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

Description lists multiple actions (create, cancel, reschedule, update status) but ends with '[Flattened action: create]', creating confusion. It fails to clearly state that this tool is only for creating appointments, especially given sibling tools for cancel, reschedule, and update status. The purpose is ambiguous 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 the separate write tools for cancel, reschedule, and update status. The description implies this tool handles all those actions, which contradicts the sibling tool set. This could lead to incorrect tool selection.

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

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

The description includes a behavioral note for cancel action ('reversible status flip'), adding value beyond annotations. But it lacks details on side effects, error handling, or concurrency for other actions. Annotations provide no extra information (readOnlyHint false, destructiveHint false).

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

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

The description is well-structured with action bullet points, but it is lengthy and includes some redundancy (e.g., repeating 'Optional:' for each action). A more concise format could improve clarity while retaining essential 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's complexity (multiple actions) and minimal schema (no param descriptions, no output schema), the description is incomplete. It omits critical information about the JSON wrapping of parameters, return values, and error responses. This gap severely impairs correct tool invocation.

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

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

The description lists many parameters per action but fails to explain that the actual input schema only has 'data' (string) and 'account'. The agent cannot determine that the listed parameters should be nested inside the 'data' JSON string. Schema coverage is 0%, so the description should compensate but does not.

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

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

The description clearly states the tool can create, cancel, reschedule, or update appointment statuses. It lists each action with required parameters, making the purpose evident. However, the tool name 'reschedule' is narrower than the description, causing slight confusion with sibling tools that are action-specific.

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

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

The description provides explicit parameter requirements per action, giving clear context for each operation. However, it does not guide when to use this combined tool versus the sibling tools (e.g., feegow_appointment_write_cancel) that are dedicated to single 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 provide basic safety info (not read-only, not destructive). The description adds that cancel is a reversible status flip, which is helpful. However, it fails to clarify that all action parameters must be passed as a JSON object in the 'data' string field—a critical behavioral detail missing from both schema and description.

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 with conflicting scope. The final line '[Flattened action: update_status]' is cryptic. Bullet points help structure, but the text is not efficiently front-loaded and includes unnecessary repetition.

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?

While the description covers required fields per action, it omits the data format, response details, error handling, and differentiation from sibling tools. For a complex tool with four actions and no output schema, this is insufficient for reliable selection and 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, so the description must compensate. It lists detailed fields for each action but does not map them to the actual schema parameters ('data' and 'account'). The agent receives no guidance on how to structure the input, making it impossible to invoke 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 lists four actions (create, cancel, reschedule, update_status) which clarifies the tool's capabilities, but the name 'feegow_appointment_write_update_status' and the final note '[Flattened action: update_status]' create confusion about the intended scope, especially given sibling tools for individual actions.

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 combined tool versus sibling tools (feegow_appointment_write_create, feegow_appointment_write_cancel, feegow_appointment_write_reschedule). The description does not specify use cases or exclusions, leaving the agent to infer without direction.

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 states 'Read benefit card data', which aligns with the annotations (readOnlyHint=true, destructiveHint=false). However, it adds no additional behavioral context such as rate limits or authentication requirements. The annotations already provide the safety profile, so the description is adequate but not enriching.

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 (list_plans action and a long list of filters that don't match the schema) and a confusing final note. It is not concise or well-structured, as it contains irrelevant details.

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

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

With only two undocumented parameters and no output schema, the description fails to explain what the tool returns or how to use the parameters. It does not provide a complete picture for an agent to successfully invoke the tool, especially given the mismatch between described 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 string parameters ('data' and 'account') with no descriptions, and the tool description does not explain their meaning or usage. The listed filters (page, perPage, etc.) are not reflected in the schema, so the description fails to add any parameter semantics, despite 0% schema description coverage.

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

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

The description claims the tool reads both contracts and plans, but the sibling tool 'feegow_benefit_card_list_plans' exists separately, and the note '[Flattened action: list_contracts]' suggests only list_contracts is active. This ambiguity makes the purpose unclear and potentially 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 explicit guidance is given on when to use this tool versus others. While 'Read benefit card data' implies a read operation, it does not differentiate from the sibling 'feegow_benefit_card_list_plans' or other read tools, and no exclusion criteria 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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds 'Read benefit card data' and '[Flattened action: list_plans]', which are consistent but offer minimal additional insight beyond the annotations.

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

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

The description is verbose, including irrelevant details about list_contracts and a flattened action note. It is not front-loaded with essential information about the tool's core purpose and parameter handling.

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

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

Given the absence of parameter descriptions, no output schema, and many sibling tools, the description fails to provide enough context for an agent to correctly invoke the tool. The disconnect between the described filter parameters and the actual schema parameters is a critical gap.

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

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

The input schema has two parameters ('data' and 'account') with 0% description coverage. The description lists many filter parameters for actions but does not explain how they map to the schema parameters, leaving the agent unable to determine what values 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 states it reads benefit card data, but includes actions for both list_contracts and list_plans, making it unclear whether the tool is for contracts, plans, or both. The tool name specifically targets listing plans, but the description dilutes this purpose and does not distinguish it 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 mentions filter parameters but does not specify conditions or exclusions for usage.

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

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

Annotations indicate it's a write operation (readOnlyHint=false) and not destructive. The description adds that the data body contains 'contract, recurrence, people arrays', but no details on side effects, success/failure indications, or idempotency. 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, listing multiple actions that may not all be active, and includes a confusing '[Flattened action: create_contract]' note. It could be more focused and structured.

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

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

With 2 parameters, 0% schema coverage, and no output schema, the description should provide comprehensive usage context. It lacks details on how to invoke the tool, expected response, error handling, or prerequisites. The tool is underspecified for a write operation.

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

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

The schema has 0% coverage; the description says 'Full body with contract, recurrence, people arrays' for the data parameter, adding a high-level structure but not format or required subfields. The account parameter remains unexplained. Does not compensate adequately for low schema coverage.

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

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

The description states the tool creates a benefit contract, with 'create_contract' in the title and flattened action. However, it also lists other actions (update_contract, create_plan, update_plan) which are not directly applicable, creating some confusion.

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

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

The description implies this tool is for contract creation but does not explicitly compare to sibling tools like feegow_benefit_card_write_create_plan or update variants. The context hints at its purpose but lacks clear when-to-use guidance.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds minimal behavioral context (e.g., 'create benefit plan' with fields) but does not explain side effects, authentication needs, or data persistence 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 relatively short but includes unnecessary details about other actions, making it less focused. The flattened action note helps slightly, but overall conciseness is adequate.

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 0% schema coverage, the description should explain how to structure the 'data' parameter and the role of 'account'. It fails to do so, leaving the agent uncertain about 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 coverage is 0%, so the description should explain parameters. It lists fields like 'name, membershipValue, recurrenceValue' but does not map them to the actual schema parameters 'data' and 'account'. The 'data' parameter's structure is not described.

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 multiple actions (create_contract, update_contract, create_plan, update_plan) even though the tool name and sibling tools indicate it is specifically for create_plan. This makes the purpose ambiguous and overlapping with other tools.

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

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

No guidance 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 lists actions but doesn't clarify that only create_plan is intended for 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 indicate write behavior (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds a list of actions but no behavioral details such as authentication requirements, error handling, or side effects.

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

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

The description is moderately concise but includes a mix of actions and a buried note about flattened action. The structure could be improved by focusing on the specific action and removing redundant items.

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, 2 untyped parameters) and lack of output schema, the description is insufficient. It does not explain how to specify the action, nor does it cover return values or error conditions.

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 parameters are just 'data' and 'account' strings. The description mentions structures for actions but does not explicitly map them to the 'data' parameter or clarify its expected format.

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 the 'Flattened action: update_contract' note suggest it is specifically for updating a contract. This contradiction makes the tool's 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 provided on when to use this tool versus siblings like feegow_benefit_card_write_create_contract or write_update_plan. The description does not exclude other actions or specify prerequisites.

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

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

Annotations indicate it's not read-only and not destructive, but the description adds little beyond 'write operations'. No details on error handling, side effects, idempotency, or required permissions. For a mutation tool with minimal annotation support, the description should disclose more 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 fairly concise with a bullet list of actions. However, the final line '[Flattened action: update_plan]' is confusing and unexplained. Overall, it's adequately sized but contains an odd statement that detracts from 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 complexity of multiple actions, no output schema, and overlapping sibling tools, the description is insufficient. It fails to clarify the tool's role relative to its siblings, does not describe the return value or error behavior, and lacks context on the data 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?

The schema has 0% description coverage, so the description must compensate. It provides some field names for each action (e.g., name, membershipValue for create_plan) but does not explain how to structure the 'data' string parameter, nor explains the 'account' parameter. The info adds some meaning but is incomplete.

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

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

The description lists multiple actions (create/update contract/plan) but the tool name 'write_update_plan' and flat action 'update_plan' suggest a narrower scope. The existence of sibling tools for create_plan, create_contract, and update_contract makes the purpose unclear. It does state the verb 'write' and resource 'benefit card operations', but the specificity is muddled.

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 tools that perform similar actions. For example, feegow_benefit_card_write_create_plan exists, but this tool also includes create_plan. No conditions, prerequisites, or exclusions are provided.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds that it reads billing guides and requires specific IDs, but does not disclose additional behavioral traits like authentication needs, rate limits, or side effects. With annotations covering safety, this is adequate but not exceptional.

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 very concise with two sentences, front-loading the purpose. However, the parameter list is not formatted for easy parsing, and the mismatch with schema reduces effectiveness.

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 only 2 parameters with 0% schema coverage, the description should fully explain usage. It fails to clarify how the listed parameters map to schema fields, and omits return value information, 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%, so description must compensate. However, description lists parameters (billing_type_id, insurance_id, billing) that do not match the schema properties ('data', 'account'), likely misleading the agent about how to invoke the tool. This is worse than no 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 clearly states the tool reads insurance billing guides (guias) in Feegow, with a specific verb and resource. It distinguishes from write siblings like feegow_billing_write_create and feegow_billing_write_edit.

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

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

Description implies the tool is for reading billing guides, but does not provide explicit when/when-not guidance or alternatives. The presence of write siblings gives context, but the description lacks direct usage 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 indicate non-readOnly and non-destructive, consistent with state modification. However, the description adds no extra behavioral context such as required permissions, side effects, or whether edit is actually supported (despite being mentioned). The '[Flattened action: create]' note is unclear.

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

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

The description is relatively concise but includes unnecessary details about edit for a create-focused tool. The sentence structure is clear but the '[Flattened action: create]' adds confusion.

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 sparse parameter descriptions, the description should provide more context on input format, output, and side effects. It fails to cover the actual parameters adequately and includes irrelevant edit instructions.

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 with no descriptions (0% coverage). The description mentions that 'data' should be a JSON string for create, and for edit it requires 'billing_id' etc., but those fields are not in the schema. This adds some meaning but is inconsistent and potentially misleading.

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 indicates 'create', but the description includes both create and edit actions, making it ambiguous. The presence of sibling 'feegow_billing_write_edit' suggests this should be for create only. The description's inclusion of edit details muddles the purpose.

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

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

No explicit guidance on when to use this tool versus alternatives like 'feegow_billing_write_edit' or 'feegow_billing'. No prerequisites or context for usage are provided.

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

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

Annotations show it is a write tool. Description adds that it edits SADT billing guides and lists required fields (billing_id, billing_type_id, attribute), but does not disclose side effects, prerequisites, or response behavior.

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

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

Description is relatively short and uses bullet points, but the mix of create and edit actions and the flattened action note create confusion. Acceptable but not optimal.

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

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

No output schema, low schema coverage, and two implied actions. Tool description lacks completeness for a mutation tool, especially regarding how to structure the data parameter for edit actions.

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

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

Schema has 2 parameters (data, account) with 0% coverage. Description mentions passing full data as JSON for create and required fields for edit, but these details are not aligned with the schema parameters. Insufficient to compensate for missing schema descriptions.

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

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

Description claims both create and edit actions, but the note says '[Flattened action: edit]' and there is a sibling feegow_billing_write_create for creation. This ambiguity misleads the agent about 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?

No guidance on when to use this tool vs alternatives (e.g., feegow_billing_write_create for creation). The description does not specify context or exclusions.

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

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

Annotations (readOnlyHint, idempotentHint) already indicate safe read behavior. The description adds minimal behavioral info beyond stating it's a read operation, and the dual-action description could mislead 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?

Description includes redundant information about list_units and a flattened action note, reducing clarity. It is not front-loaded with the main purpose and contains unnecessary detail.

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

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

For a tool with 3 undocumented parameters and no output schema, the description fails to explain return values, parameter formats, or behavior. The split between two actions adds confusion rather than completeness.

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

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

Schema coverage is 0%. Description only hints at 'endereco' and 'cep' for list_units, not for list_locals, and omits 'account'. No meaningful parameter documentation 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 states the tool lists rooms/locations ('list_locals') and contrasts it with listing units, so the verb and resource are identifiable. However, it also describes list_units, which is a sibling tool, causing potential confusion about the primary purpose.

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

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

No explicit guidance on when to use this tool vs alternatives. Mention of list_units implies a separate tool exists for units, but no direct comparison or usage context is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description confirms it is a read operation ('Read clinic company info') and adds that it lists units, but does not disclose any additional behavioral traits that the annotations do not 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 includes a redundant action list and a flattened action note, making it less concise. It could be streamlined to a single sentence without the extra detail about list_locals, which is handled by a separate 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 lacks completeness: it does not explain return values, parameter behavior beyond being optional, or how the output is structured. With no output schema and high parameter count, the description should provide more context.

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

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

With 0% schema description coverage, the description should compensate. It mentions two optional parameters (endereco, cep) but does not explain their meaning or the third parameter 'account'. The description adds minimal 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 states 'list all units (matriz + filiais)' which clearly identifies the verb and resource. The flattened action note resolves confusion about the included actions, and the tool name aligns with the purpose.

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

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

No guidance is provided on when to use this tool versus its siblings, such as feegow_company_list_locals. The description only lists optional parameters but does not indicate when they should be specified.

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

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. Description adds value through 'Bulk support: accepts unidade_ids for batched execution', which is a behavioral trait not captured in annotations. No contradictions.

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

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

Two concise sentences: first states purpose, second details key parameters and bulk capability. Front-loaded, no extraneous content. Efficient and clear.

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

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

No output schema, so description should explain return format, but does not. For a list tool, missing what fields are returned, pagination, etc. Also, description says 'requires ativo' but schema marks it optional with default, causing potential confusion.

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

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

Schema description coverage is 0%, so description compensates partially. Explains 'ativo' values (0=inactive, 1=active) and mentions optional unidade_id. However, the 'account' parameter is not described, and 'unidade_ids' bulk usage lacks detail. Adds meaning but not comprehensive.

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

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

Clearly states 'List employees in Feegow', a specific verb+resource. Distinguishes from sibling tools like feegow_patient_list or feegow_appointment_list by naming the entity. Parameters further clarify the 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?

No explicit guidance on when to use this tool versus alternatives. Description implies it lists employees, but does not compare to similar list tools or mention conditions for choosing it.

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

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

Annotations already indicate destructiveHint=true, and the description adds 'All are irreversible,' which reinforces the destructive nature. However, it does not explain what happens when cancelling a voucher (e.g., side effects, required state, return behavior). It adds minimal value beyond annotations.

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

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

The description is short but includes a confusing list of multiple actions followed by a flattening note. This redundancy and inconsistency detract from clarity and conciseness.

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

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

No output schema, no parameter descriptions, and limited behavioral context. The tool is destructive and has two undocumented parameters, yet the description fails to provide enough information for correct use. It is far from complete.

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

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

Input schema has two parameters ('data' and 'account') with no description coverage. The description does not explain their purpose, format, or expected values. This leaves the agent without critical information to invoke 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 states it performs destructive financial operations and lists three actions, but clarifies it's flattened to cancel_voucher. This causes confusion about whether this tool can also remove invoices or payments, especially since sibling tools exist for those. The core purpose is cancellable but muddied.

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 (e.g., separate remove_invoice and remove_payment tools). No prerequisites or context provided for when a voucher cancellation 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 already indicate destructiveHint=true. The description adds 'irreversible,' which is redundant with the annotation. No additional behavioral details are provided, such as required permissions, side effects on related records, or error states.

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

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

The description is somewhat concise but contains extraneous information about other actions. The key point ('remove an invoice') is present, but the structure could be improved by focusing solely on the remove_invoice action without listing unrelated operations.

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 (destructive with 2 parameters, no output schema), the description is woefully incomplete. It fails to explain what 'data' and 'account' are, what happens when the operation succeeds or fails, or any prerequisites. The agent lacks critical information to use the tool correctly.

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

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

Schema coverage is 0% with no descriptions for the 'data' and 'account' parameters. The description provides no explanation of what these parameters mean or how they should be used. The agent must guess that 'data' might contain the invoice identifier, but this is not stated.

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 removes an invoice via the 'remove_invoice' action, which is clear. However, it also lists other actions (remove_payment, cancel_voucher) that are not relevant to this specific tool, causing slight confusion. The purpose is specific enough to distinguish it from sibling tools like feegow_financial_delete_remove_payment and feegow_financial_delete_cancel_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 explicit guidance on when to use this tool versus alternatives. It mentions irreversibility but does not provide scenarios for use or when to choose a different tool (e.g., cancel_voucher instead). Agents must infer from the tool name and sibling list.

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

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

Annotations already declare destructiveHint=true. The description adds that all operations are irreversible, which provides minimal additional transparency. However, listing other actions not applicable to this tool may mislead the agent.

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 irrelevant multiple-action listing that wastes space. The structure could be improved by focusing only 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?

As a destructive tool with no output schema and undocumented parameters, the description is severely incomplete. It fails to explain the required input format, behavior, or expected results.

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

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

Schema coverage is 0% and the description does not explain what the 'data' and 'account' parameters mean. Without any parameter documentation, the agent cannot properly use 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 lists multiple actions (remove_invoice, remove_payment, cancel_voucher) but the flattened action is only remove_payment. This is confusing and does not clearly distinguish the tool from sibling tools like feegow_financial_delete_remove_invoice or feegow_financial_delete_cancel_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 versus alternatives. The description does not provide context for when to use remove_payment over other destructive operations.

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, destructiveHint, and idempotentHint. The description adds no behavioral context (e.g., what 'find' returns, pagination, required permissions).

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 confusing flattened action note. Not concise; 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?

With no output schema, no parameter descriptions, and a generic description, the tool definition is inadequate for an agent to use correctly.

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

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

Schema coverage is 0%, and the description does not explain the 'data' or 'account' parameters. No meaning is added beyond the bare schema.

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

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

The description is generic ('Read financial data in Feegow') and lists many actions without specifying what 'find_invoice_nfse' does. It fails to differentiate from sibling tools like list_invoices or 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?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which align with 'Read financial data'. However, the description does not add any behavioral context beyond the annotations, and the inclusion of a list of other actions is misleading. The tool's actual behavior (e.g., what 'get_dmed' returns) is not 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 poorly structured, starting with a generic 'Read financial data' then a bullet list of many actions not relevant to this tool. The note about 'Flattened action: get_dmed' suggests this is part of a larger pattern, but the description wastes space on irrelevant actions. It is not concise or well-organized.

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

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

Given the tool has 2 undocumented parameters, no output schema, and a vague description, it fails to provide sufficient context. The purpose of 'get_dmed' is unexplained, and the meaning of 'account' is unclear. The description 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?

Input schema has two parameters ('data' and 'account') with no descriptions, and schema description coverage is 0%. The description says 'All params are passed as JSON in the "data" field', which contradicts the schema where 'account' is a separate string. No meaningful guidance on parameter values or usage is provided.

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

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

The description states 'Read financial data' but then lists many unrelated actions like list_suppliers, list_categories, etc. The tool is specifically for 'get_dmed', but the description does not clarify what 'get_dmed' means or how it differs from other actions. The name indicates a specific function, but the description is generic and 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?

There is no guidance on when to use this tool versus alternatives. Among many sibling tools (e.g., feegow_financial_list_invoices, feegow_financial_search_supplier), no differentiation is provided. The description does not mention use cases, prerequisites, or exclusions.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds only that all params are passed as JSON in the 'data' field, which is marginally helpful but does not significantly expand behavioral understanding 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 (list_suppliers, etc.) that are irrelevant to this specific tool. This detracts from conciseness and creates confusion. The key information ('list_categories') is buried in a list and only clarified by the bracketed note. The description could be much shorter and more focused.

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 annotations present, the description should provide enough context to invoke the tool correctly. It lacks specificity about what 'list_categories' returns, what parameters are required inside the 'data' field, and how the 'account' parameter is used. The description is insufficient for an agent to reliably use this 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 0% description coverage, so the description must compensate. It mentions that all params are passed as JSON in the 'data' field, but does not explain the 'account' parameter or specify what keys/values are expected for the 'data' field when listing categories. The parameter semantics are largely 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' which is vague. It then lists multiple actions including list_categories, but does not clearly state that this tool specifically lists categories. The suffix '[Flattened action: list_categories]' hints at the specific action, but the overall description is confusing and fails to distinctly define the tool's purpose.

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

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

There is no guidance on when to use this tool versus its siblings (e.g., list_suppliers, list_cost_centers). The description lists many actions but does not explain that for listing categories, this is the correct tool. No when-to-use or when-not-to-use information 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?

The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description merely repeats 'Read financial data' without adding any behavioral context such as required authentication, response structure, or rate limits. It adds minimal value beyond the annotations.

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

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

The description is convoluted: it starts with a generic statement, lists many actions that are not relevant to this specific tool, includes a redundant note about JSON passing, and ends with an unclear bracketed note. It is not concise and front-loads irrelevant 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, two undocumented parameters, and numerous sibling tools, the description is grossly incomplete. It does not explain what the tool returns, the meaning of 'account', or how the 'data' field should be structured for an agent to successfully 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?

The description mentions 'All params are passed as JSON in the "data" field', which clarifies that the 'data' parameter is a JSON string, but it does not describe the expected structure for list_cost_centers. The 'account' parameter is not explained at all. With 0% schema coverage, the description fails to sufficiently 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?

The description states 'Read financial data in Feegow' and lists multiple actions including 'list_cost_centers', but it is unclear whether this tool is a generic reader or specifically for cost centers. The bracketed note '[Flattened action: list_cost_centers]' adds ambiguity rather than clarity, failing to concisely state that the tool retrieves a list of cost centers.

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_suppliers' or 'feegow_financial_list_categories'. The description does not differentiate the tool's purpose or specify prerequisites, making it impossible for an agent to select it appropriately.

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, idempotentHint=true, destructiveHint=false, and the description says 'Read financial data', which aligns. However, the description adds no further behavioral context (e.g., what data is returned, pagination, permissions). With annotations, the burden is lower, but the description still fails to provide any useful behavioral information beyond the annotations.

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

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

The description is cluttered with a long list of unrelated actions, which distracts from the tool's specific purpose. The essential 'flattened action' line is present, but the overall structure is poor. Every sentence should earn its place; here much is extraneous.

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

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

Given the tool's simplicity (2 optional params) and presence of annotations, the description is woefully incomplete. It fails to explain return values (no output schema), parameter semantics, or use case. An agent would have no idea what list_credit_card_brands actually does or how to use 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?

Schema description coverage is 0%, so the description must compensate. It only says 'All params are passed as JSON in the "data" field,' which does not explain what the 'data' parameter should contain for this specific action, nor does it describe the 'account' parameter. This is insufficient for an agent to understand how to invoke 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 does not specifically state what list_credit_card_brands does; it only generically says 'Read financial data' and lists many actions including this one. The name implies listing credit card brands, but the description fails to articulate the tool's purpose clearly or distinguish it from siblings like list_vouchers or list_sales.

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 usage guidelines are provided. The description does not mention when to use this tool, prerequisites, or alternatives. It simply lists actions without any contextual guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds a note about passing all params as JSON in the 'data' field, which is useful but minimal. No additional behavioral details (e.g., authentication, pagination, 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 short but includes a long list of unrelated actions that waste space. The relevant part (the flattened action) is buried. Could be much more concise and focused.

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 undocumented parameters, no output schema, and a complex financial domain, the description fails to explain what 'list_current_accounts' returns, how to filter, or any error conditions. It is severely incomplete for an AI 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 description coverage is 0%, and the description only mentions that params are passed as JSON in the 'data' field. It does not explain the meaning of 'data' or 'account' parameters. Lacks any semantic guidance beyond the parameter names.

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

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

The description starts with a generic 'Read financial data in Feegow' and then lists many actions including 'list_current_accounts'. It does not clearly state what the tool uniquely does. The purpose is implied by the action name but the description is cluttered with irrelevant actions, making it 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 on when to use this tool versus siblings like 'feegow_list_accounts' or other financial list tools. No mention of prerequisites or appropriate contexts.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description's 'Read financial data' adds no new behavioral context. There is no contradiction, but the description does not disclose additional traits beyond what annotations provide.

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

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

The description is cluttered: it lists 13 unrelated actions, repeats the tool name context, and uses brackets for metadata. It is not concise and mixes tool-level purpose with action enumeration.

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

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

Given no output schema and ambiguous parameter descriptions, the description fails to provide a complete picture of the tool's behavior, expected inputs, and return structure. It is inadequate for an agent to use correctly.

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

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

With 0% schema description coverage, the description must define parameter meanings. It only states 'All params are passed as JSON in the "data" field' but does not explain the 'data' structure or the 'account' parameter. This is insufficient for correct 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 lists many financial actions (e.g., list_suppliers, list_invoices) and then states '[Flattened action: list_invoices]', making it unclear whether this tool is a multi-purpose dispatcher or specifically for listing invoices. The purpose is vague and potentially 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 is provided on when to use this tool versus its many siblings (e.g., feegow_financial_list_suppliers, feegow_financial_list_vouchers). The description does not mention 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?

The description says 'Read financial data', which aligns with the readOnlyHint annotation. However, it adds no behavioral context beyond what annotations already convey (read-only, idempotent, non-destructive). Additional details about data access or limitations are missing.

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 but includes an unnecessary list of actions that do not pertain solely to this tool, adding noise. The note about flattened action is helpful but the structure could be more focused.

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, low schema coverage (0%), and many sibling tools, the description fails to provide sufficient context. It does not explain what private tables are, what data is returned, or how to use the parameters effectively, leaving the tool under-documented.

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

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

The description explains that all parameters are passed as JSON in the 'data' field, which adds meaning beyond the schema (which only specifies 'string' type). However, the 'account' parameter receives no explanation, and the schema coverage is 0%, so the description only 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?

Description states 'Read financial data in Feegow' and lists many actions including 'list_private_tables', but it does not clearly define what listing private tables entails or distinguish this tool from siblings like list_suppliers or list_categories. The purpose is vague and the tool's specific role is 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 alternatives. The description lists multiple actions without indicating which are performed by this specific tool, potentially confusing an agent about the tool's 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 already indicate readOnlyHint=true and idempotentHint=true. The description adds that all params are JSON in 'data', but no further behavioral details like side effects or return format. Adequate but minimal added 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, which is not concise and obscures the actual tool purpose. The key action is only revealed in the last line. Could be much shorter and focused.

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?

As a simple list operation with no output schema, the description should indicate what the tool returns (e.g., list of sales, fields included). It does not, leaving the agent without sufficient 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?

The input schema has two parameters with no descriptions (0% coverage). The description states 'All params are passed as JSON in the 'data' field,' which implies data is a JSON string but does not explain its structure or the 'account' parameter. Very little added meaning.

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

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

The description is generic, listing many actions rather than specifying what 'list_sales' does. The tool name gives some purpose, but the description conflates multiple functionalities, making it unclear what this specific tool is for.

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_financial_list_invoices' or 'feegow_financial_list_vouchers'. The description does not provide any 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 indicate read-only, non-destructive, idempotent. The description adds minimal behavioral context: it mentions that params are JSON in 'data' field but omits specifics like return format, pagination, or any side effects. Does not contradict annotations.

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

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

The description is cluttered with a long list of unrelated actions, which reduces conciseness. The relevant information is tucked at the end. Each sentence does not earn its place; much is irrelevant 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 no output schema and 0% parameter description, the tool is severely underdocumented. The description does not explain what the tool returns, how to construct the JSON data, or how it fits among siblings. 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 coverage is 0%, placing burden on description. Description only notes that params are passed as JSON in 'data' field, but does not describe the structure of that JSON or the purpose of the 'account' parameter. No enum or format details.

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 vague 'Read financial data' and lists many actions, only clarifying the specific action with a parenthetical '[Flattened action: list_suppliers]'. It does not clearly state that this tool exclusively lists suppliers, and the purpose is confused by the laundry list of unrelated actions.

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 like feegow_financial_search_supplier or other list tools. The description fails to differentiate context or provide any usage direction.

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 agent knows this is a safe read. The description adds 'Read financial data' which aligns but does not provide additional behavioral context beyond annotations.

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

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

The description includes a long list of unrelated actions, cluttering the purpose. The essential information about list_transfers is only in the final bracket. The structure is not focused or 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?

With no output schema and minimal parameter documentation, the description should provide details on return format or usage. It fails to compensate, leaving the agent without crucial context for a 2-parameter tool.

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

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

Schema coverage is 0%, and the description only adds that params are passed as JSON in the 'data' field. No explanation of the expected JSON structure for list_transfers or the purpose of the 'account' parameter.

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

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

The description lists many financial actions without specifying that this tool is specifically for listing transfers. The tool name suggests 'list_transfers', but the description is a generic list of actions, making the purpose vague and indistinguishable from siblings.

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

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

No guidance on when to use this tool versus siblings like list_suppliers or list_invoices. The description only says 'Read financial data' without providing any decision criteria or when-not-to-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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is clearly a safe read operation. The description adds the note about passing params as JSON in the 'data' field, which is useful but not critical. 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 cluttered with a long list of actions that are not relevant to this tool. It is not concise; a focused description would be more efficient. The note about the 'data' field is buried.

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 minimal parameter info, the description is incomplete. It does not explain what the response looks like or any filtering options. For a list operation, more details on usage and output are needed.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions that all params are passed as JSON in the 'data' field, which clarifies the data format, but it does not explain the 'account' parameter or what the JSON should contain. Inadequate for effective use.

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 generic, stating 'Read financial data' and listing many actions. The tool is specifically for listing vouchers, but this is not clearly highlighted. The flattened action at the end helps, but the overall description causes confusion about 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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools include many other list operations (e.g., list_invoices, list_suppliers), but the description does not differentiate or provide 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, idempotentHint, and destructiveHint. The description adds 'Read financial data' which aligns, but provides no additional behavioral details (e.g., rate limits, authentication needs) beyond the annotations.

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

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

The description is cluttered with a list of unrelated actions, making it unnecessarily long. It could be more concise by focusing solely on the search_supplier action.

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

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

With no output schema and many sibling tools, the description fails to explain the search functionality, return values, or how it differs from listing. The tool's behavior is inadequately specified for an AI agent.

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

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

Schema description coverage is 0%. The description notes that all params are passed as JSON in the 'data' field, which gives some meaning but does not specify the structure or required fields. The 'account' parameter is unexplained, 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 states it reads financial data and lists actions, then specifies 'Flattened action: search_supplier', which clarifies the tool's purpose. However, the inclusion of many other actions is confusing and detracts from 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 vs. sibling tools like feegow_financial_list_suppliers. The description does not specify prerequisites or context for use.

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

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

Annotations indicate a non-destructive write, but the description lists multiple actions with potentially different behaviors. It does not disclose the effect of the 'associate_account' action beyond a brief phrase, nor does it address rate limits, auth needs, or side effects.

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

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

The description is unnecessarily long due to listing many actions not relevant to this tool. It is not front-loaded with the essential purpose; instead, it starts with a generic statement and then a 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?

With 2 parameters (one required), no output schema, and many sibling tools, the description should provide enough context to use the tool correctly. It fails to explain how to invoke the associate_account action, what the parameters mean, or what the response looks like.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not explain the 'data' or 'account' parameters. The phrase 'account, association' in the action list is vague and does not map to 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 but the tool is specifically for 'associate_account' as indicated by the name and flattened action note. This mixing of actions confuses the agent about which tool to use, as separate tools exist for the other actions. The purpose is not clearly stated.

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

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

The description mentions using feegow_financial_delete for destructive removals, which is good, but it fails to differentiate from other write tools like feegow_financial_write_create_invoice. Listing those actions implies they can be performed by this tool, which is incorrect.

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 only provide readOnlyHint=false and destructiveHint=false. The description does not add behavioral context such as required permissions, data formats, idempotency, or side effects. With no annotations filling the gap, this is insufficient.

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 a list of multiple actions irrelevant to this specific tool. It should be concise and focused on create_invoice. The structure wastes space on unrelated operations.

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

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

Without an output schema and with poor parameter documentation, the description fails to provide a complete picture. It does not cover expected input format, error handling, or return values, making it inadequate for a write operation.

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

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

Schema coverage is 0% and the description does not explain the 'data' or 'account' parameters. While it lists per-action parameters, it does not map them to the schema, leaving the agent unable 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 is generic, listing multiple financial operations rather than specifying that this tool is for creating invoices. The name and flattened action note provide some clue, but the description is misleading and fails to clearly differentiate from sibling tools like feegow_financial_write_create_invoice_by_appt.

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. Only mentions using feegow_financial_delete for destructive operations, but does not compare with other write tools or specify prerequisites for create_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 it's not read-only and not destructive, but the description adds no behavioral context aside from the action list. The flat action 'create_invoice_by_appt' is not described in terms of side effects, idempotency, or required permissions. The multi-action list is misleading as it suggests the tool can perform several operations, contradicting the flattened action.

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 due to listing multiple actions, but the relevant part is a small subset. Important information is not front-loaded; the generic header and list obscure the specific action. The description should focus solely 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?

Given the tool has no output schema and only two undocumented parameters, the description should provide comprehensive context about input format, prerequisites, and expected results. It fails to do so, leaving the agent without enough information to invoke the tool correctly.

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

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

Schema coverage is 0% and the description does not explain what 'data' or 'account' parameters mean for the specific action. Without any parameter documentation, an agent cannot determine how to construct a valid request. This is a critical gap.

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

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

The description lists 'create_invoice_by_appt: create invoice from appointment' among many other actions, which clarifies the tool's specific purpose. However, the inclusion of multiple unrelated actions and a generic 'Write financial operations' header dilutes the focus and could confuse an agent about what this specific tool does.

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_financial_write_create_invoice'. The only hint is that destructive actions require a different tool, but that doesn't help distinguish among write operations. The agent is left to guess based on tool name.

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 and destructiveHint=false, but the description adds minimal behavioral context. It states 'Write financial operations' but does not explain side effects, such as what happens when creating a voucher or updating an invoice, beyond the listed actions.

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

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

The description is overly long with a list of multiple actions, most of which are irrelevant to the tool's core purpose (create_voucher). The flattened action note helps, but the clutter undermines conciseness and front-loading of 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 tool's complexity (multiple actions) and missing output schema, the description is severely incomplete. It lacks parameter details, return value information, and specific usage context for the create_voucher action, making it inadequate for an AI 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 description coverage is 0%, so the description must elucidate parameters. It fails to explain what 'data' and 'account' represent for the create_voucher action or any other action, leaving agents unable to correctly populate required fields.

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

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

The description lists multiple actions under 'Write financial operations in Feegow', but the tool name and flattened action specifically indicate 'create_voucher'. This creates ambiguity about the tool's primary purpose and does not distinguish it from sibling tools like 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 provides some guidance by noting that destructive removals should use feegow_financial_delete. However, it lacks explicit instructions on when to use this tool versus other write tools (e.g., feegow_financial_write_pay_invoice), leaving usage context incomplete.

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

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

Annotations indicate mutation (readOnlyHint=false) but no additional behavioral details. Description does not disclose idempotency, side effects, or required permissions for pay_booking. Minimal 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 overly long with a list of unrelated actions and their parameters. The essential pay_booking details are buried. Not front-loaded; the flattened action note should be primary but is at the end.

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 only 2 parameters but the description implies many more; no explanation of how to structure the 'data' parameter to include pay_booking fields. No output schema. Incomplete 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 coverage is 0% but description lists pay_booking parameters (bookingId, amount, etc.), providing some semantics. However, these are not mapped to the schema fields (data, account), and the inclusion of other actions' parameters adds confusion. Partially helpful but incomplete.

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

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

The tool name suggests pay_booking, but the description lists multiple financial actions (associate_account, update_nfse, etc.) without clarifying which action is performed. The flattened action note helps but is ambiguous. Purpose is not clearly 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?

The description only mentions when not to use this tool (for destructive removals, use feegow_financial_delete). No guidance on when to use pay_booking vs other write tools like pay_invoice. Lacks positive usage context.

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

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

The description states 'Write financial operations' and lists 'pay_invoice: pay an invoice,' but adds no behavioral details beyond what annotations already imply (write operation, non-idempotent, non-destructive). There is no disclosure of side effects, required permissions, or what the return value is. The annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds little transparency.

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

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

The description is overly long and includes a list of unrelated actions, making it confusing. The key information (paying an invoice) is not front-loaded; instead, it is buried after a generic introduction. The note about flattened action is helpful but the rest is clutter.

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

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

Given the tool's complexity (financial operation, no output schema, no param descriptions), the description is severely incomplete. It fails to specify required input format, behavior, or return structure. The agent cannot reliably use this tool based on the description alone.

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% schema description coverage. The description does not explain what 'data' or 'account' mean. It only lists parameter hints for other actions (like pay_booking) but not for pay_invoice itself, leaving the agent without guidance on how to structure the 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 the note '[Flattened action: pay_invoice]' indicate the purpose is to pay an invoice. However, the description mixes a general statement about writing financial operations and lists multiple actions (e.g., associate_account, update_nfse, create_invoice) that are not all relevant to this specific tool. The purpose is clear but buried within a list, and it does not differentiate from sibling tools like 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 provides minimal usage guidance. It mentions that for destructive removals one should use feegow_financial_delete, but it does not explain when to use this tool (paying an invoice) versus other write tools like feegow_financial_write_create_invoice or feegow_financial_write_pay_booking. There is no explicit 'use this tool when' statement.

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 indicates a write operation, consistent with readOnlyHint=false and destructiveHint=false, but lacks details about side effects, authentication needs, or response behavior.

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

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

The description is front-loaded but includes a long list of actions that may not apply, making it less concise. The structure is somewhat messy with a trailing 'Flattened action' note.

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 poor parameter documentation, the description fails to complete the picture. The actions listed do not align with the schema, leaving the agent without essential 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 2 parameters (data, account) with 0% description coverage. The description lists actions with different parameters but does not explain how they map to the schema, leaving the parameters completely unexplained.

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

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

The description lists multiple actions but the tool name 'update_nfse' suggests a specific function. The phrase 'Write financial operations' is vague, and the connection to the actual action is unclear due to the 'Flattened action' note and mismatch with the schema.

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

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

The description provides some guidance by noting that destructive removals should use feegow_financial_delete, but it does not differentiate this tool from other financial write siblings like feegow_financial_write_associate_account.

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

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

Annotations indicate it's not read-only and not destructive, consistent with write operations. However, the description provides no details on side effects, permissions, or what each action does beyond a brief label. The behavioral profile of each listed action is opaque.

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

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

The description is somewhat structured with a list of actions and a note, but it is verbose and includes many actions that may not all be relevant to the named tool. It lacks clarity and focus, which hinders quick understanding.

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

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

Given the tool's complexity (multiple actions), lack of output schema, and zero parameter descriptions, the description is severely incomplete. It does not specify how to invoke each action, what valid inputs are, or what the tool returns. The agent cannot reliably use this tool based on the description alone.

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% description coverage. The description lists actions with parenthetical parameter hints (e.g., account, association) but does not map them to the actual schema parameters or explain the structure of the 'data' string. No meaning is 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, etc.) under a tool named for update_voucher, and includes a note about a flattened action. This conflates many purposes into one tool, making it unclear whether the tool is general or specific. The name and description are inconsistent.

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 mentions that destructive removals should use a sibling tool. No guidance on when to use this tool vs the many other financial write tools (e.g., create_voucher, pay_invoice) or how to choose 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 declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context about batched execution via unidade_ids, which is beyond what annotations provide.

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

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

The description is two sentences long, front-loads the main purpose, and adds bulk support without any redundant information. Every sentence earns its place.

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

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

For a simple list tool with no output schema, the description covers essential aspects: listing plans/sub-plans, optional filter, and bulk support. It lacks details on response format or pagination, but is mostly complete.

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

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

With 0% schema description coverage, the description compensates by explaining unidade_id as an optional filter and unidade_ids for bulk, but fails to describe the 'account' parameter, leaving one parameter unexplained.

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

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

The description clearly states that the tool lists all accepted insurance plans and sub-plans in Feegow, with an optional filter. This distinguishes it from sibling tools like feegow_professional_insurance and feegow_benefit_card_list_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 filtering and bulk support but does not explicitly specify when to use this tool over alternatives or provide exclusions. Usage is straightforward for listing insurance plans.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description adds that the tool returns id, label, and name, but does not disclose potential pagination, rate limits, or other behavioral traits. It adds some value but is minimal 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 very short and front-loaded, but it omits parameter information. It is efficient but incomplete, earning a middle score.

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

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

For a tool with low complexity and no output schema, the description partially covers return fields but fails to document the optional 'account' parameter. It is not complete enough for an agent to use without guessing about the parameter's purpose.

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 one optional parameter 'account' with no description (0% coverage). The description does not mention or explain this parameter at all, failing to add meaning beyond the schema. Given low schema coverage, the description should compensate but does not.

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

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

The description uses the specific verb 'List' and clearly identifies the resource as 'Feegow API connections (clinics) linked to this install'. It also specifies the returned fields (id, label, name), making the purpose unambiguous. It distinguishes itself from sibling tools like feegow_company_list_units by focusing on accounts.

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

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

The description implies usage when you need to list available Feegow accounts, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The context is clear but lacks exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context (listing with filters) but presents filter parameters not present in the schema, potentially misleading an agent about accepted inputs. No information about pagination, response format, or side effects is provided.

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

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

The description is a single sentence of 17 words, which is concise. However, the mismatch between listed filters and schema forces the agent to reconcile conflicting information, reducing efficiency. The structure front-loads the purpose but fails to accurately represent the tool's interface.

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 listing tool with no output schema and poor parameter descriptions, the description is insufficient. It does not clarify the actual parameters (data and account) or how they relate to the intended filters. Without output schema, information about return values is absent, 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?

The input schema has two generic parameters ('data' and 'account') with no descriptions (0% coverage). The description lists different filter fields (bloqueio_id, date_start, etc.) that are not in the schema, creating a direct contradiction. This severely hinders correct parameter usage as the agent cannot align described intent with actual schema.

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

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

The description clearly states the action ('List') and resource ('schedule locks/blocks in Feegow'), establishing a specific verb+resource pair. It is distinct from sibling tools like feegow_appointment_list or feegow_employee. However, the listed filter parameters (bloqueio_id, date_start, etc.) do not match the input schema, creating confusion about the actual interface.

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. While there are no other lock-specific tools among siblings, the description does not clarify use cases or prerequisites, such as required authentication or context for filtering.

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 the URL is valid for 20 minutes, which is helpful. But no additional info on auth, rate limits, or error cases. Adequate but not exceptional.

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 includes extraneous information about list and search actions that are not part of this tool. This adds clutter and reduces conciseness. Could be trimmed to focus solely on get_file.

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 no parameter descriptions, the description is incomplete. It provides some behavioral info but fails to document the actual parameters or expected response. The extra actions mislead rather than complete.

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

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

Input schema has two parameters (data, account) with 0% description coverage. Description does not explain these parameters at all, instead mentioning irrelevant parameters from other actions. No value added beyond schema.

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

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

The description states it reads medical reports and gets a download URL, but it also lists list and search actions that are not part of this tool (flattened to get_file). This muddies the purpose and fails to clearly distinguish from sibling tools like feegow_medical_report_list and feegow_medical_report_search.

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

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

Some context provided (requires lab_report_id, URL valid 20 min) but no explicit when-to-use or alternatives. The misleading inclusion of list and search actions confuses usage guidance. Does not tell the agent when to use this vs list or search.

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, which the description's 'Read' aligns with. However, the description adds no additional behavioral context beyond what the annotations provide, such as missing prerequisite information or response behavior. The 20-minute validity note is for the get_file action, which is not part of this tool.

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

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

The description includes unnecessary details about other tools and actions, and ends with a cryptic note '[Flattened action: list]'. It is not front-loaded with the essential operation, and much of the text is wasted on alternative uses.

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 schema descriptions and output schema, the description must fully explain how to use the tool. It fails to map the actual parameters (data, account) to any functionality, and introduces phantom parameters. The tool cannot be correctly invoked based on this description alone.

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 contains two parameters ('data', 'account') with 0% description coverage. The description ignores these and instead mentions completely different required parameters (start_date, end_date, patient_id) for the list action, which do not appear in the schema. This is severely misleading and fails to explain 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 medical/lab reports (laudos) in Feegow', which is clear. However, it then lists multiple actions (list, get_file, search) that are actually separate sibling tools (e.g., feegow_medical_report_get_file, feegow_medical_report_search), creating confusion about the tool's exact scope.

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

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

The description provides a pointer to the creation tool (feegow_medical_report_write). But it fails to differentiate when to use this list tool versus the separate get_file and search tools, which are incorrectly included as actions. This could lead an agent to misuse the tool.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which align with the 'Read' claim. The description adds a behavioral detail about the get_file URL being valid for 20 minutes. However, the mismatch between described actions and the input schema undermines transparency, as it's unclear how the tool actually behaves.

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 with details but fails to align with the schema. The '[Flattened action: search]' note adds confusion. Several sentences address actions that do not match the tool's actual interface, making it wasteful.

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 (0%) and no output schema, the description should compensate but fails to do so. It does not explain how to use the tool for the listed actions, nor does it clarify the relationship between the tool and sibling tools. The description is incomplete for effective usage.

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

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

The input schema has two parameters, 'data' and 'account', with no descriptions (0% coverage). The description does not explain these parameters; instead, it mentions other parameters (start_date, end_date, etc.) that are not in the schema. This creates a severe disconnect, leaving the agent unable to understand how to invoke 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 states 'Read medical/lab reports (laudos) in Feegow', which gives a general purpose. However, it lists three actions (list, get_file, search) that are not reflected in the input schema, creating confusion about what the tool actually does. The name suggests it's for search, but the description expands to list and get_file, which are separate sibling tools.

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

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

The description mentions that for creating a report, use feegow_medical_report_write, but it does not provide guidance on when to use this search tool versus the sibling tools feegow_medical_report_list and feegow_medical_report_get_file. The actions described overlap with these siblings, 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 (readOnlyHint=false, destructiveHint=false) are present but minimal. The description only says 'Register', which implies creation, but does not explain side effects like whether it overwrites existing reports, requires authentication, or has any rate limits. No insights beyond the basic action.

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 (two sentences) and front-loads the purpose. However, the inaccuracy regarding parameters undermines conciseness, as it introduces confusion rather than clarity. It would be more concise if accurate.

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 write tool with no output schema and two undocumented parameters, the description fails to explain what the 'data' string should contain (e.g., base64-encoded content? JSON structure?) or what 'account' means. The reference to unrelated parameters makes it incomplete and unreliable.

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 shows two parameters (data and account) with no descriptions. The description references agendamento_id, laudo_base64, profissional_laudador, and procedimento_id, which are not in the schema. This mismatch severely misleads the agent about what parameters to provide, making the description counterproductive.

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 registers a medical/lab report in Feegow, using the verb 'register' and specifying the resource. It distinguishes from sibling tools like feegow_medical_report_get_file or feegow_medical_report_list by being a write operation.

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

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

No explicit guidance on when to use this tool vs alternatives. It lists required and optional parameters but does not explain any prerequisites or scenarios where another tool (e.g., feegow_medical_report_search) would be more 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral details: pagination, filtering, batch execution, and response fields. 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?

Description is front-loaded with purpose and uses bullet points for actions. Slightly verbose with 'Flattened action: get' but overall efficient.

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

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

Covers three operation modes, filtering, batch support, and return fields. Missing explanation for some parameters and the interaction between actions. No output schema, but return fields listed.

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

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

Schema coverage is 0% (no descriptions in schema), so description compensates by explaining most parameters (offset, limit, paciente_id, cpf, telefone, origem_id, alterado_em, data_aniversario, paciente_ids, origem_ids). However, photo, account, and programa_saude are left unexplained.

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

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

The description clearly states 'Read patients in Feegow Clinic' and enumerates three actions (list, get, search_cpf), distinguishing from sibling write tools and dedicated search 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?

Provides context for each action: list is paginated with filters, get by paciente_id, search_cpf by CPF. Also mentions bulk support. However, it does not explicitly clarify when to use this tool vs. the sibling feegow_patient_search_cpf, which may cause ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds return field details and mentions actions, but it does not disclose any behavioral traits beyond the annotations, and the mention of multiple actions with a '[Flattened action: list]' note adds ambiguity.

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

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

The description is structured with bullet-like actions but includes unnecessary details like '[Flattened action: list]' which is confusing. It could be more concise without losing essential information.

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

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

The description covers return fields and actions, but given 13 parameters and no output schema, it lacks details on bulk behavior, parameter interactions, and how the selected action is determined. It is adequate but not fully complete.

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

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

The description explains some parameters (telefone, cpf, origem_id, alterado_em, data_aniversario, paciente_id, paciente_ids, origem_ids) but omits others (photo, account, limit, offset, programa_saude). Given 0% schema coverage, the description partially compensates but is incomplete.

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

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

The description clearly states the tool reads patients in Feegow Clinic and lists actions (list, get, search_cpf). However, it does not differentiate from sibling tools like feegow_patient_get and feegow_patient_search_cpf, which may cause confusion.

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

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

The description implies usage through actions and mentions bulk support, but it does not provide explicit guidance on when to use this tool versus its siblings, nor does it mention prerequisites or exclusions.

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