GestãoClick

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

The description adds meaningful behavioral context beyond the annotations: the no-arg link flow, the session-only nature of passing a token, and the non-expiring behavior of the config header. It does not contradict the readOnly, destructive, or idempotent hints, but it does not cover expiration or failure 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 reasonably compact and front-loaded with the core auth flow. It contains a slightly awkward introductory phrase and some redundancy, but every sentence contributes useful operational 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 an authentication tool with no output schema and one optional parameter, the description explains the login link mode, session token mode, and a permanent alternative. It does not mention expiration, error cases, or returned status payloads, but these are not required by the exposed schema and annotations.

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

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

Despite having 0% schema description coverage, the description fully documents the optional token parameter: it identifies the JWT format, shows the exact invocation shape, and explains that omitting the token yields a login link. This more than compensates for the bare schema.

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

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

Clearly shows this is the authentication entry point for the MCP server, with a browser-login flow and a token-paste flow. It is much more specific than the tool name alone, though it does not explicitly contrast itself with the sibling 'connect' tool.

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

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

The description gives concretely actionable guidance: call with no arguments to receive a link, call with a pasted JWT for session-only login, and add the token as a header in the server config for a permanent connection. It also highlights the recommended option without being ambiguous.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable state-dependent behavior (authenticated flag, empty pending[], connect_url) that goes beyond the annotations, showing what the response looks like under different conditions.

Agents need to know what a tool does to the 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, front-loaded with the main purpose ('Returns connection status and URLs'). Every clause adds meaningful detail about output states, with no redundant filler.

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

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

The description covers the two primary states (all connected vs. missing credentials) and mentions key output fields (authenticated, pending[], connect_url). Without an output schema, it could have clarified what 'pending[]' contains or addressed partial-connection states, but it is sufficient for a simple read-only status 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 tool has zero parameters, so the schema coverage is trivially 100%. There is nothing for the description to add about parameter semantics, and the baseline score of 4 for no-parameter tools 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 'Returns connection status and URLs', a specific verb+resource that distinguishes this status-check tool from the sibling 'authenticate' which initiates connections. The title 'Connection Status' reinforces purpose.

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

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

The description provides conditional context ('When all providers are connected... When credentials are missing...') which tells the agent what to expect in different states. However, it doesn't explicitly name alternatives like 'authenticate' or state when not to use this tool.

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

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

The description adds '[write, altera dados]' which explicitly states the write behavior, consistent with readOnlyHint=false in annotations. However, this is largely redundant with the annotation, and no additional behavioral traits (e.g., irreversibility, side effects) are disclosed. 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 a single concise sentence with no wasted words. It is efficiently structured, front-loading the purpose and endpoint. However, while concise, it sacrifices necessary detail, making it minimally viable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 parameter descriptions, no output schema, and minimal behavioral context, the description is severely incomplete. It fails to explain what data is required to create a new record, the structure of 'atributos_cadastros', or any nuances of the request. This is inadequate for a creation tool in a large API.

Complex tools with many parameters or behaviors need more documentation. 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 (body, account) with no descriptions, and schema coverage is 0%. The description does not mention either parameter, providing no guidance on what body should contain or what account refers to. This is a critical gap for a creation tool.

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

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

The description clearly states the action 'Cadastrar' (create) and the resource 'Campos extras de cadastros' (extra fields of registrations), and provides the HTTP endpoint. This distinguishes it from sibling tools like _delete, _list, etc., and from other attribute type tools by naming the specific resource.

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

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

The description implies usage via the verb 'Cadastrar' and the context of a create operation, but it does not explicitly state when to use this vs. alternatives, nor any prerequisites or conditions. The name and endpoint provide implicit guidance, but no explicit when-to-use or when-not-to-use statements.

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

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

The description explicitly says 'Deletar' and 'DELETE', which are destructive operations, but annotations set destructiveHint=false, directly contradicting the described behavior. The 'write, altera dados' note and bulk support add some context, but the contradiction forces a score of 1.

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

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

The description is compact and front-loaded: purpose, endpoint, write behavior, and bulk support are conveyed in two short lines with no wasted words.

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

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

The description covers the core deletion action and batch capability, but there is no output schema and four parameters exist, of which 'body' and 'account' are unexplained. It also omits any note about irreversibility, prerequisites, or usage boundaries, leaving the tool incompletely specified.

Complex tools with many parameters or behaviors need more documentation. 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 clarifies 'id' via the endpoint path and 'ids' via bulk support. The 'body' and 'account' parameters remain entirely unexplained, so the description only partially compensates for the lack of schema-level parameter documentation.

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

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

The description clearly states the resource ('Campos extras de cadastros') and the action ('Deletar') with the exact HTTP DELETE endpoint. It is unambiguous and distinguishes this tool from the sibling create/get/list/update 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 intended use is implied by 'Deletar' and the DELETE method, and bulk support is mentioned for batched execution. However, it does not explicitly state when to prefer this over alternatives or provide any when-not-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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the bulk support behavior (accepts ids for batched execution) which is useful beyond annotations. No contradiction found.

Agents need to know what a tool does to the 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 with the main purpose. The bulk support note is a single additional sentence. No wasted words, though it could be slightly more structured with parameter explanations.

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

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

Given 4 parameters with 0% schema coverage and no output schema, the description is incomplete. It does not explain the 'query' and 'account' parameters, nor does it describe the return format or any pagination/limitations. For a GET tool with bulk support, more detail is needed for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'id' implicitly via the endpoint and 'ids' for bulk, but does not explain 'query' or 'account' parameters at all. The description adds minimal meaning beyond the schema for two of four parameters, leaving the other two unexplained.

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

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

The description states 'Campos extras de cadastros: Visualizar (GET /api/atributos_cadastros/{id})' which clearly indicates a GET operation to view extra fields of registrations. It distinguishes from siblings by the resource type (atributos_cadastros) and the GET verb, though it doesn't explicitly contrast with the list tool.

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

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

The description implies usage for viewing specific extra fields by ID, and mentions bulk support via 'ids'. However, it does not explicitly state when to use this vs. the list tool or other get tools for different resources, nor does it mention any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the HTTP method (GET) and endpoint path, which is useful but minimal. It does not disclose pagination, response format, or any side effects, but given the annotations, the description meets the baseline.

Agents need to know what a tool does to the 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 short sentence, front-loaded with the key purpose. It is concise and to the point, though it could be slightly more informative without becoming verbose.

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

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

The tool has 2 parameters with no schema descriptions, no output schema, and no usage guidance. The description is too sparse to fully support an agent in selecting and invoking the tool correctly, especially given the large number of similar sibling list tools.

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

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

Schema description coverage is 0%, and the description does not explain the 'query' or 'account' parameters. The agent has no idea what values to provide or whether they are optional. The description adds no meaning beyond the schema's bare property names, which is insufficient given the lack of schema descriptions.

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

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

The description states the tool lists extra fields for registrations (Campos extras de cadastros) and maps to GET /api/atributos_cadastros. It is clear about the resource and action, but it does not distinguish from sibling list tools like gestaoclick_atributos_financeiros_list or gestaoclick_atributos_produtos_list, which are similarly named and likely similar in purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for 'cadastros' specifically, nor does it explain the query and account parameters or any filtering capabilities. The agent must infer usage from the name alone.

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

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

The description adds 'write, altera dados' and mentions bulk support, which provide some context beyond the annotations that already indicate readOnlyHint=false. However, it does not elaborate on side effects, idempotency, or required authentication, which would be valuable for a mutation tool.

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

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

The description is extremely concise: two sentences that front-load the purpose and HTTP method, then highlight the bulk feature. Every word contributes value with no fluff or redundancy.

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

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

For a tool with four parameters and no output schema, the description is insufficient. It fails to explain the 'body' payload structure, the role of 'account', or what the response looks like, and the bulk support is only lightly mentioned without usage details.

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

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

With 0% schema description coverage, the description must compensate for parameter documentation, but it only mentions 'ids' for bulk execution. It says nothing about 'id', 'body', or 'account', leaving their meanings and formats unclear to the agent.

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

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

The description clearly states the tool edits extra fields of cadastros via PUT, with 'Editar' as the verb and 'atributos_cadastros' as the resource. It distinguishes this update tool from the sibling create/delete/get/list variants by specifying the action and HTTP method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 from the tool name and context—this is for editing existing records—but there is no explicit guidance on when to use this versus the create or delete tools. It does not mention prerequisites or exclusions, leaving the agent to infer that this is the update operation.

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

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

Annotations include readOnlyHint=false and destructiveHint=false, which indicate a write operation but not destructive. The description explicitly notes '[write, altera dados]', confirming data mutation. However, it does not disclose specifics like whether the operation is idempotent, required authentication, or potential side effects on related data. Given the annotations already convey write behavior, the description adds little beyond the endpoint.

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

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

The description is brief, with a single sentence and a bracket marker. It is front-loaded with the action and endpoint. It wastes no words, but it misses critical information about parameters and usage, so it is concise but incomplete. The structure is adequate for a simple tool, but the lack of detail reduces its 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?

The tool has two parameters with zero documentation in both schema and description, making it incomplete for correct invocation. There is no output schema, and the description does not explain what a successful creation returns. The simplicity of a POST endpoint is acknowledged, but the missing parameter semantics and response details leave significant gaps.

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

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

Schema coverage is 0%, meaning the description must explain the parameters. It does not mention 'body' or 'account' at all. The 'body' parameter is a string, but its format or content is undocumented. 'account' likely refers to an account identifier, but no detail is provided. The description fails to compensate for the lack of schema documentation.

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

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

The description states the action ('Cadastrar') and the endpoint (POST /api/atributos_financeiros), which clearly indicates creating financial extra fields. It is distinct from sibling operations (get/list/update/delete) by the verb 'Cadastrar'. However, it does not fully explain what 'atributos financeiros' are, making it somewhat vague for users unfamiliar with the domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the HTTP method and endpoint, which implies usage context. It lacks explicit guidance on when to use this tool versus alternatives (e.g., the update or list versions). No exclusions or prerequisites are mentioned, but the endpoint reference gives some direction. Sibling tools follow a clear create/read/update/delete pattern, so the action verb partly conveys 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?

Annotation Contradiction: the description says 'Deletar' (delete) and '[write, altera dados]' (changes data), implying a destructive mutation, while annotations declare destructiveHint=false. The description also does not disclose irreversibility, side effects, or response behavior beyond the raw DELETE HTTP verb.

Agents need to know what a tool does to the 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 short, front-loaded sentences. The first states the operation and resource; the second adds the only non-obvious usage detail (bulk support). No filler or 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?

For a delete tool with no output schema and minimal annotations, the description should explain parameter roles, expected outcomes, and safety aspects. It only covers the basic delete and bulk support, omitting `body`, `account`, and any error/response context; the annotation contradiction further reduces trust.

Complex tools with many parameters or behaviors need more documentation. 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 4 parameters with 0% description coverage. The description only clarifies that `ids` enables batch deletion and implies `id` is the single identifier. It leaves `body` and `account` completely unexplained, so the agent cannot determine their purpose.

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

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

The description clearly states the operation: 'Deletar' (delete) for 'Campos extras financeiros' and provides the explicit DELETE endpoint. The resource scope distinguishes it from sibling delete tools for cadastros, orcamentos, ordens_servicos, etc.

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

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

The description gives useful bulk execution guidance ('accepts ids for batched execution') and the delete verb implies when to use it. However, it does not explicitly contrast with create/update/list/get siblings or explain when to use single `id` versus `ids`.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond annotations by specifying the HTTP GET method and the bulk execution capability through the ids parameter. This provides concrete operational detail without contradicting the annotations.

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

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

The description is concise and well-structured: the first sentence states the verb, resource, and endpoint; the second adds the important bulk-support behavior. There is no filler or repetition of what the annotations already communicate.

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

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

For a simple read operation with strong safety annotations, the description is minimally adequate. However, it lacks explanation of query and account parameters, does not describe the return shape (no output schema exists), and gives no guidance on when to prefer list vs get. These gaps make it incomplete for fully reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only clarifies id via the endpoint placeholder and ids as a batched-execution list. The query and account parameters are completely unexplained, leaving the agent without enough guidance on how to populate them.

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

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

The description clearly states the tool's purpose: 'Visualizar' (view) with the specific endpoint GET /api/atributos_financeiros/{id}, identifying the resource as 'Campos extras financeiros'. It is immediately distinguishable from sibling tools because it explicitly indicates a single-resource GET operation, while siblings like list/create/delete/update are clearly different.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: use this tool to view a specific financial extra-fields record by ID, and mentions bulk support via ids. However, it does not explicitly contrast with alternatives such as gestaoclick_atributos_financeiros_list for listing all records, nor does it state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds no additional behavioral context such as pagination, sorting, or return format, which would be valuable for a list operation.

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

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

The description is extremely brief (one phrase), which is concise, but it lacks structure and substance. It is effectively a repetition of the tool name with the endpoint, so while there is no verbosity, the content is too thin to be considered well-structured.

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

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

Given the lack of an output schema, no parameter descriptions, and a large set of sibling tools with similar names, the description is insufficient. It does not help the agent understand expected inputs, outputs, or when to choose this tool over alternatives.

Complex tools with many parameters or behaviors need more documentation. 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 does not mention the 'query' or 'account' parameters at all. With no documentation in either the schema or the description, the agent has no idea what these parameters control.

Input schemas describe structure but not intent. Descriptions should explain 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 lists financial extra fields via GET, which is clear in verb and resource. However, it does not explain what 'atributos_financeiros' actually are or how they differ from other attribute types (e.g., cadastros, orcamentos), making it only minimally distinctive beyond the tool name.

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

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

No guidance is provided on when to use this tool versus the many other attribute list tools (e.g., gestaoclick_atributos_cadastros_list, gestaoclick_atributos_orcamentos_list). The description offers no context for selection criteria 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 a write operation and non-idempotent behavior; the description adds value by stating '[write, altera dados]' and explicitly calling out bulk execution via ids. It also provides the HTTP method PUT, giving useful behavioral context. 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 compact and front-loaded: it identifies the operation, endpoint, write nature, and bulk capability in two short lines. Every sentence carries information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 four parameters, no output schema, and no parameter documentation, the description is insufficient for fully correct invocation. The core update action is clear, but the payload/body parameter and account context are missing, limiting completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It gives some meaning to 'id' via the endpoint path and to 'ids' via the bulk-support note, but 'body' and 'account' remain completely unexplained, leaving the agent unable to construct a correct update payload.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Editar (PUT /api/atributos_financeiros/{id})', identifying both the verb and the resource. The 'financeiros' scope distinguishes it from the cadastros, orcamentos, produtos, vendas, and other sibling update 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 tool's purpose as an edit/update tool is implied by 'Editar' and the sibling naming, but there is no explicit guidance on when to use this vs. the create/delete/get/list alternatives. Bulk support is mentioned, but not in terms of when batched execution is preferred over single updates.

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

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

The description adds '[write, altera dados]' which merely echoes the readOnlyHint=false annotation. It provides no additional behavioral context such as authentication requirements, side effects, or what happens on duplicate creation. It does not contradict annotations, but adds minimal value beyond them.

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

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

The description is a single concise sentence with the purpose and endpoint, avoiding unnecessary words. It is front-loaded with the key info, though it could benefit from a bit more detail without becoming verbose.

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

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

Given the two parameters, no output schema, and minimal annotations, the description is severely incomplete. It does not explain the request body structure, account usage, or response format, and the 0% schema coverage leaves the agent without critical 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?

With 0% schema description coverage, the description should compensate for parameter meaning, but it only mentions the tool is for 'campos extras' (extra fields), offering no explanation of what 'body' or 'account' contain or how they are used. This is insufficient given the lack of schema documentation.

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

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

The description clearly states the tool creates extra fields for budgets (Cadastrar) and provides the endpoint. It specifies the resource (orçamentos) and action (create), distinguishing it from other atributos_*_create siblings by naming the specific entity.

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

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

The description implies usage for creating extra fields of budgets but provides no explicit guidance on when to use this tool versus alternatives, no exclusions, or context about prerequisites. The sibling tool list includes many other create tools, but no differentiation is given beyond the 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?

The description explicitly says 'Deletar', 'DELETE', and '[write, altera dados]', which are destructive/write semantics, while annotations set destructiveHint to false. This is a direct annotation contradiction and makes the tool's safety profile ambiguous.

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

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

The description is compact: two sentences that front-load the resource and operation, then add the bulk execution detail. No unnecessary filler.

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

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

For a delete tool with no output schema and multiple undocumented parameters, the description does not cover body/account semantics, response/error behavior, idempotency, or side effects. The destructiveHint mismatch further prevents the agent from invoking this tool confidently.

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

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

Schema description coverage is 0%, and the description only adds meaning for the ids parameter via bulk support. The id is implied from the endpoint, but body and account are left entirely unexplained, so parameter semantics remain 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 identifies the resource ('Campos extras de orçamentos') and the operation ('Deletar', 'DELETE /api/atributos_orcamentos/{id}'), and the name distinguishes it from create/get/list/update 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?

The only explicit usage guidance is batch support ('accepts ids for batched execution'). There is no guidance on when to use this instead of related tools, whether id and ids are mutually exclusive, or how account/body parameters should be set.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the bulk support behavior and the endpoint pattern, which is useful. However, it doesn't disclose what happens with invalid ids, response format, or any rate limits. Given the annotations cover the main behavioral traits, a 3 is appropriate.

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

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

The description is very concise: two short sentences. It front-loads the purpose and then adds the bulk support note. No wasted words. However, it could be slightly more structured by separating the purpose from the bulk note, but overall it's efficient.

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

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

Given the tool has 4 parameters with 0% schema coverage, no output schema, and no enums, the description is insufficient. It doesn't explain the 'query' and 'account' parameters, doesn't describe the return value, and doesn't provide context on how this tool fits with the list tool. The bulk support is mentioned but not detailed (e.g., how to format ids, limits). For a tool with this complexity, the description is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. The description mentions 'id' in the endpoint and 'ids' for bulk, but doesn't explain the 'query' and 'account' parameters at all. The description adds minimal meaning beyond the schema: it clarifies that 'id' is the primary identifier and 'ids' enables batch, but 'query' and 'account' remain unexplained. This is a significant 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 states 'Campos extras de orçamentos: Visualizar (GET /api/atributos_orcamentos/{id})' which clearly indicates this tool retrieves extra fields for budgets (orcamentos). It distinguishes from siblings by specifying the resource type (orcamentos) and the action (Visualizar/GET). However, it doesn't explicitly contrast with the list variant, but the verb 'Visualizar' and the endpoint pattern make the purpose clear.

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

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

The description mentions 'Bulk support: accepts ids for batched execution' which gives a hint about when to use this tool (for batch retrieval). However, it doesn't explicitly state when to use this over the list tool or other alternatives. The context is implied: use this to get specific extra fields by id, but no explicit exclusions or alternative guidance is provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the GET endpoint and resource context but does not disclose additional behaviors such as authentication requirements, pagination, or response format.

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

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

The description is a single concise sentence that front-loads the resource and operation, then appends the endpoint. Every part contributes meaning and there is no waste.

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

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

For a list operation with two unexplained optional parameters and no output schema, the description is too sparse. It omits parameter semantics, filtering or pagination details, and expected return structure, leaving the agent without enough information to use the tool effectively.

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

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

The schema defines two optional string parameters ('query' and 'account') with zero description coverage, and the description does not mention either parameter. An agent has no way to know what values are accepted, what 'query' filters, or how 'account' should be specified.

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

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

The description clearly identifies the resource ('Campos extras de orçamentos' – extra fields of budgets) and the operation ('Listar' – list), and includes the specific endpoint GET /api/atributos_orcamentos. The resource name distinguishes it from sibling list tools for other domains such as atributos_cadastros_list and orcamentos_list.

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

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

There is no guidance about when to use this tool versus alternatives like get, create, update, or even the regular orcamentos_list endpoint. The only usage signal is the verb 'Listar', but no context 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?

The description explicitly states '[write, altera dados]' and the PUT method, reinforcing that this tool mutates data, which aligns with readOnlyHint=false. It also discloses bulk execution via 'accepts ids for batched execution', a behavior not captured in annotations. It does not describe response behavior, but annotations cover the safety profile sufficiently.

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

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

The description is brief and front-loaded: it names the resource, operation, HTTP method, and bulk capability in two sentences without unnecessary filler. Every sentence adds useful information.

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

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

Given the tool has 4 parameters, no output schema, and no per-parameter documentation, the description is too sparse. It does not explain what 'body' should contain, what 'account' means, how the bulk mode interacts with 'id' and 'ids', 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%, and the description only adds meaning for 'id' and 'ids' via the endpoint and bulk note. The 'body' and 'account' parameters remain entirely unexplained, leaving the agent without enough semantic information to construct a correct request.

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

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

The description clearly identifies the operation as 'Editar' (edit) for 'Campos extras de orçamentos' and provides the exact endpoint PUT /api/atributos_orcamentos/{id}. This distinguishes it from sibling update tools like gestaoclick_orcamentos_update by specifying that it targets extra budget attributes.

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

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

The description mentions bulk support and the resource context, but it gives no explicit guidance on when to choose this tool over alternatives, nor does it mention prerequisites, exclusions, or conditions for batched vs single updates. Usage context is only implied.

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, so the description's mention of '[write, altera dados]' is redundant. It does add the endpoint, which is useful, but it does not disclose other behavioral aspects like error handling, idempotency (already in annotations as false), or effects on existing data beyond the write nature. Minimal added 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 a single concise sentence with a bracketed tag, front-loading the action and resource. It contains no unnecessary words and is appropriately brief for a straightforward create operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 two parameters, no output schema, and only basic annotations, the description is incomplete. It covers the purpose and endpoint but omits parameter semantics and any guidance on successful execution or prerequisites. The agent would have to infer the body structure from the endpoint alone, which is insufficient for reliable invocation.

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

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

Schema description coverage is 0% and the description does not explain the two parameters (body, account) at all. The endpoint hints that body is the POST payload, but there is no guidance on its format or content. The description fails to compensate for the lack of schema documentation, leaving the agent without critical parameter information.

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

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

The description clearly states the action ('Cadastrar' - register/create) and the resource ('Campos extras ordens serviço' - extra fields for service orders), and includes the specific endpoint. This distinguishes it from other create tools in the sibling set which target different entities (e.g., clientes, produtos).

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

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

The description implies usage for creating extra fields on service orders, and the sibling tools make alternative targets obvious. However, it does not explicitly state when to use this versus other create tools, nor does it mention any exclusions or prerequisites. The context is clear but not fully explicit.

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

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

The description includes '[write, altera dados]' indicating it modifies data, which is useful. Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description adds the write nature. It does not disclose potential side effects, irreversibility, or permission requirements beyond that.

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

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

The description is concise, with two sentences. It front-loads the main purpose and includes a note on bulk support. No wasted words, though it could be slightly more structured.

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

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

Given the tool has 4 parameters, no output schema, and no parameter descriptions, the description is insufficient. It does not explain the 'body' or 'account' parameters, nor does it clarify the relationship between 'id' and 'ids'. The bulk support note is helpful but incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'ids' for bulk support but does not explain the 'id', 'body', or 'account' parameters. The description adds minimal meaning beyond the schema, leaving the agent to infer the purpose of each 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 clearly states the tool deletes extra fields for service orders via DELETE /api/atributos_ordens_servicos/{id}. It distinguishes from siblings by specifying the resource type (ordens_servicos) and the delete action, though it doesn't explicitly contrast with other delete 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 bulk support with ids, implying when to use it for batched deletion. However, it does not provide explicit guidance on when to use this tool versus alternatives, such as when to use the update or create tools for the same resource.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the bulk execution behavior via the 'ids' parameter, which is useful but doesn't disclose error handling, authentication needs, or response format. Since annotations cover the core traits, a score of 3 is fair.

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

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

The description is extremely concise, with just two sentences. It front-loads the purpose and adds the bulk support note without waste. However, it might be too brief, as it omits essential parameter details, but for what it covers, it is well-structured and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 4 parameters, no output schema, and minimal parameter descriptions. The description only partially explains the 'ids' parameter and leaves 'query' and 'account' undefined. It also doesn't describe what the return value looks like or any error conditions. Given the moderate complexity and lack of schema coverage, this is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies the 'ids' parameter for batch support; 'id' is implicit from the endpoint, but 'query' and 'account' remain unexplained. This leaves significant gaps in understanding all parameters, so a score of 2 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 action ('Visualizar' - View) and the resource ('Campos extras ordens serviço'), matching the GET endpoint. It distinguishes from sibling tools by naming the specific resource type (ordens_servicos) and the operation (get vs list/create/update/delete). Though the sibling tools are numerous, this description unambiguously identifies its purpose.

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

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

The description provides a hint about bulk support ('accepts ids for batched execution') but does not explicitly state when to use this tool versus the list alternative or other tools. No exclusions are given, but the behavior is clear enough for a GET operation. More explicit guidance, such as 'use this to fetch specific extra fields by id, not for listing all', would improve it.

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

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

The description does not contradict the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) and correctly implies a read-only GET operation. However, it adds little behavioral context beyond the annotations, such as pagination behavior, response shape, or whether query/account affect the returned list.

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

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

The description is a single, front-loaded sentence with no redundant filler. It efficiently states the resource and the HTTP verb, though it is concise to the point of being under-specified in other areas.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 is enough to recognize the tool as a list operation for extra fields of service orders, and the annotations cover the safety profile. However, with no output schema or parameter semantics, the description is only minimally complete for guiding correct invocation and result interpretation.

Complex tools with many parameters or behaviors need more documentation. 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 but 0% schema description coverage, and the tool description does not explain the meaning of 'query' or 'account' or how they affect the listing. With no parameter-level documentation in the schema, the description fails to compensate for that gap.

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

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

The description clearly identifies the action ('Listar') and the resource ('Campos extras ordens serviço' via GET /api/atributos_ordens_servicos), which distinguishes it from get/create/update/delete siblings for the same entity. It is clear and minimally differentiated, though it does not explicitly state what 'campos extras' represent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 about when to use this list tool versus the sibling list tools or the get/create/update/delete variants. The 'Listar' label implies a listing action, but no exclusions, prerequisites, or alternative-tool suggestions are provided.

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

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

The description explicitly notes '[write, altera dados]', which aligns with readOnlyHint=false and adds a clear write-behavior signal. It also discloses bulk support via ids. However, it does not describe effects, response behavior, or any side effects beyond the annotation-implied write nature.

Agents need to know what a tool does to the 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 with the endpoint and write intent. The bulk-support note is a useful addition. It earns a high score for conciseness, though it sacrifices some completeness.

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

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

Given 4 parameters, no output schema, and sparse annotations, the description is incomplete. It covers purpose and bulk support but omits parameter semantics for body/account, response details, and any prerequisite or error context, leaving significant gaps for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'ids' enables batched execution, but it does not clarify the meaning or format of 'id', 'body', or 'account'. This leaves most parameters under-specified for an agent.

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

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

The description clearly states the tool edits 'Campos extras ordens serviço' via PUT /api/atributos_ordens_servicos/{id}, using the verb 'Editar' and naming the resource. It is specific enough to distinguish from sibling create/delete/get/list tools, though it does not explicitly contrast with other update 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 explicit guidance is given about when to use this tool versus alternatives. The phrase 'Editar' implies updating, and 'Bulk support' hints at batch usage, but there are no conditions, exclusions, or references to sibling update tools.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) indicate this is a write operation, which the description's '[write, altera dados]' tag reinforces. However, the description does not add behavioral details such as whether existing extra fields are overwritten, how IDs are generated, or error handling. The tag is redundant with the annotations, providing minimal additional 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 brief and front-loaded with the core purpose and endpoint. The '[write, altera dados]' tag is concise, though it adds little beyond the annotations. It avoids unnecessary fluff and is easy to scan.

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

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

With no output schema and only two parameters that lack descriptions, the description is incomplete for an agent to use the tool correctly. It does not explain how to structure the request body, what fields are required, or what the response looks like. The write nature is acknowledged, but practical usage details are 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 lists only 'body' (string) and 'account' (string) with no description. Schema description coverage is 0%, so the description must compensate, but it only mentions the endpoint and operation. It does not explain what 'body' should contain (e.g., JSON structure for product extra fields) or what 'account' represents (likely an account identifier). This is a significant gap.

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

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

The description clearly identifies the action as 'Cadastrar' (create) for 'Campos extras de produtos' (extra fields for products) and specifies the endpoint 'POST /api/atributos_produtos'. This distinguishes it from sibling tools that handle other entities or operations, though it could be more explicit about what 'produtos' refers to in context.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not differentiate from other '_create' siblings beyond the product entity, nor does it mention any preconditions or typical scenarios. The sibling tools list shows multiple create operations, but no contextual cues are given.

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

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

The description includes '[write, altera dados]' indicating the tool modifies data, which is helpful since the destructiveHint is false. It also discloses bulk support (accepts ids), adding behavioral context beyond the annotations. However, lacks details on irreversibility or consequences of deletion, but with annotations lacking destructiveHint, this is still valuable.

Agents need to know what a tool does to the 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: two lines covering purpose, endpoint, and bulk support. It is appropriately short, though could add a brief note on the 'account' parameter. No waste words overall.

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

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

For a delete tool with no output schema and 4 parameters, the description covers the core action and bulk capability, but leaves gaps: no mention of how 'id' vs 'ids' relate (mutually exclusive?), no detail on 'body' or 'account', and no explanation of response. Given the tool's simplicity, it's adequate but not 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 input schema has 4 parameters with 0% description coverage, so the description needs to compensate. It mentions 'ids' for bulk and implies 'id' from the endpoint, but does not explain the purpose of 'body' or 'account'. Provide insufficient detail for the parameters, especially given no 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?

The description clearly states it deletes extra product fields via DELETE /api/atributos_produtos/{id}, and includes '[write, altera dados]' indicating modification. It distinguishes from sibling tools by specifying the resource (produtos) and operation (delete), though the title already conveys this.

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

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

It mentions bulk support with IDs, implying usage when multiple entries need deletion, but does not explicitly contrast with alternatives (e.g., 'use update to change fields') or specify when not to use. The endpoint and write intent give some context, but there's no clear when-to-use guidance beyond the operation itself.

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 fully cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). Description adds the endpoint and bulk execution behavior, which is useful context. Description 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?

Two compact lines, front-loaded with the core purpose and endpoint. Every sentence adds value with no filler or redundancy.

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

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

For a simple GET tool with strong annotations this is mostly adequate, but query and account parameters are undocumented and no output format is described. The bulk support mention adds value but does not cover all 4 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 description coverage is 0%, so the description must compensate. It only explains ids (bulk) and implicitly id (URL path). The query and account parameters receive zero explanation, leaving their purpose and usage unclear.

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

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

Clear verb 'Visualizar' + resource 'Campos extras de produtos' with exact endpoint GET /api/atributos_produtos/{id}. Distinguishes from siblings like gestaoclick_produtos_get by specifying it handles extra product fields, not core product data.

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

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

Indicates it's for viewing extra product fields and mentions bulk support via ids, but does not explicitly state when to use this vs gestaoclick_produtos_get or sibling *_get tools, nor provide exclusions or alternative 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 establish read-only, idempotent, non-destructive behavior, and the description is consistent with those by showing GET. It adds the concrete endpoint but does not disclose pagination, response shape, or any account/context requirements beyond what annotations already imply.

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

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

The description is a single compact phrase containing the resource, the operation, and the endpoint. It has no filler and is easy to parse, though other dimensions carry the cost of this brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 optional-parameter list operation with strong annotations, the description is minimally viable. However, it leaves parameter semantics, response contents, and pagination/filtering behavior unspecified, so an agent has to guess about important invocation details.

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

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

The schema has zero description coverage, and the tool description does not explain the 'query' or 'account' parameters. The names are only minimally suggestive and there is no documentation of formats, allowed values, or whether account selects a tenant context.

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

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

The description clearly names the resource ('Campos extras de produtos') and the verb ('Listar'), and also gives the exact GET endpoint. This distinguishes it from sibling create/get/update/delete operations on the same resource.

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

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

The word 'Listar' and the GET endpoint imply it should be used for listing extra product fields, but there is no explicit guidance on when to prefer this over related tools such as gestaoclick_atributos_produtos_get or how query/account filtering affects 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 include readOnlyHint=false and destructiveHint=false, but the description does not go beyond that. The description does not disclose behavioral traits such as whether existing data is overwritten, whether it merges fields, or any validation rules. The '[write, altera dados]' tag is informative but already implied by the PUT method and the update verb. With annotations only indicating non-read-only and non-destructive, the description adds minimal behavioral context, and there is no explanation of potential side effects or prerequisites.

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

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

The description is concise, with only two sentences, and front-loads the core purpose. It includes the HTTP method and resource, which is efficient. It also mentions the bulk support, which is relevant. The structure is clean and not verbose, but it could be slightly more informative without becoming bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 is a mutation with 4 parameters, no output schema, and low schema description coverage, the description should provide more context about the request body, account parameter, and any specific behavior. The description is minimal and leaves the agent to infer too much. It covers the basic update operation but lacks details on required fields within 'body', error handling, or what constitutes a successful response. For a CRUD update on a specific attribute resource, with sibling tools for other attribute types, it is not sufficiently complete.

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

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

Schema description coverage is 0%, meaning the description must compensate for the parameters. It mentions 'ids' for batched execution and the endpoint includes {id}, but it does not clarify the meaning of 'body' (likely the payload with fields to update) or 'account' (likely account context). The description does not enrich the schema's parameter meanings; it only mentions bulk support. With low coverage and 4 parameters, this is a deficit.

Input schemas describe structure but not intent. Descriptions should explain 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 'Campos extras de produtos: Editar (PUT /api/atributos_produtos/{id})' which identifies the tool's purpose as editing extra product fields. It is specifically about updating product attributes, distinguishing it from sibling tools like create, delete, get, and list for the same resource. However, it could be more explicit about the resource scope ('atributos_produtos' vs 'produtos').

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 explicitly mentioning the HTTP method (PUT) and the endpoint structure, which implies usage for updating existing records. It also states 'Bulk support: accepts ids for batched execution,' giving a clue about when to use the 'ids' parameter. However, it does not provide explicit when-to-use vs. alternatives, such as when to use create vs. update, or any conditions like 'do not use if record doesn't exist.'

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

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

The description only repeats the write behavior ('[write, altera dados]') already implied by the create action and the annotations. No additional side effects, error conditions, or permissions are disclosed.

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

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

The description is extremely concise and front-loaded, but it omits essential details. While it is not verbose, it lacks structure and substance, making it minimally acceptable at best.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 is too sparse to be complete. It fails to explain the purpose of the extra fields, the expected body content, or the role of the account parameter, leaving the tool contextually incomplete.

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

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

The description does not explain the 'body' or 'account' parameters. It provides no context for what these strings should contain or how they relate to the extra sales fields, leaving the schema underdocumented.

Input schemas describe structure but not intent. Descriptions should explain 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 indicates a create operation ('Cadastrar') for 'Campos extras vendas' (extra sales fields), matching the tool name. However, it doesn't elaborate on what these extra fields are, distinguishing it from other sales-related tools.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or relationships to other create tools like gestaoclick_vendas_create.

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

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

The description explicitly states 'Deletar' (delete) and marks it as '[write, altera dados]', which indicates a destructive mutation. However, the annotation destructiveHint is false, implying the tool is not destructive. This directly contradicts the description. The annotation also has readOnlyHint=false which aligns with the 'write' claim, but the destructiveHint conflict is severe enough to warrant a score of 1.

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

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

The description is compact, consisting of two concise sentences. It front-loads the core purpose (Deletar) and the endpoint, then adds bulk support detail. It avoids redundancy and unnecessary fluff, though it could be slightly more structured (e.g., separating endpoint and behavior).

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

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

While a delete operation is relatively simple, the tool has 4 parameters (1 required) with 0% schema descriptions. The description only covers 'ids' partially, leaving 'id', 'body', and 'account' unexplained. There is no output schema to clarify return values. Given the tool's moderate complexity and lack of structured documentation, the description is incomplete.

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

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

Schema description coverage is 0%, so the description carries full responsibility for parameter explanations. It does add semantics for the 'ids' parameter by stating 'accepts ids for batched execution', but provides no explanation for the required 'id', nor for 'body' or 'account'. This is insufficient given the tool's complexity and the lack of schema descriptions.

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

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

The description clearly states this tool deletes extra sales attributes (Campos extras vendas: Deletar) and provides the specific endpoint DELETE /api/atributos_vendas/{id}. It distinguishes itself from sibling tools by explicitly naming the resource type (vendas) and the action (delete), making its purpose unambiguous.

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

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

The description gives the core action (delete) and notes bulk execution capability via ids, but it does not specify when to use this tool versus other delete tools for different resource types (e.g., delete for clientes, compras). It implies usage from the name and resource context, but explicit when-to-use guidance is absent.

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 that the tool supports bulk execution via 'ids', providing extra behavioral context beyond the annotations. No contradictions; it enhances transparency regarding batch capabilities.

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

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

The description is extremely short—two sentences—and gets straight to the point. It front-loads the purpose and adds a key detail about bulk support. No filler or redundancy.

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

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

The tool has 4 parameters and no output schema, so the description should explain return values and remaining parameters. It explains the core read purpose and batch, but omits details about what the response contains, the meaning of 'query' and 'account', and how it differs from the list tool. Given the complexity (average), this is a moderate gap.

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

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

Schema description coverage is 0%, so the description must explain parameters. It clarifies 'id' (referenced in the endpoint) and 'ids' (for batch), but 'query' and 'account' remain unexplained. It compensates partially but not fully, leaving two parameters ambiguous.

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

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

The description says 'Campos extras vendas: Visualizar' (View extra sales fields) and specifies the GET endpoint, making it clear this is a read operation for a specific resource. It distinguishes from create/delete/update siblings by the verb 'Visualizar' and the GET method, though it doesn't explicitly compare to the list sibling.

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

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

It mentions bulk support with 'accepts ids for batched execution', which hints at using this tool when you have multiple IDs. However, it doesn't explicitly state when to use this instead of the list tool or single GET, nor does it mention any alternatives. Usage context is implied but not fully articulated.

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, covering safety. The description adds the HTTP method and the resource path, which are useful context. However, it does not mention potential pagination, filtering, or any rate limits, but given the strong annotation coverage, a 3 is appropriate.

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

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

The description is concise and front-loads the key information ('Campos extras vendas') and the endpoint. It is only one short sentence with no fluff, which is efficient. However, the lack of detail is a trade-off, but for what it contains, it earns a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 relative simplicity (list operation with two optional params and no output schema), the description is adequate but minimal. It omits details like typical usage patterns, parameter purposes, or any return structure nuances. With no output schema and low schema coverage, more context would be helpful, but the core purpose is clear.

Complex tools with many parameters or behaviors need more documentation. 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 covers 0% of the two parameters (query and account) with descriptions, and the tool description provides no explanations for these parameters. This leaves the agent guessing what values to pass. Since schema coverage is low, the description must compensate, but it fails to do so.

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

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

The description states the tool lists extra sales fields via GET /api/atributos_vendas, which is clear as a list operation. However, it does not distinguish it from sibling list tools like gestaoclick_atributos_vendas_get or other atributos_vendas tools. The phrase 'Campos extras vendas' is specific but not unique among siblings.

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

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

No guidance is provided on when to use this tool versus alternatives, such as when to use the list vs get, or how it differs from other attribute list tools. The description mentions the HTTP method but does not explain scenarios or prerequisites, leaving usage ambiguous.

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

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

The description discloses the write behavior ('write, altera dados') and bulk execution, which adds context beyond the annotations. It does not contradict the annotations (readOnlyHint=false). However, it omits potential partial-failure behavior for bulk operations, error handling, or response details.

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

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

The description is extremely concise: two short sentences front-load the operation and endpoint, and the bulk note is separate and clear. There is no filler or redundant 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?

For a write-oriented tool with four parameters and no output schema, the description is too sparse. It does not describe the body format, account requirements, return values, or bulk-operation caveats. The endpoint and bulk note provide a base, but the tool remains under-specified.

Complex tools with many parameters or behaviors need more documentation. 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 needed to explain the four parameters but only clarifies 'ids'. The required 'id', 'body', and 'account' remain ambiguous, especially 'body' and 'account', leaving the agent without enough information to construct a correct request.

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

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

The description clearly identifies the operation ('Editar'), the target resource ('Campos extras vendas'), and the endpoint (PUT /api/atributos_vendas/{id}). This distinguishes it from the create/get/list/delete sibling tools for the same domain, and the bulk-support note adds further specificity.

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

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

The description implies usage through 'Editar' and provides a practical bulk-execution note ('accepts ids for batched execution'). However, it does not explicitly discuss when to choose this tool over the create/delete/list 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.

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

The annotations already declare readOnly, idempotent, and non-destructive behavior, which the description aligns with but does not contradict. The description adds only the HTTP method and endpoint, offering no additional behavioral context such as pagination, authentication, or filtering.

Agents need to know what a tool does to the 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 short sentence that is immediately clear and front-loads the resource and verb. Every word contributes to identifying the operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no parameter descriptions, the description is too sparse to fully support an agent. It identifies the operation but fails to explain what parameters do or what the response contains, leaving important context for a list endpoint unclear.

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

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

The schema defines two parameters (query, account) with zero description coverage, and the tool description does not mention or explain either parameter. With no information in the description, an agent cannot infer the purpose or format of 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 description clearly states the verb (Listar/list) and resource (centros de custos/cost centers), along with the exact HTTP endpoint. This makes it distinct from the many sibling list tools for other resources.

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

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

The description implies usage by naming the specific resource, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or contrast with similar list 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description only repeats the GET method and endpoint, adding no behavioral context such as pagination, filtering, authentication, or response structure.

Agents need to know what a tool does to the 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, compact sentence with no wasted words or redundant phrasing. It front-loads the essential verb and resource, followed by the endpoint, making it easy to parse.

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

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

For a list tool with two undocumented parameters and no output schema, this description is insufficient. It does not explain the meaning of 'query' or 'account', nor does it describe pagination, response format, or any other behavior needed to use the tool effectively.

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

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

Both parameters 'query' and 'account' are completely undocumented in the schema and the description. With 0% schema description coverage and no explanation of what these parameters mean or how they affect the listing, the agent cannot make informed parameter choices.

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

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

The description clearly states the verb 'Listar' and the resource 'Cidades', and the explicit endpoint 'GET /api/cidades' reinforces the purpose. It is more informative than the tool name alone, but it provides no additional detail about the city entity or the meaning of the list result.

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

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

The description provides no guidance on when to use this tool versus the many sibling list tools, nor any context about prerequisites or typical use cases. There are no exclusions or alternative tool mentions.

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, altera dados]' which aligns with the annotations (readOnlyHint: false) but adds minimal extra context. It does not disclose any side effects, required permissions, rate limits, or consequences beyond the write nature, and it repeats what annotations already imply.

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

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

The description is extremely brief, consisting of a single sentence. While it is concise and front-loaded with the essential action and endpoint, it omits crucial information about parameters and usage. It is not verbose, but the brevity comes at the cost of completeness, so it is not a top 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?

Given this is a create operation with two parameters and no output schema, the description is severely incomplete. It does not explain the payload structure, the account context, or any expected response. An agent cannot safely invoke this tool based solely on the description and 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 schema has zero description coverage for both parameters (body and account), and the description does not mention either parameter at all. There is no explanation of what body should contain or what account refers to, leaving the agent entirely in the dark about how to invoke the API.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Cadastrar' = create) and the target resource (Clientes), and specifies the HTTP endpoint (POST /api/clientes). This distinguishes it from sibling tools like get, list, update, and delete for the same resource, making the purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, contexts, or situations where this create operation is appropriate or inappropriate. There is no reference to other tools or exclusion criteria.

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

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

The description explicitly calls the operation 'DELETE' and marks it as '[write, altera dados]', yet the annotations declare destructiveHint=false. This is a direct contradiction and makes the actual behavioral effect of the tool ambiguous. No additional side effects, irreversibility, or data-impact details are disclosed.

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

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

The description is concise and front-loaded: the first sentence gives the action, resource, and HTTP method, and the second adds the bulk execution detail. Every part earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 is adequate for a straightforward DELETE endpoint, and bulk support adds relevant context. However, the missing parameter semantics and contradictory annotation about destructiveness leave gaps that the agent would need resolved in order to select and invoke the tool confidently.

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

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

Schema description coverage is 0%, so the description should compensate by explaining the parameters. It only mentions that 'ids' enables bulk execution and that id is part of the endpoint, but it leaves 'body' and 'account' entirely unexplained.

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

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

The description clearly states the action ('Deletar'), the resource ('Clientes'), and the exact HTTP endpoint (DELETE /api/clientes/{id}). It unambiguously distinguishes this delete tool from the other client CRUD 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 communicates the core operation and mentions bulk support, which is useful. However, it does not explicitly say when to use this tool instead of alternatives, such as gestaoclick_clientes_update or gestaoclick_clientes_get, nor does it state any preconditions or after-effects.

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 false, lowering the bar. The description adds the concrete HTTP GET endpoint and the important custom behavior of bulk execution via an 'ids' array, going beyond what annotations convey. It does not disclose response shape or error behavior, but for a safe GET operation this is adequate.

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

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

Two short sentences convey the essential action, endpoint, and bulk capability with zero filler. The structure is front-loaded with the core purpose and immediately follows with the special feature.

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

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

For a simple read-only GET with good annotations, the description is reasonably complete, but the unexplained 'query' and 'account' parameters plus the lack of response details leave gaps. Without an output schema, some added information about the expected response or remaining parameters would make the tool easier to reason about.

Complex tools with many parameters or behaviors need more documentation. 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 only clarifies 'id' through the URL and 'ids' through the bulk mention. The 'query' and 'account' parameters are completely unexplained, and the relationship between required 'id' and optional 'ids' is not fully clarified.

Input schemas describe structure but not intent. Descriptions should explain 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 this is a read operation for clients via GET /api/clientes/{id}, matching the tool name. The 'Visualizar' (View) label plus the REST endpoint identifies exactly what resource is targeted and distinguishes it from create/update/delete/list 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?

The description implies the tool is for retrieving one or more clients by ID and mentions bulk support via 'accepts ids for batched execution'. However, it does not explicitly contrast with clientes_list or state when to use one over the other, leaving some usage 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, destructiveHint=false, so the safety profile is clear. The description adds the endpoint path but no additional behavioral context (e.g., pagination, response structure). It doesn't 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?

Single sentence, very concise and front-loaded. No wasted words.

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

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

For a list operation with no output schema and two unexplained parameters, the description is too sparse. The agent cannot know what 'query' or 'account' accept, what data is returned, or how filtering works. More detail is needed.

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

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

Schema description coverage is 0%, and the two parameters (query, account) are completely undocumented. The description provides no explanation of what these parameters mean or how to use them, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain 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 resource (Clientes) and action (Listar) with the HTTP method (GET /api/clientes). While it names the endpoint, it could be more explicit about the scope (all clients vs filtered), but the verb+resource mapping is unambiguous.

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

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

No guidance on when to use this tool versus alternatives (e.g., gestaoclick_clientes_get for fetching a specific client). The description only repeats the endpoint without context on typical use cases or prerequisites.

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

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

Annotations already indicate this is not read-only, and the description reinforces that with '[write, altera dados]' and the PUT method. It also adds a bulk behavior trait, but it does not disclose auth requirements, response format, or side effects of updating, so it only partially goes beyond the annotations.

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

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

The description is very short and front-loaded with the core purpose and endpoint. There is no wasted wording, but it is terse enough that important parameter details like body and account are omitted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 4 parameters, no output schema, and 0% schema description coverage, the description is incomplete. It fails to explain the body payload, account usage, id/ids interaction, or any expected response/errors, which an agent would need to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It clarifies that 'ids' enables batched execution, but it does not explain what 'body' or 'account' mean, nor the relationship between 'id' and 'ids'.

Input schemas describe structure but not intent. Descriptions should explain 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 edits clientes via PUT /api/clientes/{id}, giving a specific verb, resource, and HTTP method. This distinguishes it from sibling create/delete/get/list tools for the same resource.

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

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

The description provides clear context that this tool is for editing existing clientes, and the bulk-support note explicitly tells the agent it can accept multiple ids for batched execution. It does not explicitly mention exclusions or alternatives, so it falls short of a 5.

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=false, which signals a write operation, and the description adds '[write, altera dados]' (modifies data), which is redundant with the annotation. However, it does expose the HTTP method (POST) and endpoint, which are not in annotations. Beyond that, no additional behavioral traits (e.g., auth requirements, side effects, or data persistence details) are mentioned, leaving the description only marginally additive.

Agents need to know what a tool does to the 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 (a single sentence) and front-loaded with the resource and action, which is good. However, it is under-specified rather than economically thorough; it omits all parameter details and behavioral nuance. While it earns its place for purpose, the brevity is not a strength when essential information is missing.

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

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

Given the minimal schema (no enums, no required fields, no output schema) and the fact this is a create operation, the description fails to provide necessary context. It does not explain the request body structure, required account handling, or any expected response. Sibling tools like gestaoclick_compras_{get,list,update} suggest a full CRUD ecosystem, but this description alone is insufficient for an agent to correctly invoke the tool without external knowledge.

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

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

The schema defines two string parameters ('body', 'account') with zero description coverage, and the tool description does not explain either parameter at all. For a create operation, 'body' likely holds the purchase payload and 'account' might identify the account, but this is pure speculation. With no guidance, the agent has no semantic understanding of how to populate these fields, making this a critical gap.

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

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

The description clearly states the action: 'Compras: Cadastrar' (Purchases: Register) with the HTTP endpoint POST /api/compras. It identifies the specific resource (compras) and the create operation, distinguishing it from sibling tools like gestaoclick_compras_update or other entity create tools. The '[write, altera dados]' tag reinforces the intent.

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

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

The description implies when to use this tool (i.e., when creating a purchase) via the 'Cadastrar' verb, but provides no explicit guidance on when not to use it or alternatives like update or list. It lacks any mention of prerequisites, such as needing an existing account or authentication flow, and does not differentiate from similar create tools beyond the resource 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?

The description includes '[write, altera dados]', which indicates it modifies data, but the annotation destructiveHint is false, which contradicts the deletion action. This is a serious inconsistency, and the description does not clarify the safety profile despite being a delete operation.

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

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

The description is concise (two sentences) and front-loaded with the main purpose. The second sentence about bulk support is useful, but the '[write, altera dados]' tag is redundant with annotations, adding little value. Overall, it's efficient with no unnecessary fluff.

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

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

Given the tool is a mutation with no output schema and only 0% parameter coverage, the description is under-specified. It does not explain the effects of deletion (e.g., irreversible?), the role of 'account', or the response format, leaving the agent with gaps for safe use.

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

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

The description mentions bulk support via 'ids' but does not explain the 'body' or 'account' parameters beyond the schema. With 0% schema description coverage, the description should clarify parameter usage, but it only highlights 'ids' briefly without syntax or semantics.

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

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

The description clearly states it deletes 'Compras' via DELETE /api/compras/{id}, identifies the resource and action. It distinguishes from siblings like gestaoclick_compras_get/list/update/create by the DELETE verb and 'Deletar' label, though it could be more explicit about bulk deletion as an alternative.

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

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

No guidance on when to use this tool vs alternatives like gestaoclick_compras_update for modifications or gestaoclick_compras_delete for other resources. The only usage hint is the bulk support mention, but it lacks context on 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?

The annotations already mark readOnlyHint=false and destructiveHint=false; the description adds '[write, altera dados]' and the POST method, clearly indicating a data-mutating operation. Still, it does not disclose what data is altered, what records are generated, or whether the operation can be reversed.

Agents need to know what a tool does to the 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 concise line that front-loads the domain and action, making it easy to scan. The '[write, altera dados]' marker is somewhat redundant with annotations, but it is short and not distracting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no output schema, sparse annotations, and a minimal description. A caller cannot infer the required body content, the role of 'account', expected side effects, or error conditions, making the tool risky to invoke correctly without external documentation.

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

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

Both parameters ('body', 'account') are undocumented in the schema and have 0% schema description coverage. The description does not mention either parameter or hint at their meaning, so the agent has no basis for constructing a correct request payload.

Input schemas describe structure but not intent. Descriptions should explain 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 a specific action ('Gerar parcelas') and a domain resource ('Compras'), with the endpoint further reinforcing the operation. It differentiates from sibling gerar_parcelas tools for vendas, orcamentos, and ordens_servicos by naming 'Compras', though it does not elaborate on what parcelas creation entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'Compras:' prefix implies this tool is for purchase-related installment generation, and sibling gerar_parcelas tools give some contrast. However, there is no explicit guidance on when to prefer this tool, what prerequisites exist, or when another tool should be used instead.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the behavioral detail of bulk execution ('accepts ids for batched execution'), which is not in annotations. It does not contradict annotations and provides useful extra context about how the tool can be invoked.

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

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

The description is extremely concise: two sentences, immediately stating the purpose and a key additional capability. There is no filler or repetition. Every word earns its place, making it easy to parse.

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

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

Given the tool is a simple GET-by-id with good annotations (readOnly, idempotent, non-destructive), the description covers the core usage and even adds bulk support. No output schema is present, so return format is not specified, but for a simple view it may be acceptable. It does not mention authentication or prerequisites, but those might be implied by the broader API context. Overall it's reasonably complete for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'id' implicitly via the endpoint and mentions 'ids' for bulk support, but leaves 'query' and 'account' entirely unexplained. This is a significant gap since these parameters could have important semantics. The description partially adds meaning but does not cover all parameters.

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

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

The description clearly states the tool retrieves a purchase ('Compras: Visualizar') and specifies the exact endpoint (GET /api/compras/{id}). It distinguishes from siblings like compras_list by indicating it's for a single resource, and the bulk support note adds specificity. The verb 'Visualizar' and resource are unambiguous.

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

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

The description implies this tool is for viewing a specific compra by id, and the bulk support note hints at using it when needing multiple specific ids. However, it does not explicitly mention when to prefer this over list or other alternatives, nor does it state any exclusions. It's clear enough but lacks explicit 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?

The annotations already disclose that the operation is read-only, idempotent, and non-destructive. The description adds no behavioral context beyond the HTTP method and endpoint, but it does not contradict the annotations either.

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

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

The description is extremely short and contains no filler or repetition. However, it is at a level of under-specification where some needed contextual and parameter information is absent, so it is not fully 'appropriately sized.'

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 endpoint, the minimal language and good safety annotations cover basic purpose, but the missing parameter semantics, lack of pagination/filtering context, and no mention of what data is returned make the definition incomplete for an agent relying solely on it.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or interaction of 'query' and 'account'. An agent cannot infer whether these are filters, identifiers, or account-scoping values from the provided text.

Input schemas describe structure but not intent. Descriptions should explain 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 operation and resource: 'Listar' and 'GET /api/compras'. This is enough to distinguish it from compras_get, compras_create, compras_update, and compras_delete, but it does not add scope beyond the obvious listing behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 this tool should be used versus alternatives like compras_get, or what kinds of list/summary operations warrant this call. Usage is only implied by the endpoint and 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 already indicate this is not read-only and not idempotent; the description reinforces mutation with `[write, altera dados]` and adds the batch-execution behavior. It does not disclose more context such as whether omitted fields are replaced, whether authentication is needed, or what errors might occur.

Agents need to know what a tool does to the 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: it starts with the exact operation and endpoint, then adds the bulk-support caveat. Every line adds value, and no unnecessary words beyond the inline write tag are present.

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

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

For a mutation tool with no output schema and no parameter descriptions in the schema, the description is too sparse for correct invocation. It explains what the tool does and that bulk is supported, but leaves `body` and `account` behavior unexplained, creating a substantive gap for how to actually call the tool.

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

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

Schema description coverage is 0%, and the description only gives partial meaning to `id` (single record via PUT path) and `ids` (bulk execution). The important parameters `body` and `account` are not explained, so the agent cannot reliably determine the update payload or which account context is required.

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

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

The description clearly identifies this as the edit/update operation for Compras, with the exact HTTP method and endpoint: 'Editar (PUT /api/compras/{id})'. This distinguishes it from sibling create, delete, get, and list operations for the same resource.

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

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

It communicates that the tool edits existing Compras records and that batch execution is possible via `ids`, so the agent knows when to select it. However, it does not explicitly say when not to use it or name alternatives such as create/delete/get, leaving the guidance somewhat implied.

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 readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds the HTTP method and endpoint, which is extra context, but it doesn't describe pagination, return format, or any restrictions.

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

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

The description is extremely concise, a single phrase, which is good for brevity. However, it lacks structure and does not front-load any actionable details beyond the resource name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 list tool with two parameters and no output schema, the description is too sparse. It doesn't explain what the tool returns, any defaults, or the significance of the parameters, making it incomplete for an agent to use effectively.

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

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

Schema description coverage is 0% and the description does not explain the 'query' or 'account' parameters at all. It offers no hints about their purpose or expected values, leaving the agent entirely uninformed.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Listar') and the resource ('contas bancárias'), and even provides the API endpoint. It distinguishes itself from siblings by naming the specific resource, though it doesn't explicitly contrast with other list tools.

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

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

No guidance is provided on when to use this tool versus alternatives. There's no mention of filtering, prerequisites, or context for choosing this over similar list tools like gestaoclick_clientes_list.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the endpoint in the form, with no additional behavioral context such as filtering behavior, pagination, or data returned. This is consistent with annotations and does not contradict them.

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

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

The description is extremely concise: 'Estados: Listar (GET /api/estados).' It uses a front-loaded resource-and-verb structure and contains no fluff or redundant 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?

For a list operation with no output schema and completely undocumented parameters, the description is not complete. It identifies the endpoint, but it does not explain what 'query' and 'account' do, what state data is listed, or what shape the response takes. Despite the low conceptual complexity, key usage details are 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 has two properties, 'query' and 'account', and the schema description coverage is 0%. The description says nothing at all about what these parameters mean, what values they accept, or how they affect the response. The tool must rely entirely on the parameter names, which are ambiguous.

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

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

The description clearly identifies the tool as listing 'Estados' (states) and explicitly provides the HTTP endpoint 'GET /api/estados'. The verb 'Listar/List' plus the resource uniquely distinguishes it from the large sibling set of list tools.

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

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

The description implies this is a read-only listing operation, which is reinforced by the annotations, but it does not provide explicit guidance about when to prefer this tool over alternatives or any conditions/ exclusions. No when-not-to-use guidance is given, despite many similar list endpoints existing among siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds only the HTTP method (GET), which is consistent with annotations but provides no additional behavioral context such as return structure, limits, or side effects. 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 a single sentence, which is concise, but it is under-specified—it essentially restates the tool name and adds the endpoint. It fails to include necessary usage details, so the brevity is not effective conciseness but rather omission.

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

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

Given the tool has two undocumented parameters and no output schema, the description does not provide enough context for an agent to use it effectively. It lacks parameter semantics, return value expectations, and usage scenarios, making it incomplete for a functional tool.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'query' or 'account' parameters. Without any description of their meaning or usage, an agent cannot correctly construct calls, making this a significant gap.

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

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

The description clearly states it lists payment methods (Formas pagamentos: Listar) and provides the endpoint. It is unambiguous about the resource and action, though it does not distinguish from sibling list tools with similar names.

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

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

No guidance is given on when to use this tool versus alternatives, nor does it explain the purpose of the 'query' and 'account' parameters or any filtering or pagination considerations. The description only states the action without context.

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

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

The description's '[write, altera dados]' tag merely restates the annotation readOnlyHint=false and adds no new behavioral context. It does not disclose side effects, authentication needs, or response behavior beyond what annotations already 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 extremely short and front-loaded with the main purpose. However, the '[write, altera dados]' element is redundant given the annotations, so it does not fully earn its place.

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

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

For a create operation with an undocumented body and account parameter, the description is critically incomplete. No output schema exists to compensate, and the agent lacks essential 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?

The schema's two parameters (body and account) have no descriptions and 0% coverage. The description offers no explanation of what values or format these parameters require, leaving the agent unable to construct a valid request body.

Input schemas describe structure but not intent. Descriptions should explain 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 'Cadastrar' (create/register) for the resource 'Fornecedores' (suppliers) and gives the HTTP POST endpoint. This specific verb+resource combination distinguishes it from sibling tools like get, list, update, and delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 creating suppliers via the verb 'Cadastrar' and POST method, but it does not explicitly state when to use it versus alternatives, nor provide exclusions or conditions. Usage guidance is only implicit.

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

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

The description states 'Deletar' (delete) and '[write, altera dados]', indicating a mutating operation. However, the annotation destructiveHint is false, which directly contradicts the nature of a delete operation. This contradiction warrants a score of 1.

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

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

The description is extremely concise, with the primary purpose stated first and bulk support noted second. No extraneous words, perfectly front-loaded and efficient.

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

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

For a tool with 4 parameters, no output schema, and conflicting annotations, the description is too sparse. It omits details on return values, error handling, authentication, and does not clarify the use of multiple parameters. The contradiction further reduces 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?

The description only mentions 'ids' for bulk support, but does not clarify the purpose of the 'body', 'account', or the relationship between 'id' (required) and 'ids'. With 0% schema description coverage, the description fails to compensate for missing parameter 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 clearly states the operation: 'Fornecedores: Deletar (DELETE /api/fornecedores/{id})' identifies the resource (fornecedores) and the action (delete). It also mentions bulk support, making it distinct from other delete tools for different resources.

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

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

The description implies usage for deleting suppliers, and the bulk support note provides a clear scenario for using the tool with multiple IDs. It does not explicitly contrast with alternatives, but the purpose is clear enough that an agent knows when to invoke 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the bulk execution trait ('accepts ids for batched execution'), which is beyond the annotation set. However, it does not disclose potential error handling, pagination, or response format, but given the annotation coverage, this is acceptable. 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 extremely concise, consisting of two short sentences. It front-loads the primary purpose and adds a single relevant note about bulk support. There is no fluff, and every sentence contributes. However, it might be too minimal, but for conciseness it earns a high 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?

With 4 parameters, no schema descriptions, and no output schema, the description must provide substantial context. It only explains the basic GET action and bulk support, leaving 'query' and 'account' unexplained, and no indication of return values or error scenarios. The tool is not adequately described for an agent to use it confidently without additional context.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only mentions 'ids' for bulk support, but does not explain 'id', 'query', or 'account'. The description does not compensate for the lack of schema descriptions, leaving most parameters ambiguous.

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

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

The description clearly states it is a read operation for suppliers ('Fornecedores: Visualizar (GET /api/fornecedores/{id})') and mentions bulk support via 'ids'. This distinguishes it from the sibling list, create, update, and delete tools. However, it could be more explicit about what data is returned, but the core purpose is unambiguous.

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

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

There is no explicit guidance on when to use this tool versus the list tool or how to handle bulk vs single retrieval. The mention of bulk support hints at a use case, but it does not explain when to prefer this over alternatives or provide any exclusions (e.g., 'use list to retrieve all suppliers'). The description fails to give clear usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and side effects. The description adds only the HTTP method and endpoint, which are not behavioral disclosures. It does not mention pagination, result set size, or any side effects on the system, so 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 a single, front-loaded sentence that states the resource, operation, and endpoint without waste. It is concise and to the point, though it lacks a structured breakdown of parameters or usage, which affects completeness but not 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 tool has two optional parameters and no output schema, yet the description provides no explanation of expected inputs or return data. Without guidance on filtering, account handling, or response format, the description is inadequate for an agent to use the tool effectively in most scenarios.

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

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

Both parameters (query and account) have no descriptions in the schema (0% coverage), and the tool description does not explain their purpose. The agent cannot infer what 'query' filters on or why 'account' is needed. This is a critical gap for correct invocation.

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

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

The description explicitly states the resource (fornecedores) and operation (Listar), and mentions the HTTP method and endpoint. It clearly distinguishes from get/create/update/delete siblings by indicating it's a list operation. However, it lacks any detail on scope (e.g., all items vs. filtered) or response characteristics, so it's not a perfect 5.

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

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

No guidance is provided on when to use this tool versus the get/update/delete tools or other list endpoints. There is no mention of filtering via the query parameter or any prerequisites (e.g., needing an account). The description simply states the action without contextual advice.

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 a non-read-only operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the explicit '[write, altera dados]' and notes bulk execution, providing some extra context. No contradictions; however, it does not disclose error handling, side effects, or authentication requirements beyond what annotations imply.

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

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

The description is concise: two sentences with no filler, front-loading the primary purpose and then a note on bulk support. It earns its place without verbosity, though it could be slightly more informative without hurting 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?

For an update tool with four parameters, no output schema, and zero schema description coverage, the description leaves significant gaps: it does not explain the 'body' parameter (presumably the fields to update) or 'account' (likely needed for tenant context). Return behavior is also unspecified, making it incomplete for correct agent usage.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It only addresses 'id' (via endpoint) and 'ids' (bulk support), leaving 'body' and 'account' unexplained. This is insufficient for an agent to know how to construct a valid update request, especially what the body should contain.

Input schemas describe structure but not intent. Descriptions should explain 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 action (edit suppliers) and the HTTP method plus endpoint, which unambiguously identifies the tool's purpose. It distinguishes from siblings like create, delete, get, and list by specifying 'Editar' (update) and the PUT method.

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

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

Mentions bulk support via 'ids', but does not clarify when to use this update tool versus other retrieval tools, nor does it specify prerequisites or exclusion conditions. Guidance is minimal and implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP method (GET) and endpoint, which confirms the read-only nature. However, it does not add further behavioral details such as pagination, response format, or any side effects, but given the annotations, the description meets the baseline.

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

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

The description is extremely concise, one sentence, and includes the resource name and HTTP method. It is front-loaded and wastes no words, though it could have used a bit more space to clarify parameters or usage.

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

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

With no output schema and minimal description, the tool is under-specified. The tool complexity is low (list operation), but the two parameters are completely unexplained, and there is no guidance on expected return. Given the lack of parameter semantics and usage guidance, the description is incomplete for reliable invocation.

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

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

Schema description coverage is 0%, and the description does not explain the 'query' or 'account' parameters at all. The schema only provides type string with no descriptions, so the agent has no clue what these parameters mean or how they affect the listing. The description must compensate but fails to do so.

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

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

The description clearly states the tool's purpose: listing employees via GET /api/funcionarios. It specifies the resource (funcionarios) and the action (listar/list). While it does not explicitly differentiate from siblings, the resource name is unique among the many list tools, so the purpose is clear.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only states the HTTP endpoint. There are no exclusions, prerequisites, or mention of other tools for filtering or retrieving specific records. The usage context is implied by the resource name but not articulated.

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 state read-only, idempotent, and non-destructive behavior. The description adds only the HTTP method/path, which is minimal and does not disclose anything beyond what annotations imply (e.g., no mention of pagination, filtering, or return structure). No contradiction with annotations, but little additional transparency value.

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

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

The description is intentionally concise: one short sentence naming the resource and operation. Every word earns its place, with no fluff or repetition. For a simple list endpoint, this is appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 parameter descriptions and output schema, the description leaves the agent without enough context to correctly invoke the tool. It does not explain what the query and account parameters are for, or what data the response contains. A simple list tool still needs basic parameter semantics to be usable.

Complex tools with many parameters or behaviors need more documentation. 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 does not explain the 'query' or 'account' parameters at all. The agent has no information about what these parameters do or how to use them, making this a critical gap.

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

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

The description clearly states the operation (Listar/List) and the resource (grupos_produtos/product groups), with the HTTP endpoint. This is a specific verb+resource combination that distinguishes it from sibling list tools for other entities.

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

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

There is no guidance on when to use this tool versus alternatives. The description simply names the resource and operation, providing no context about typical 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 establish readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful behavioral context beyond those annotations by specifying that the list is scoped to 'this install' and by revealing the returned shape (id, label), which helps the agent understand exactly what to expect.

Agents need to know what a tool does to the 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 one short, front-loaded sentence that includes the action, the resource, the installation scope, and the expected return fields. Every word contributes meaning, with no redundancy or filler.

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

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

For a simple, read-only listing tool with supportive annotations, the description covers the main purpose and output fields. However, with no output schema and no explanation of the optional account parameter, the description has a notable gap that prevents it from being 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 input schema only defines 'account' as a string with no description, and the description does not clarify what this parameter accepts or how it affects the result. With 0% schema description coverage, the description carries the burden for parameter semantics, and it fails to explain the optional 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 clearly states the tool lists GestãoClick connections/accounts linked to the installation and specifies the returned fields (id, label). 'Lista' is a specific verb, and the resource 'conexões (contas) GestãoClick vinculadas a este install' distinguishes it from the many other list 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 context is clear: an agent would use this when it needs to see which GestãoClick accounts are connected. However, the description gives no explicit when-to-use guidance or alternatives, and it does not explain whether the optional account parameter is meant to filter the list or serve some other purpose.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the HTTP endpoint and does not mention pagination, response format, or any other behavioral details beyond what annotations already imply.

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

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

The description is very short and front-loaded: resource, action, and endpoint in one line. It is efficient, though slightly redundant with the tool name, which prevents a perfect 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?

The tool is a simple read-only list endpoint, but with no output schema and minimal parameter documentation, the agent is left without information about filtering semantics or the shape of the returned stores. Important 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?

Schema description coverage is 0%, and the description does not explain the 'query' or 'account' parameters at all. An agent cannot determine what those values should represent or how they affect the list request.

Input schemas describe structure but not intent. Descriptions should explain 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 resource ('Lojas') and the action ('Listar'), and also gives the exact endpoint GET /api/lojas. This directly distinguishes it from the many other gestaoclick_*_list 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?

It is implied from the verb 'Listar' and endpoint that this tool is for listing stores, so an agent can infer core usage. However, there is no explicit statement of when to prefer this over alternatives or any exclusions/filtering 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, so the write/alter behavior is expected. The description adds that it updates data and supports bulk execution. However, it does not disclose what happens to associated records, whether cancellation is reversible, or any side effects, which would add 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 very concise: two lines with key information (endpoint, write nature, bulk support). It is front-loaded with the core purpose and endpoint. No fluff, but it could briefly mention parameter roles without much added length.

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

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

Given the tool has 4 parameters, 0% schema description coverage, and no output schema, the description is insufficient for reliable invocation. It does not clarify how 'body' and 'account' are used, the relationship between 'id' and 'ids', or error conditions. The lack of output schema means the agent cannot predict return values, and the description does not compensate.

Complex tools with many parameters or behaviors need more documentation. 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 'id' and 'ids' for bulk support. It does not explain the purpose of 'body' or 'account' parameters, nor does it clarify constraints on 'id' format or behavior when both 'id' and 'ids' are provided. Since the schema provides no descriptions, the tool description fails to compensate, leaving agent unsure about parameter usage.

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

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

The description clearly states the tool's purpose: cancelling consumer invoices via POST /api/notas_fiscais_consumidores/cancelar/{id}. It also notes bulk support for batches. It distinguishes from siblings through the resource name (notas_fiscais_consumidores) and action (cancelar), though it doesn't explicitly contrast with other variants like notas_fiscais_produtos_cancelar_create.

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

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

The description indicates it is a write operation that alters data and supports bulk execution via ids, implying use when cancelling consumer invoices. However, it does not provide explicit guidance on when to use this vs. other cancellation tools (e.g., for produtos or servicos) or when cancellation is appropriate, relying on the tool name and context.

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

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

Annotations already indicate readOnlyHint=false, so the description's '[write, altera dados]' confirms the mutation behavior, adding slight value. However, no details on required permissions, idempotency, or side effects. Since annotations already cover the read-only flag, the description adds minimal context.

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

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

The description is concise with two short sentences and a clear write tag. It is front-loaded with the resource name and action, though the bracket tag is redundant with annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 create tool with no output schema and low parameter explanation, the description is insufficient. It doesn't specify required fields, data format, or typical usage context, leaving the agent guessing about the body structure.

Complex tools with many parameters or behaviors need more documentation. 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 parameters 'body' and 'account' are not explained in the description. The description only mentions the endpoint but gives no hint about how to construct the body or what account means. The description does not compensate for the lack of schema detail.

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

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

The description states the tool is for registering consumer invoices (POST /api/notas_fiscais_consumidores), which clearly indicates a create operation. However, it does not differentiate from sibling tools like gestaoclick_notas_fiscais_consumidores_update or emitir_create, and the 'Cadastrar' verb is somewhat generic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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. It does not mention that this is for creating new invoices, while emitir_create or update are for other operations. No exclusions or prerequisites stated.

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

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

The description says 'DELETE' and 'Deletar', but the annotations set `destructiveHint` to false, which contradicts the destructive nature of the operation. The description does not add helpful behavioral context such as permanent deletion effects, authorization requirements, 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 short, front-loaded, and includes the HTTP method and a bulk-support note in a compact format. There is minor redundancy between 'Deletar' and 'DELETE', but the extra line about bulk execution is useful.

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

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

For a mutation/delete tool with no output schema and minimal annotations, the description leaves important gaps: it does not explain what `body` or `account` mean, what happens when the deletion succeeds, or whether bulk execution has restrictions. The contradictory destructive hint further weakens the operational 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 needed to explain the parameters. It explains that `ids` can be used for batched execution, but it does not clarify the meaning or format of `id`, `body`, or `account`.

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

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

The description clearly states the tool deletes consumer invoices (Notas Fiscais de Consumidores) using the DELETE endpoint and provides the path with `{id}`. The verb and targeted resource are explicit, and the domain in the name disambiguates it from other delete tools like those for products or services.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 only operational hint is that the tool supports `ids` for batched execution. There is no mention of when to choose this tool over related operations such as cancel, create, update, or the other delete tools, and no exclusions are provided.

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