Digital Manager Guru

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

The description explains the behavioral flow: browser login, token retrieval, and the difference between permanent and session-based authentication. It adds context beyond the annotations (idempotent, non-read-only) by detailing side effects (e.g., setting up a permanent connection). 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 moderately concise, using a colon to separate purpose from instructions. Each sentence loads value: identifying target users, describing the best practice, and providing an alternative. Slightly longer than necessary but well-structured and front-loaded.

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

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

Given the simple interface (one optional parameter, no output schema), the description provides all needed context: how to authenticate, two modes, and invocation examples. It covers the complete usage scenario without missing key 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 fully compensates by explaining the token parameter's purpose and optionality. It explicitly states to call with { token: "<jwt>" } after pasting, or with no args to get the link, making the parameter's semantics crystal clear.

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

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

The description clearly states the tool's purpose: facilitating authentication for IDE agents via browser login and token handling. It specifies the workflow (log in, copy token) and distinguishes it from sibling tools like 'connect' by its focus on authentication and token configuration.

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

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

The description provides explicit usage context—it is for IDE agents and explains two modes (permanent via config header, session-only via token). It also explains when to call with or without the token argument. However, it does not directly compare to alternative tools or state when not to use it, so a small deduction.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which already disclose safe read-only behavior. The description adds context about state transitions: when credentials are missing vs when all connected, explaining the returned structures. This exceeds what annotations provide and adds 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 concise (two sentences) with key information front-loaded: what it does and expected outputs. It's efficient without unnecessary fluff. Minor deduction for not explicitly delineating edge cases, but it's 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 tool's simplicity (0 params) and output schema absence, the description covers the essential states. However, it could mention potential errors (e.g., partial connection, network issues) or what 'pending' means more explicitly. It's adequate but leaves minor gaps.

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

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

The tool has 0 parameters, and schema coverage is 100% (vacuously). No parameter semantics needed. The description focuses on output semantics, which is beneficial. Since there are no parameters, baseline 4 applies as the description doesn't need to compensate.

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

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

The description clearly states the tool 'Returns connection status and URLs' with specific details about authenticated state and pending array. While it doesn't explicitly name sibling tools, the context of an authentication toolset makes its purpose distinct: checking connectivity rather than performing authentication. It's specific enough to differentiate from the 'authenticate' 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?

The description implies usage for checking connection status without stating when to use it versus alternative tools. It doesn't explicitly say 'use this to check if all providers are connected before other operations' or mention when not to use it. Context signals show parameters 0, so usage is implied 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't repeat those. It does add the behavioral context that this is for verifying webhook origin, which is useful. However, it doesn't describe return values, side effects, or any error conditionshering to the validation. Given the annotations cover safety, a score of 3 is appropriate; the description adds a bit of value but could be more explicit about outcomes.

Agents need to know what a tool does to the 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 directly addresses the main purpose and key argument. It front-loads the most important information. No fluff, but it is perhaps too terse to earn a 5; it could add a brief note on what the function returns or the broader context.

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

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

For a simple read-only validation tool with no output schema, the description is reasonably complete. It explains the purpose and the required parameter. However, it omits the optional 'account' parameter and does not mention what the response looks like (e.g., boolean, object, error codes). Given the low parameter coverage and lack of output schema, a bit more detail would be expected, hence a 3.

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

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

The schema has two parameters ('account' and 'account_token'), but the description only explains 'account_token' and entirely ignores 'account'. With 0% schema coverage, the description should clarify each parameter's meaning agendas. It mentions 'account_token' in the description but not 'account', leaving ambiguity. This is a gap in parameter clarification, so it scores low.

Input schemas describe structure but not intent. Descriptions should explain 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 validates a Guru account token and explains its purpose (verifying webhook origin). It uses a specific verb ('validates') and a clear resource ('Guru account token'), which distinguishes it from the many other guru_* tools. However, it doesn't explicitly differentiate from the sibling 'authenticate' or other validation-like tools, which keeps it from a 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?

The description gives a concrete use case ('used to verify webhook origin'), which helps an agent decide when to use it. However, it does not mention when not to use it or recommend alternative tools, nor does it describe any prerequisites or context for invocation. It provides basic context but no exclusionary 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, and the description's 'leitura' is consistent with those. The description adds useful extra behavior by mentioning cursor-based listing and bulk execution via ids, though it does not explain response shape or other runtime behavior.

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

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

The description is short and front-loaded with the read-only scope, and the action/parameter mapping is compact. The '[Flattened action: assets]' note is slightly cryptic, but the overall text is efficient and not padded.

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

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

There is no output schema and no explanation of what 'assets' actually returns, which leaves an agent uncertain about the result. The description also introduces multiple actions while declaring only 'assets' as the flattened one, and it never explains the account parameter, making the tool incomplete for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does link cursor to list, id to get/assets/transactions, and ids to batched execution, which gives real meaning to several parameters. However, 'account' is left completely unexplained, so the compensation is incomplete.

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

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

The description says this is read access to Guru affiliations and identifies 'assets' as the flattened action, so it goes beyond a tautology. However, the action list 'list/get/assets/transactions' muddles what this specific tool does, and 'assets' is never defined, making the purpose less crisp than it could be.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 about when to use this tool instead of sibling tools like guru_affiliations_get, guru_affiliations_list, or guru_affiliations_transactions. The mention of cursor and bulk support hints at usage, but it does not give 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds that it supports bulk execution via ids, which goes beyond annotations. Although it doesn't mention specifics like rate limits or pagination details, the annotations already cover safety, so the description adds some value without contradiction.

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

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

The description is concise and front-loaded with the purpose, but the inclusion of a bracketed flattened action and generic action list adds some clutter. It is not overly verbose, but the structure could be improved by explaining parameters more directly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 4 parameters at 0% coverage, the description is inadequate for agents to fully understand how to invoke the tool correctly. It does not explain return values, pagination behavior, or how to choose between actions. For a complex tool with multiple actions, this is insufficient.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or role of each parameter (id, ids, cursor, account). It only mentions 'ids' for bulk execution and 'id' for get action implicitly. The description fails to compensate for the lack of parameter documentation, leaving agents to infer from names alone.

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

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

The description states it lists affiliations in Guru with a read-only action, and specifies the actions (list, get, assets, transactions) with flattened action 'get'. However, it does not explicitly distinguish from sibling tools like guru_affiliations_list or guru_affiliations_assets, relying on the flattened action to imply it. The purpose is clear but not fully differentiated.

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

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

The description does not provide guidance on when to use this tool versus alternatives. It mentions bulk support (accepts ids for batched execution) but does not explain when to use 'get' vs 'list' or other specific tools. It lacks explicit usage context or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'leitura' (redundant) and bulk behavior 'accepts ids for batched execution', which is useful. It does not explain pagination behavior, return format, or how cursor and ids interact, but the annotations cover the safety profile.

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

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

The description is short and uses line breaks, but it includes an extraneous action list (get/assets/transactions) for a tool that is flattened to list. The 'Ações' list is misleading, and not every sentence earns its place; the first sentence is a fragment.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 0% parameter coverage, the description is incomplete. It does not state what the list returns, how cursor pagination works, or what the account parameter does. Bulk support is a plus, but there are significant gaps for a tool with four undocumented 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 maps cursor to list and ids to batched execution, but leaves id and account completely unexplained. The mention of get/assets/transactions with id only adds confusion for this particular tool.

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

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

The description states 'Afiliações no Guru (leitura)' indicating a read operation for affiliations, and '[Flattened action: list]' clarifies that this specific tool handles the list action. The verb 'list' and resource 'affiliations' are clear, but it does not explicitly differentiate from sibling tools like guru_affiliations_get, relying on the tool name and flattening note.

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

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

Provides some guidance: 'list (cursor)' suggests listing with cursor, and 'Bulk support: accepts ids for batched execution' gives a concrete use case for the ids parameter. However, it does not explicitly state when to use this tool over guru_affiliations_get or guru_affiliations_assets, nor 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 cover readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds the useful 'bulk support' behavior and 'leitura' context, but it does not describe output, scope, endpoint semantics, or what happens when using account. It is consistent with the annotations, so there is no contradiction.

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

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

The text is short and front-loaded with 'leitura,' but the inclusion of a four-action list followed by '[Flattened action: transactions]' is redundant and slightly confusing. It earns some conciseness credit but not full marks because not every phrase adds clarity.

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

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

Given the 0% schema coverage, no output schema, four parameters, and a large family of similar transaction tools, this description does not provide enough context for an agent to confidently invoke the tool. It lacks clear semantics for transactions, account, return values, and relationships to alternative affiliation/transaction endpoints.

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

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

Schema description coverage is 0%, so the description must clarify meaning beyond bare schema properties. It does partially: cursor is connected to list, id to get/assets/transactions, and ids to bulk execution. However, the account parameter is never explained, and the exact roles of the action parameters remain unclear.

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

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

The description identifies the resource broadly ('Afiliações no Guru (leitura)') and points to 'transactions' as the flattened action, so the domain is somewhat clear. However, it never states a concrete operation like 'retrieve transactions for an affiliation,' and the action list 'list (cursor); get (id); assets (id); transactions (id)' blurs whether this is a single-purpose transactions tool or a multi-action 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?

There is some usage signal: action-to-parameter mappings are given (cursor for list, id for get/assets/transactions), and bulk execution is indicated by 'accepts ids.' But nothing says when to choose this over related sibling tools such as guru_transactions_search, guru_contacts_transactions, or guru_subscriptions_transactions, so the tool lacks strong disambiguation.

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

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

Annotations already indicate this is a non-read, non-idempotent write, so the description's added value is mainly the bulk execution behavior and the id/data shape. It does not disclose authentication needs, success/error behavior, or whether setting a commission overwrites an existing 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 short and front-loads the action. The '[Flattened action: set_commission]' line is somewhat redundant with the first sentence, but the overall size is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 an opaque nested data object, the description is under-specified. It lacks information about the commission field format, account semantics, return values, and potential errors, 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?

With 0% schema description coverage, the description adds some meaning for id, data, and ids: data is said to contain the commission, and ids support bulk execution. However, account is not explained, and the internal structure of the data object is left unspecified.

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

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

The description clearly identifies the action as set_commission on Guru affiliations and specifies the basic input shape (id + data with the commission). This distinguishes it from read-oriented siblings like guru_affiliations_get and guru_affiliations_list, though the wording is terse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 primary use case through the action name and mentions bulk execution via 'Bulk support: accepts ids for batched execution.' However, it provides no explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the batch execution capability (accepts ids), which is not present in annotations. It does not describe the return format, but for a get operation this is less critical, and the batch behavior is a useful extra.

Agents need to know what a tool does to the 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. It starts with the purpose, then lists actions, clarifies the flattened action, and mentions bulk support. Each line adds value without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 simple get operation. It covers the main actions and batch support, but does not describe what the tool returns (since there is no output schema) or clarify the 'account' parameter's role. Given the lack of output schema and partial parameter coverage, there is room for more detail, but the core functionality is understandable.

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

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

Schema coverage is 0%, so the description must explain parameters. It does describe 'cursor' as used for list, 'id' for get, and 'ids' for batch, which gives meaning to three of the four parameters. 'account' is not mentioned, but the description partially compensates for the lack of schema documentation. It does not fully document all parameters, hence not a 5.

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

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

The description clearly states that this tool handles 'Listas de bloqueio (anti-fraude) no Guru' and specifies the flattened action as 'get', distinguishing it from the sibling list and write tools. The purpose—retrieving blocklist entries by id or in bulk—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?

The description implies usage by indicating 'get (id)' and mentions bulk support with 'ids', which suggests when to use this tool (when you have an id or want to batch fetch). It does not explicitly state when not to use it (e.g., for listing you'd use guru_blocklists_list), but the mention of the list action and the flattened get action provides sufficient context to differentiate.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful details about cursor-based pagination and the ability to batch by ids, which goes beyond the basic annotations without contradicting 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, consisting of two short sentences that convey the core purpose, actions, and bulk capability without any redundancy or irrelevant information.

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

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

For a list operation, the description covers the essential aspects: listing blocklists, pagination via cursor, and batch retrieval via ids. It lacks details on return structure or filtering options, but given the simplicity and annotations, it is largely complete. The ambiguous 'get' mention slightly 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 input schema lists all four parameters (id, ids, cursor, account) with basic types, but no descriptions. The tool description explains cursor and ids, but leaves id and account ambiguous. Since schema coverage is complete, baseline is 3, and the description adds value for only some 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 it lists anti-fraud blocklists in Guru and mentions cursor-based list and id-based get actions, which distinguishes it from the get tool. However, the 'get (id)' phrase might be slightly confusing as it could imply the tool also performs gets, though the tool name clarifies it's the list variant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the tool name (list vs get) and mentions bulk support with ids, but it does not explicitly state when to use this tool instead of guru_blocklists_get or other list tools. It provides only implicit guidance on pagination and batching.

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

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

Annotations already mark the tool as non-read-only, and the description adds that it performs mutations and supports batched execution via ids. It does not disclose return behavior, account requirements, or idempotency details beyond the annotations, but it does not contradict the provided hints.

Agents need to know what a tool does to the 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 with the domain and action list. The inclusion of update/delete actions is somewhat redundant for a create-specific tool, but overall it is concise and free of unnecessary prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, nested objects, no output schema, and 0% schema description coverage, this short description is not sufficient. It lacks any explanation of return values, the account parameter, the data schema, or clear differentiation from sibling write 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%, so the description carries the burden of explaining parameters. It maps create to 'data' and mentions 'ids' for bulk execution, which is partial help, but it leaves 'id' vs 'ids' relationships, the structure of 'data', and the purpose of 'account' completely unexplained.

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

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

The description clearly identifies the resource (Guru blocklists) and the mutation nature, with 'Flattened action: create' explicitly stating the intended operation. However, it also lists update/delete actions that belong to sibling tools, so it does not clearly differentiate this create-only tool from guru_blocklists_write_update and guru_blocklists_write_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?

Usage context is partially implied: 'create (data)' suggests when to use the data parameter, and 'Bulk support: accepts ids' hints at batch usage. But there are no explicit when-to-use or when-not-to-use instructions, nor any reference to sibling tools for update/delete alternatives.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description confirms it is a mutation tool. However, it does not disclose important details such as whether deletion is permanent, soft-delete behavior, permission requirements, or error handling. The bulk support note is helpful but insufficient for a delete operation that may have irreversible consequences.

Agents need to know what a tool does to the 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 fits in a few sentences, but the structure is awkward. It starts with a vague statement ('Mutações em listas de bloqueio Guru'), then lists actions, then mentions 'Flattened action: delete' and bulk support. The information is not front-loaded or clearly organized, making it harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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-specific tool (given the name and siblings), the description unnecessarily introduces create and update actions, which is misleading. It also lacks information about return values, idempotency (annotations say false), and what happens to existing data. The bulk support note is useful but does not compensate for the missing clarity on the tool's primary purpose.

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

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

Schema coverage is 0%, so the description is the only source of parameter meaning. It partially maps parameters: create uses 'data', update uses 'id'+'data', delete uses 'id', and bulk uses 'ids'. However, it does not explain the 'account' parameter at all, and the mappings are implied rather than explicit. The description adds moderate value but leaves significant gaps.

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

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

The description states it handles mutations in Guru blocklists and lists create/update/delete actions, but the tool name and sibling tools (guru_blocklists_write_create, guru_blocklists_write_update) clearly indicate this is specifically for deletion. The description fails to clearly state that this tool is for delete operations only, instead listing all actions ambiguously. The phrase 'Flattened action: delete' is confusing rather than clarifying.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 sibling create/update tools. It does not mention that for creating blocklists one should use guru_blocklists_write_create, or for updating use guru_blocklists_write_update. The description lists all three actions, making it unclear which tool should be chosen for a given operation.

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

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

The description adds useful behavioral details beyond the annotations: it indicates the operation is a mutation, lists parameter patterns for create/update/delete, and mentions bulk support via 'ids'. However, it does not disclose side effects, whether updates are partial or full replacements, authorization requirements, or error behavior. The annotations already indicate readOnlyHint=false and idempotentHint=false, but the description adds action-specific context. No direct contradiction with annotations is found because the '[Flattened action: update]' clarifies the destructive delete action is not the primary behavior of this tool.

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

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

The description is compact (two short paragraphs plus a note) and conveys core information without fluff. The structure with action list and bulk support note is reasonably organized, though the '[Flattened action: update]' line feels like an artifact and adds minor confusion. Each sentence contributes value, so it earns a high but not 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 write/update operation with a free-form data object and bulk execution, but the description lacks critical context: what fields the data object should contain, whether the update replaces the entire record or just provided fields, what happens if the id does not exist, authentication/permission requirements, and return value/errors. With no output schema and minimal annotations, this is insufficient for an agent to invoke the tool correctly in non-trivial 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?

With 0% schema description coverage, the description must explain parameters. It does explain that update uses 'id + data', and bulk execution accepts 'ids', covering three of the four parameters. However, 'account' is never mentioned, and the content of 'data' is left to the schema's generic object type. The mapping is helpful but not detailed enough to fully compensate for 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 it performs mutations on Guru blocklists and lists create/update/delete actions, but then adds '[Flattened action: update]' to indicate this instance is for update. This is confusing because it initially seems to support all three actions, making the actual purpose (update) ambiguous. The resource (blocklists) is clear, but the specific verb is muddled by the conflicting action 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?

No explicit guidance is given on when to use this tool versus the sibling write_create or write_delete tools. The description lists all three actions but does not say 'use this tool to update; use write_create to create; use write_delete to delete'. The reliance on the tool name and '[Flattened action: update]' is implicit, not 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?

Annotations provide no safety hints (all false) and the description adds little behavioral context. It indicates a POST request, which implies a write, but does not explain side effects, required permissions, or response behavior. The description relies on the endpoint without enriching the agent's understanding of consequences.

Agents need to know what a tool does to the 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 (one sentence), but it omits essential details like the account parameter and the shape of 'data'. It is front-loaded with the endpoint, yet under-specification prevents it from being an effective single-sentence summary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 a nested object parameter, no output schema, and no parameter descriptions, the description is too sparse. It does not mention the 'account' parameter, possible return values, or differentiate among the many offer/checkout siblings. The endpoint hint is useful but insufficient for an agent to invoke the tool correctly.

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

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

Schema coverage is 0% and the description only mentions 'data com os parâmetros da oferta' (data with offer parameters), which vaguely maps to the 'data' param. The 'account' param is undocumented, and the structure of the data object is not explained. The description barely compensates for the schema's silence.

Input schemas describe structure but not intent. Descriptions should explain 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 consults/configures offer settings in Guru checkout, with a specific endpoint (POST checkout/offers/settings). It identifies both a verb and a resource, distinguishing it from most sibling tools except those dealing with offers/checkout options, which remain undifferentiated.

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

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

No explicit guidance on when to use this tool versus alternatives. The description mentions resource and action but does not state prerequisites, exclusions, or contrast with similar sibling tools like guru_products_offer_checkout_options.

Agents often have multiple tools that could apply. Explicit usage 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, so the safety profile is clear. The description adds that it supports bulk execution via ids, which is useful, but doesn't detail behavior like pagination or response format.

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

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

The description is compact but includes a list of actions that may be redundant given the tool name. The flattened action note is confusing. It's not front-loaded with the most critical info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 9 parameters, no output schema, and no parameter descriptions, the description is insufficient. It doesn't explain what affiliations are returned, how to use cursor for pagination, or what the 'account' parameter does. 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 lists parameter names (email, doc, name, created_at_ini/end, cursor) but doesn't explain their semantics or how they relate to the affiliations action. The 'id' parameter is mentioned but not 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 states it's for reading contacts/clients in Guru and lists actions including affiliations, but the tool name already implies affiliations. It doesn't clearly distinguish from sibling tools like guru_affiliations_get or guru_contacts_get, and the flattened action is ambiguous.

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

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

No guidance on when to use this tool vs alternatives. The description lists actions but doesn't explain when to use affiliations vs other contact-related tools. No exclusions or context 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, destructiveHint=false, and idempotentHint=true, matching the description's 'leitura' (read). The description adds the 'Bulk support' feature but does not disclose additional behavioral aspects like authentication, rate limits, or response format. It adds minimal value beyond annotations.

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

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

The description is concise, front-loading the read-only purpose and then listing actions and bulk support. It is efficient with no redundant sentences, though the formatting could be more structured with bullet points for clarity.

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

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

The tool complex with 9 parameters, no output schema, and multiple actions. The description does not explain how to select an action (no action parameter in schema), nor does it describe return values, pagination, or error handling. It is incomplete for an agent to correctly invoke specific actions 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?

The description maps several parameters to actions (e.g., search uses email, doc, name, created_at_ini/end, cursor; get uses id) and mentions 'ids' for bulk. This provides some meaning beyond the bare schema, which has 0% coverage. However, not all parameters are explained (e.g., account) and the mapping is not comprehensive, leaving ambiguity about which parameters apply to which action.

Input schemas describe structure but not intent. Descriptions should explain 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's a read-only tool for contacts in Guru with a list of actions, which gives a general purpose. However, it lacks a clear single verb+resource focus and does not differentiate from sibling tools like guru_contacts_get or guru_contacts_search. The name suggests a focus on etickets, but the description lists multiple actions, causing ambiguity.

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

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

The description mentions 'Bulk support: accepts ids for batched execution', which hints at a batch use case, but it does not provide explicit guidance on when to use this tool over the specific sibling tools for each action. No when-not or alternative recommendations 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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'leitura' is consistent with those. The added 'Bulk support: accepts ids' provides some extra behavioral context beyond the annotations, but the list of unrelated actions makes the actual behavior less transparent than it could be.

Agents need to know what a tool does to the 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 with the resource and read intent. The action list and bulk note are terse, though the action list arguably adds noise for a tool annotated as a flattened get.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 9-parameter tool with no output schema and no per-parameter documentation, this description is insufficient to confidently invoke the tool. It does not specify which of the search-oriented parameters are valid for the flattened get action, what the return shape is, or what 'account' means.

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

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

With 0% schema description coverage, the description carries the full burden, but it only groups parameter names under actions (email/doc/name/created_at_ini/end/cursor for search; id for get; ids for bulk). It omits the 'account' parameter entirely and never explains formats, requiredness, or which parameters actually apply to the flattened get action.

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

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

The description opens with 'Contatos/clientes no Guru (leitura)', establishing a read operation on contacts. However, it then lists search, transactions, subscriptions, affiliations, and etickets as 'Ações' before saying '[Flattened action: get]', which muddles whether this tool is for get-by-id or a broader read facade. It does not clearly distinguish itself from sibling tools like guru_contacts_search.

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

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

Usage is only implied: 'get (id)' and 'Bulk support: accepts ids' suggest this is for single or batched contact retrieval by id. There is no explicit when-to-use versus guru_contacts_search, guru_contacts_transactions, guru_contacts_subscriptions, or guru_contacts_affiliations, and the presence of 'search' in the action list blurs the boundary.

Agents often have multiple tools that could apply. Explicit usage 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 'leitura' (read-only) and mentions bulk support, adding some transparency beyond the annotations. However, the annotations already indicate read-only, idempotent, and non-destructive behavior. The description does not elaborate on other behavioral aspects such as pagination or error handling, but it does reinforce the read-only 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 concise and contained within a single sentence, listing actions and filters in a compact manner. The structure is somewhat cluttered due to listing multiple actions, but it remains efficient and does not have redundant content. It effectively communicates the essential information without excessive verbosity.

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

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

While the description is brief and lacks details about the output format or pagination behavior, it does include the cursor parameter and mentions bulk support, implying some pagination capability. Given that the tool is a straightforward search operation with an implicit output of matching contacts, the description is reasonably complete for its simplicity, though it could benefit from clarifying what is returned or how cursor is used.

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

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

The description lists the search filters: email, doc, name, created_at_ini/end, cursor, and mentions 'ids' for bulk support, covering approximately 7 of 9 schema parameters. It does not explain the 'account' parameter or describe the exact purpose of each filter (e.g., that created_at_ini/end define a date range). The description adds some meaning but not comprehensive parameter explanations.

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

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

The description clearly states that this tool handles contacts in read-only mode and identifies the primary action as 'search' with specific filter parameters. It distinguishes itself from other contact operations by explicitly listing the search action, though listing multiple actions (search, get, transactions, etc.) in the same description introduces some ambiguity that is partially resolved by the tool name and [Flattened action: search].

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

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

The description provides the search filter parameters and notes bulk support for ids, giving some guidance on when to use this tool. However, it does not explicitly contrast with alternative tools like guru_contacts_get, leaving the user to infer that search is for finding contacts while get is for retrieving by id. The guidance is implied 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to repeat that. The description adds 'leitura' (read) which aligns with annotations, and 'Bulk support: accepts ids' provides extra info about batch behavior not present in annotations. No contradiction.

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

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

The description is compact but structurally messy. It packs a list of actions and parameters in a compressed format without clear headings or separation. The '[Flattened action: subscriptions]' note is cryptic and could be clearer. While it is not overly long, the lack of organization reduces comprehensibility.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 9 optional parameters and multiple implied actions, the description is insufficient. It does not explain return values, how cursor pagination works, which combinations of parameters are valid, or how to choose among actions. With no output schema and no additional context, an agent cannot reliably invoke this tool for a specific need like 'get subscriptions for contact X'.

Complex tools with many parameters or behaviors need more documentation. 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 maps some parameters to actions (e.g., 'search (email, doc, name, created_at_ini/end, cursor)' and 'get (id)'), but it omits parameters like 'account' and does not explain how to select an action (since no action parameter exists). The bulk support via 'ids' is mentioned, but details on required fields per action are missing. The description adds some meaning but is incomplete against a 9-parameter schema.

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

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

The description opens with 'Contatos/clientes no Guru (leitura)' which is a broad noun phrase rather than a specific verb+resource. It lists multiple actions (search, get, transactions, subscriptions, affiliations, etickets) but the tool name is 'guru_contacts_subscriptions', creating ambiguity about the primary purpose. The '[Flattened action: subscriptions]' note partially clarifies but does not fully disambiguate from sibling tools like guru_contacts_search or guru_subscriptions_get.

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

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

No guidance on when to use this tool versus the many sibling tools that specialize in specific actions (e.g., guru_contacts_get, guru_contacts_search, guru_contacts_affiliations). The description does not mention alternatives or exclusions (e.g., 'use for subscriptions only' or 'prefer dedicated tools for other actions'). Context is unclear for an agent deciding which tool to call.

Agents often have multiple tools that could apply. Explicit usage 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=true, idempotentHint=true, destructiveHint=false, which are consistent with the description's 'leitura' (reading). The description adds 'Bulk support: accepts ids for batched execution', which is a useful behavioral disclosure beyond annotations. However, it does not describe the return format or any error behavior. It also lists multiple actions (search, get, transactions, etc.) in the description, implying the tool can perform multiple operations, but the flattened action is transactions, so the description is ambiguous about what the tool actually does. Since annotations already establish safety (read-only, idempotent), the description's contribution is minimal and partially confusing.

Agents need to know what a tool does to the 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 cluttered list of actions and parameters, which is not concisely structured. It is front-loaded with 'Contatos/clientes no Guru (leitura)' but then dumps a list of actions with parameters in parentheses, which is hard to parse. The 'Flattened action: transactions' line is confusing because it suggests that despite listing multiple actions, the tool actually only does transactions. The bulk support note is a separate sentence. This structure does not help an agent quickly understand the tool's core purpose. It could be rewritten as a clear statement of the primary function with parameter details.

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

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

The tool has no output schema, and given the complexity of transactions (likely returning transaction details), the description is incomplete. It does not describe what the tool returns when given an 'id' or 'ids'. It also fails to explain the relationship between the 'transactions' action and the other actions listed, which is confusing. The annotations provide safety but not operational detail. The description should clarify the input requirements and output expectations for the transaction action, especially since bulk support is mentioned.

Complex tools with many parameters or behaviors need more documentation. 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. The description mentions parameters like 'search (email, doc, name, created_at_ini/end, cursor); get (id); transactions (id); subscriptions (id); affiliations (id); etickets (id)' and 'Bulk support: accepts ids for batched execution'. However, it does not explain the meaning of each parameter beyond listing them. For the flattened transaction action, it expects 'id' or 'ids', but the description does not clarify what each parameter represents (e.g., what does 'id' refer to? A contact ID? A transaction ID?). The description adds some value by specifying which parameters are used for which sub-action, but it fails to provide sufficient semantics for the core action 'transactions'.

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

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

The description is a list of actions the tool supports, with the primary action being 'transactions' (flattened action). It identifies a specific resource (contacts in Guru) and the main action is transactions, but it's cluttered with multiple other actions (search, get, subscriptions, etc.) that are likely separate tools in the sibling list (e.g., guru_contacts_search, guru_contacts_get). This muddies the purpose. The description does not clearly state that this tool exclusively handles transactions for a contact; it bundles multiple actions, making it unclear what distinguishes this tool from its 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 lists acceptable parameters for the flattened action (id, ids) and mentions bulk support, but it does not explicitly state when to use this tool versus alternatives like guru_contacts_search or guru_contacts_get. There is no mention of when not to use it or any alternatives. The presence of sibling tools like guru_contacts_get, guru_contacts_search, guru_contacts_affiliations, etc., suggests this tool is for a specific action, but the description fails to clarify which action is this tool's primary purpose and when to choose it over others.

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

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

The description states 'anonymize (id, LGPD, irreversível)' indicating the operation is irreversible, while the annotation destructiveHint is false. This is a direct contradiction; the annotation implies the tool is not destructive, but the description says it is irreversible. Additionally, the description does not disclose other behavioral aspects such as side effects, permission requirements, or what happens to associated data. With readOnlyHint false, it is clearly a write, but the irreversibility is not reflected in annotations.

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

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

The description is not concise; it lists four actions when the tool is specifically for anonymize, adding noise. The structure with bullet points and '[Flattened action: anonymize]' is somewhat clear but unnecessarily verbose. A simple statement like 'Anonymize a Guru contact (LGPD, irreversible). Accepts id or ids for batch.' would be more efficient and focused.

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

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

Given the tool has 4 parameters, no output schema, and weak annotations, the description is insufficient. It mentions LGPD and irreversibility but does not explain the intended use case, prerequisites, or consequences beyond irreversibility. It lacks details about return value, error conditions, or how the anonymization affects related data. The bulk support is mentioned but not elaborated (e.g., limits, behavior). Overall, the description does not provide enough context 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%, so the description must compensate. The description mentions id and ids (for bulk), but does not explain the data or account parameters. For an anonymize operation, data and account remain ambiguous; they might be irrelevant or required but unexplained. The description provides some meaning for id (the contact to anonymize) and ids (batch), but leaves the other half undocumented.

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

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

The description lists multiple mutation actions (create, update, anonymize, create_etickets) but does not explicitly state that this tool is specifically for anonymization. The flattened action annotation provides a hint, but the description's main clause is generic ('Mutações em contatos Guru') and lists several actions, obscuring the singular purpose of anonymizing a contact. It does mention 'anonymize (id, LGPD, irreversível)' which clarifies the function, so it is not a tautology but lacks a clear, focused statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 alternatives like guru_contacts_write_update or guru_contacts_write_create. The description mentions bulk support but does not compare with other contact mutation tools or explain scenarios where anonymization is appropriate. The list of actions (create, update, create_etickets) in the description could mislead an agent into thinking this tool performs all those actions, rather than being solely for anonymize.

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

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

The annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds some useful context, like bulk support and the fact that anonymization is LGPD-related and irreversible; however, those extra points concern other actions, not the current flattened create tool. It does not describe the outcome or any side effects of a create call.

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

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

The description is short and somewhat front-loaded, but it spends most of its space listing actions that are not part of this flattened create tool. The phrase '[Flattened action: create]' adds confusion rather than practical meaning, while the bulk-support line is concise and 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 create endpoint with 4 parameters, one nested object, and no output schema, the description is materially incomplete. An agent gets the general area of functionality but not enough information to correctly construct a create request, especially regarding required data fields or account 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?

With schema description coverage at 0%, the description must compensate for the missing parameter explanations. It explains only that `data` is used for create and that `ids` enable bulk execution; `id` and `account` are left unexplained, and the structure of `data` is not described. This is insufficient for a 4-parameter nested-object 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 says 'Mutações em contatos Guru' and lists multiple actions (create, update, anonymize, create_etickets), but it does not clearly state that this specific tool creates a single contact. The bracketed '[Flattened action: create]' helps, but the remaining action list creates ambiguity and fails to distinguish this tool cleanly from its sibling write tools.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as guru_contacts_write_update or guru_contacts_write_anonymize. It implies the create action takes `data` and that bulk execution can use `ids`, but the unqualified list of actions is misleading: the agent cannot confidently know this tool is only for creating contacts.

Agents often have multiple tools that could apply. Explicit usage 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 the behavioral detail of bulk execution support, which annotations do not provide. It also labels the operation as a mutation, consistent with readOnlyHint false. However, it does not disclose potential side effects (e.g., sending emails, triggering events) or clarify whether the operation is reversible, though destructiveHint false suggests non-destructive. Beyond bulk support, transparency is limited.

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

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

The description is relatively short but includes a list of all actions from the original parent tool (create, update, anonymize) that are not relevant to this flattened action. This extraneous content adds clutter and could confuse the agent. The flattened action clarification is helpful, but the structure could be tightened to focus solely on create_etickets and its parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, a nested 'data' object, and no output schema, the description does not provide enough context for proper invocation. It leaves 'account' unexplained, gives no detail on the required structure of 'data', and says nothing about return values or side effects. While bulk support is mentioned, the overall completeness is insufficient for a write operation with a nested schema.

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

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

The description explains that create_etickets uses 'id + data' and mentions 'ids' for bulk support, providing some meaning beyond the schema. However, it does not describe the 'account' parameter at all, and gives no detail on the structure of 'data' (what fields are expected for eticket creation). Since schema coverage is 0%, the description only partially compensates, leaving several 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 identifies the action as 'create_etickets' via the flattened action note, and names both the resource (contacts Guru) and the operation. However, the initial listing of multiple actions (create, update, anonymize, create_etickets) without immediately focusing on the intended one creates slight ambiguity, even though it is resolved later.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 hints at when to use this tool (e.g., for processing multiple contacts at once). However, it does not provide explicit guidance on choosing this tool over siblings like guru_etickets_write_create_invitations or when not to use it, nor does it mention any prerequisites or use cases.

Agents often have multiple tools that could apply. Explicit usage 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 non-read-only, non-idempotent, non-destructive. The description adds bulk support but no details on update semantics (e.g., partial vs. full update, whether data merges or replaces, side effects). The mention of anonymize being irreversible is irrelevant to this tool.

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

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

The description is not concise because it includes a list of actions that are not relevant to this tool (create, anonymize, create_etickets) before the flattened action note. This wastes space and muddies the message.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 annotations describing behavior, the description is severely lacking. It does not explain what happens on update, how to construct data, whether updates are idempotent, or any edge cases. The bulk support is the only concrete addition.

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

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

Schema coverage is 0%, so the description must explain parameters. It maps id and data to update, and ids for bulk, but does not explain the 'account' parameter. It also does not clarify the structure or constraints of 'data', leaving significant gaps.

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

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

The description lists multiple actions (create, update, anonymize, create_etickets) but then states '[Flattened action: update]', creating ambiguity about whether this tool handles all or only update. The name clearly indicates update, but the extra actions confuse rather than clarify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 update versus the sibling tools (guru_contacts_write_create, guru_contacts_write_anonymize, etc.). It mentions bulk support but gives no context on when bulk is appropriate or any 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 covered. The description adds minimal context by saying this is location data and that address lookup uses zipcode/CEP BR, but it does not explain outputs, validation behavior, or why three actions appear in a flattened tool. No contradiction with annotations was 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 general purpose, which is good, but the '[Flattened action: address]' fragment is cryptic and does not earn its place. The compactness helps, but the ambiguity of listing multiple actions in a single flattened tool prevents a higher 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 three optional parameters, zero schema descriptions, no output schema, and sibling tools for country/states, the description is not complete enough. It fails to clarify the account parameter, the exact selection mechanism for list/states/address, or how this tool differs from guru_countries_list and guru_countries_states.

Complex tools with many parameters or behaviors need more documentation. 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 partial meaning for country ('ex.: BR') and zipcode ('CEP BR'), but it does not explain the 'account' parameter at all, nor how action selection maps to parameters. The agent is left guessing which parameter to provide for which outcome.

Input schemas describe structure but not intent. Descriptions should explain 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 it provides 'auxiliary location data' and lists three actions (list, states, address), but it does not clearly state which action this tool performs. The tool name and '[Flattened action: address]' hint at address lookup, yet the description concurrently advertises country/states actions, creating ambiguity and failing to distinguish from siblings like guru_countries_list and guru_countries_states.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 sibling tools. The sibling list includes guru_countries_list and guru_countries_states, but the description never tells an agent to use those for country/states instead, or to use this tool only for address/CEP lookup. The usage context is only implied by action labels, not stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only behavior is established. The description adds minimal behavioral context—only that the data is auxiliary location data and the action is list—without disclosing return format, pagination, ordering, or any limitations.

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

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

The description is short, but it spends space enumerating states and address actions that belong to sibling tools, and it includes the technical artifact '[Flattened action: list]', which adds noise without helping an agent understand the tool's purpose or invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 0% parameter description coverage, the description should clarify what the list response contains and whether the optional parameters affect results. It does neither. The simple read-only domain and strong annotations prevent a score of 1, but the missing return and parameter semantics leave the tool 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?

Schema description coverage is 0%, so the description carries the burden for explaining parameters. It explains country and zipcode only in the context of other actions (states and address), not for the flattened list action, and the 'account' parameter is never mentioned at all.

Input schemas describe structure but not intent. Descriptions should explain 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 identifies the domain as Guru auxiliary location data and specifies the flattened action as 'list (países)', indicating the tool lists countries. It distinguishes from sibling tools like guru_countries_states and guru_countries_address by naming those actions, though including them in the description introduces some ambiguity about the current tool's exact scope.

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

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

The description offers an implied mapping between actions and parameters ('states (country, ex.: BR); address (zipcode/CEP BR)'), which hints at when related endpoints are relevant. However, it never explicitly states when to use this list tool versus the sibling guru_countries_states or guru_countries_address tools, nor does it provide 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, so the safety profile is clear. The description adds the useful context that this is the flattened 'states' action and gives example inputs, but it does not describe return data, error behavior, or any operational constraints. No contradiction with annotations is present.

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

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

The description is short and front-loaded, with no filler words. The compact notation and bracketed flattened-action note are somewhat cryptic, but the text earns its place and avoids 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 read-only tool with no output schema, the description gives enough to guess the states lookup, but it overcomplicates the picture by listing multiple actions while only the states action is flattened here. It also omits expected return shape and the role of the account parameter, leaving the tool under-specified 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 provides some parameter semantics: 'country, ex.: BR' clarifies the country parameter, and 'zipcode/CEP BR' clarifies the zipcode parameter. However, the 'account' parameter is left unexplained, and the action list does not map cleanly onto the three schema properties.

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

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

The description identifies the domain as 'auxiliary Guru location data' and lists list/states/address actions, but it does not state a crisp verb+resource for this specific tool. The '[Flattened action: states]' note suggests this tool is for fetching states, yet the multi-action text makes the purpose ambiguous and fails to distinguish it from sibling tools like guru_countries_list and guru_countries_address.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 practical examples ('country, ex.: BR', 'zipcode/CEP BR') and names the available actions, which implies when to use the tool. However, it does not explicitly say when to use this flattened states tool instead of the sibling list/address tools, nor does it specify 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?

The description and annotations agree on read-only and non-destructive behavior. However, details about bulk execution semantics, rate limits, or whether the 'audits' action returns historical data are absent, leaving behavioral edges unclear.

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

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

The description is short but redundant, repeating 'audits' in the action list and the flattened action note. It could be more concise by focusing on the primary purpose and eliminating the generic action list.

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

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

Given the tool appears to be a multi-action wrapper (especially for audits with bulk support), the description lacks context on expected outputs, error handling, or how the actions are invoked (e.g., whether a single call can mix actions). This leaves 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?

The schema lists four parameters without descriptions. The description partially explains relationships (cursor for list, id for get/audits/transactions), but the 'account' parameter is unexplained, and the distinction between 'id' and 'ids' is not elaborated. Coverage is below 50%.

Input schemas describe structure but not intent. Descriptions should explain 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 is read-only and lists actions (list, get, audits, transactions), but the tool name suggests it is specifically for audits, creating ambiguity about the primary purpose. The phrase 'Cupons no Guru (leitura)' makes read-only clear, but the multi-action list dilutes focus.

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

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

No explicit guidance on when to use this tool versus sibling tools like guru_coupons_get or guru_coupons_list. The mention of bulk support for ids is a hint, but it does not clarify which action is appropriate for which scenario or how it relates to other coupon tools.

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

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

The description adds useful context about bulk support (accepts ids) and indicates read-only behavior ('leitura'), which aligns with annotations. However, it does not clarify the action confusion, and the bulk behavior details are minimal. Since annotations already declare readOnlyHint and idempotent, the description adds some value but not much depth.

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

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

The description is short but poorly structured. It front-loads a list of actions that may not all belong to this tool, and the real purpose ('get') is buried in a bracket. It is not concise in a helpful way; each phrase is ambiguous and could mislead.

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

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

With 4 parameters, no output schema, and no parameter descriptions, the description should be comprehensive. It does not describe return values, pagination behavior, or how bulk execution works. It also fails to differentiate from siblings, making it incomplete for effective selection and 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 explain parameters. It maps cursor to list, id to get/audits/transactions, and mentions ids for bulk, but this is ambiguous because the tool only supports get. It does not explain 'account'. The description fails to provide clear parameter semantics, especially given the mixed action list.

Input schemas describe structure but not intent. Descriptions should explain 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 'Cupons no Guru (leitura)' (reading coupons) and lists multiple actions (list, get, audits, transactions), but it's unclear that this tool specifically performs 'get'. It mentions [Flattened action: get] but doesn't clarify that the other actions are not performed here. This is vague and potentially misleading given the sibling tools for list, audits, and transactions exist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 instead of the sibling tools. It lists several actions without explaining which one this tool actually executes. No mention of alternatives like guru_coupons_list or guru_coupons_audits, nor any exclusions. This leaves the agent without clear direction.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds 'leitura' (read) and mentions bulk execution, but these do not contradict annotations and offer minimal additional transparency about 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 but poorly structured, listing multiple actions before flattening to 'list'. This creates confusion rather than clarity. The key information (that it lists coupons) is buried in Portuguese and redundancy.

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

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

Given the simplicity of a list operation, the description is incomplete: it does not clearly state what is returned, how pagination works, or what 'account' filters mean. The contradictory action list 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 schema has four parameters (id, ids, cursor, account). The description only indirectly mentions id and ids via the action list and 'bulk support', and cursor is referenced as part of 'list (cursor)', but account is completely unexplained. Coverage is low and confusing.

Input schemas describe structure but not intent. Descriptions should explain 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 'Cupons no Guru (leitura)' (read coupons) but then lists multiple actions (list, get, audits, transactions) before clarifying '[Flattened action: list]'. This ambiguity obscures the actual purpose, which is to list coupons, and fails to distinguish it from sibling tools like guru_coupons_get.

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

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

No explicit guidance on when to use this tool versus alternatives. It mentions bulk support for ids, but does not explain scenarios (e.g., listing vs. fetching a single coupon) or how it relates to other coupon tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context by listing supported actions with their expected parameters and by disclosing bulk support for batched execution. It does not contradict 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 compact and front-loaded with the resource and read-only nature. The action enumeration and bulk-support note are concise. The phrase '[Flattened action: transactions]' is jargon that adds little clarity, but overall there is no wasteful 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 descriptions in the input schema, the description is not complete enough for confident invocation. It lacks return-value behavior, account parameter semantics, pagination details beyond 'cursor', and any mention of how this tool relates to sibling coupon/transaction 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%, so the description must compensate. It partially does by mapping cursor to list, id to get/audits/transactions, and ids to bulk execution. However, it completely omits the 'account' parameter and provides no types or constraints beyond these implicit mappings, leaving a significant semantic 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 identifies the resource (Guru coupons) and the read-only nature, and lists possible actions including transactions, but it does not explicitly define what the core 'transactions' action does beyond the tool name. The enumeration of multiple actions (list, get, audits, transactions) makes the specific purpose less crisp than a single verb+resource statement.

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

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

The description provides an internal action-to-parameter mapping (list uses cursor; get/audits/transactions use id) and mentions batch support with ids, but it gives no guidance on when to use this tool versus alternatives like guru_coupons_get, guru_coupons_audits, or guru_transactions_get. There are no exclusions or preferred use-case 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 adds minimal behavioral context beyond what annotations already convey (readOnlyHint=false, destructiveHint=false). It states 'Mutações' which implies modification, and mentions bulk support, but does not disclose side effects, idempotency, or specific behaviors of creation (e.g., whether a duplicate is rejected, if there are rate limits, or what happens on partial bulk failures). With annotations present, the description adds little value.

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

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

The description is brief but poorly structured. It front-loads a generic mutation statement and lists multiple actions that are not all relevant to this tool, causing confusion. The '[Flattened action: create]' note is helpful but buried. It is not concise in the sense of being focused; it includes extraneous information that detracts from clarity.

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

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

For a mutation tool with 4 optional parameters, no output schema, and no enums, the description fails to provide essential context. It does not explain what a coupon is, what fields are required in 'data', what account refers to, or how bulk creation works. Given the complexity and the lack of schema documentation, this description is severely incomplete for an agent to use correctly.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter documentation. However, it only lists parameters in the action signatures (e.g., 'create (data)') without explaining the structure of 'data', the purpose of 'account', or how 'ids' work for batching. It does not add semantic meaning beyond what the schema property names provide. 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 starts with a generic 'Mutações em cupons Guru' (mutations in Guru coupons) and lists multiple actions (create, update, delete, duplicate, set_activation). However, it includes '[Flattened action: create]', which clarifies that this specific tool performs the create action. This is not a tautology, but it is ambiguous and does not clearly state 'create a new coupon' as the primary purpose, making it somewhat confusing despite 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?

There is no explicit guidance on when to use this tool versus its siblings (e.g., guru_coupons_write_update, guru_coupons_write_delete). The description mentions 'Bulk support' via ids but does not explain when bulk creation is appropriate or that this tool is only for creation and not other mutations. The flattened action note is implicit guidance, but it lacks explicit directives 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 declare destructiveHint=false, but the description explicitly advertises 'delete (id)' and '[Flattened action: delete]'. This is a direct annotation contradiction. The description also fails to disclose irreversibility, bulk-failure behavior, account requirements, or what happens to the coupon.

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

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

The description is short but not well-focused: it lists all coupon mutation actions even though this is a delete tool, and the cryptic '[Flattened action: delete]' adds confusion rather than clarity. The bulk-support sentence is the only clearly relevant structural element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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/delete tool with four parameters, no output schema, and minimal annotations, the description is incomplete. It omits return values, error behavior, bulk semantics (all-or-nothing vs partial), account usage, and any prerequisites. The provided information covers only the bare essentials.

Complex tools with many parameters or behaviors need more documentation. 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 maps 'id' to delete and mentions 'ids' for bulk execution, but it does not explain the 'account' parameter, whether 'data' is accepted or ignored for delete, or which parameters are required. This is only partial coverage of the four 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 does mention 'delete (id)' and '[Flattened action: delete]', so the intended action is discernible. However, it also lists create, update, duplicate, and set_activation actions, making the specific purpose of this delete-specific tool ambiguous and failing to distinguish it from the sibling coupon write tools.

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

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

There is no explicit guidance about when to use this tool versus alternatives like guru_coupons_write_create, guru_coupons_write_update, or guru_coupons_write_duplicate. The only usage hint is 'Bulk support: accepts ids', which does not compensate for the lack of 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 declare this is a non-read-only, non-idempotent mutation, so the description does not need to re-explain mutation. It adds useful context about batched execution via `accepts ids`, but it does not describe return values, side effects, permissions, or what happens after duplication beyond the action name.

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

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

The description is short and front-loads the generic mutation context, but it repeats several unrelated actions (create, update, delete, set_activation) before narrowing to `duplicate`. It is not bloated, yet some text could be trimmed to focus more directly on the single flattened action.

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

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

The description is minimal and incomplete for safely invoking the tool: there is no required-parameter guidance, no explanation of `account`, no clear role for `data`, and no description of the result or error behavior. A duplication tool with 4 parameters and no output schema needs more detail than this.

Complex tools with many parameters or behaviors need more documentation. 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 needs to compensate for all four parameters. It clarifies `id` and `ids` reasonably through `duplicate(id)` and bulk support, but `account` and `data` are not explained in the context of this duplicate 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 identifies this as a mutation tool for Guru coupons and includes `[Flattened action: duplicate]` plus `duplicate(id)`, so an agent can see this is the duplicate operation. However, the generic action list also mentions create/update/delete/set_activation, which somewhat dilutes the singular focus and makes sibling differentiation less crisp.

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

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

The description implies when to use the tool through `duplicate(id)` and bulk support with `ids`, giving useful operational context. However, it does not explicitly say when to prefer this over sibling actions like `guru_coupons_write_create` or `guru_coupons_write_update`, and there are no exclusions or alternative-tool recommendations.

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

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

Beyond stating it's a mutation and supports bulk, the description reveals little about side effects, reversibility, or validation behavior. Annotations provide no hints, so the description carries the burden but adds minimal insight.

Agents need to know what a tool does to the 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 redundantly lists all coupon mutation actions (create, update, delete, duplicate) even though this tool is specifically set_activation. This extra information could confuse and detracts from the core purpose.

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

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

Given the schema has no descriptions and there is no output schema, the description should thoroughly explain inputs and expected behavior. It lacks details on the activation flag format, handling of id vs ids, and account parameter, leaving 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?

The schema has no descriptions for parameters, and the description only loosely mentions 'id + data' for set_activation without explaining what fields data should contain (e.g., an 'active' flag) or the role of account. Insufficient compensation for missing schema 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 explicitly states it is for mutations on Guru coupons and clarifies that the specific action is set_activation, distinguishing it from sibling coupon write tools like create, 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?

It mentions bulk support via ids but does not clearly explain when to use set_activation versus other mutations (e.g., update) or how the data parameter should be structured to trigger activation changes. Lacks explicit 'use this when...' 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 only declare readOnlyHint=false, leaving the safety profile undeclared. The description adds value by revealing this is a multi-action mutator that can also delete and activate/deactivate coupons, and that it supports batched writes. However, it doesn't disclose side effects, idempotency of retries, or whether batched execution is atomic — notable gaps for a tool that can trigger deletes.

Agents need to know what a tool does to the 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 — a one-line summary, a terse action list with per-action parameter shapes, and a two-word bulk note — with no wasted filler. It loses one point because the five actions are tightly packed into a parenthetical list that blends action semantics with transport detail, making it slightly dense to parse at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 there is no output schema and no informative annotations, the description must explain return behavior, error semantics, and the meaning of the 'data' structure, but it doesn't. The note that this operation can mutate and even delete resources heightens the need to document failure modes and atomicity, which is absent — leaving a destructive, batched tool 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 coverage, the description carries the full burden and does compensate meaningfully: it maps id/data to specific actions and explains that 'ids' enables bulk execution. However, the 'account' parameter is completely undocumented, and the 'data' structure for set_activation (explicitly noted as ativa/desativa) is only hinted at. Partial but useful compensation for a fully undocumented schema.

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

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

The description clearly identifies this as 'Mutações em cupons' (coupon mutations) and explicitly enumerates the five actions (create, update, delete, duplicate, set_activation) plus bulk execution. The '[Flattened action: update]' note and mapping of actions to parameter shapes (id vs id+data) distinguish it from sibling tools like guru_coupons_write_delete and guru_coupons_write_duplicate, making the resource and scope unambiguous.

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

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

The description gives usage context by listing which parameters each action requires and noting bulk support ('accepts ids for batched execution'), which implies when to use ids vs singular mutations. However, it never explicitly names sibling alternatives or states when NOT to use this tool (e.g., for create/delete you should call the specific sibling), leaving usage inference implicit.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by mentioning 'leitura' (reading) and 'status de check-in', implying it retrieves check-in status rather than modifying anything. It does not contradict annotations, but the description is thin—it could mention that it returns status without changing state. Given the annotations, the bar is lower, so a 3 is appropriate.

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

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

The description is short but poorly structured and confusing. It mixes Portuguese and English, lists multiple actions then abruptly says 'Flattened action: check_in', which creates ambiguity rather than clarity. It is not front-loaded with the actual purpose and reads more like internal notes than a user-facing description.

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

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

With 3 parameters, no output schema, and 0% schema coverage, the description is extremely incomplete. It fails to explain what the tool returns, what each parameter does, or how it relates to other e-ticket operations. The lack of any return-type or behavior description makes it insufficient for an agent to confidently invoke the tool.

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

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

Schema description coverage is 0%, and the description only vaguely links parameters to actions: 'list (cursor); get (code); check_in (code, status de check-in)'. It does not explain the 'account' parameter, nor does it define the format or semantics of 'code' or 'cursor'. The description adds minimal value over the raw schema, which is empty of descriptions, so it fails to compensate for the low coverage.

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

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

The description states it handles e-tickets (leitura) and lists actions list/get/check_in, but then claims 'Flattened action: check_in' without clarifying whether this tool performs only check-in or all three actions. The purpose is ambiguous and does not clearly distinguish from siblings like guru_etickets_get or guru_etickets_write_do_check_in.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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. It does not mention any context, prerequisites, or exclusions. Since siblings like guru_etickets_list, guru_etickets_get, and guru_etickets_write_do_check_in exist, the description should clarify when this check-in-specific tool is appropriate, but it doesn't.

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

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

The description claims the tool supports a 'check_in' action (code, status de check-in), which implies a state-changing operation consistent with write behavior&amp;quot;. However, annotations explicitly declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. This is a clear contradiction. Additionally, the description only repeats 'leitura' (read) without disclosing any other behavior beyond what annotations already state.

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

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

The description is short, but it's organized as a list of actions with a confusing '[Flattened action: get]' note. It front-loads the read-only nature but then introduces actions that may not apply, damaging clarity. It could be much simpler: state the tool gets an e-ticket by code.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 zero parameter descriptions, the description fails to explain what the tool returns, how 'account' parameter is used, or how this relates to other e-ticket operations. The mention of list/check_in without mapping to actual parameters (cursor, code) is incomplete. There is insufficient context for the agent to use this reliably.

Complex tools with many parameters or behaviors need more documentation. 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 three parameters (code, cursor, account) with zero descriptions. The description mentions 'cursor' for list and 'code' for get, but does not explain the 'account' parameter or clarify that only 'code' applies to the get action. There is no added meaning for any parameter, so agents must guess how to use them.

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

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

The description states 'Ingressos (e-tickets) no Guru (leitura)' and lists actions 'list (cursor); check_in (code, status de check-in); get (code)' but then declares '[Flattened action: get]'. This is confusing: it suggests the tool can perform multiple actions, including a mutating check-in, yet the tool is named get and the flattened action is get. It does not clearly specify that this tool only retrieves a single e-ticket by code, which is what would differentiate it from sibling tools.

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

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

The description gives no guidance on when to use this tool versus the sibling tools like guru_etickets_check_in or guru_etickets_list. In fact, listing check_in as an action could mislead the agent into thinking this tool handles check-ins, whereas a dedicated sibling exists. There is no direction on parameter selection or use 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 mentions a check_in action (writing check-in status) while annotations declare readOnlyHint=true and destructiveHint=false, a direct contradiction. This creates confusion about the tool's 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 but poorly structured: it lists multiple actions and a technical '(Flattened action: list)' note, which adds noise without aiding comprehension. It is not succinctly focused on the list 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 3 undocumented parameters, no output schema, and only a cryptic Portuguese description, the tool is far from self-contained. An agent cannot determine expected inputs, return format, or pagination behavior.

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

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

Schema description coverage is 0% and the description does not explain any of the three parameters (code, cursor, account). It only hints 'cursor' for list but lacks details on usage, format, or 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 lists multiple actions (list, get, check_in) making the primary purpose ambiguous. Although the name and flattened action indicate 'list', the inclusion of get and check_in conflates the tool's scope. It doesn't clearly distinguish from sibling tools like guru_etickets_get.

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

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

No guidance on when to use this tool versus alternatives. The description merely enumerates actions without explaining contexts or exclusions, leaving the agent to infer usage from the name and siblings.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive write. The description adds 'Mutations' but does not explain side effects of creating invitations, required permissions, or what data means. The listing of delete actions is confusing and could imply destructive behavior, though the flattened action suggests they are not all available. No annotation contradiction is flagged because the flattened action identifies create_invitations as the actual operation, but transparency is weak.

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

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

The description is short and front-loaded with 'Mutations,' but the multi-action list and bracket note create noise and ambiguity. It could be a single focused sentence about create_invitations. It is not as clean or purposeful as a well-structured two-sentence description.

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

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

With 3 parameters, a nested data object, no output schema, and no enum constraints, the description should provide more operational context. It does not describe return values, error conditions, or the data object's structure. The sibling tools show a rich domain, but this description does not situate the tool within 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%, so the description must compensate. It only repeats 'code + data' from the action list and omits 'account' entirely. It does not define what code refers to, the expected shape of data, or how account is used. This is insufficient for a tool with a nested-object 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 identifies the tool as performing mutations on Guru e-tickets and mentions create_invitations with code+data, but it opens with a broad list of five actions, making the primary purpose ambiguous. It does not clearly state 'creates invitations' as a standalone behavior or distinguish it from sibling tools like guru_etickets_write_delete_invitations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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. It does not mention that this is for creating invitations, when to prefer it over guru_etickets_write_delete_invitations or guru_etickets_write_do_check_in, or any prerequisites or context. The 'flattened action' note is the only hint.

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

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

The description does not disclose the effects or side effects of the delete operation, such as irreversibility, required permissions, or what happens to related data. Additionally, the annotation destructiveHint is false, which directly contradicts the delete action implied by the tool name and flattened action, making the description misleading.

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

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

The description is overly broad, enumerating multiple actions that are not specific to this tool, which introduces redundancy and confusion. While short in length, the content lacks focus and structure, making it less concise than it could be if it simply stated 'Deletes an e-ticket by code.'

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

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

The description fails to provide essential context for an agent to use the tool correctly, such as the exact operation performed, the required inputs, or any edge cases. Given the tool's apparent simplicity (delete by code), the description is incomplete and leaves too much ambiguity, especially with the misleading list of unrelated actions.

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

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

The input schema defines three parameters (code, data, account) but the description provides no explanation of their meaning or usage. For a delete action, it's unclear why 'data' and 'account' are present, and no examples or constraints are given. The parameter coverage is incomplete and does not compensate for the minimal 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 is vague about the tool's specific purpose, listing multiple actions (do_check_in, delete_check_in, create_invitations, etc.) without clarifying that this tool is specifically for deleting e-tickets. The name and 'Flattened action: delete' hint at the purpose, but the description does not clearly distinguish it from sibling e-ticket mutation 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 the many sibling tools for e-ticket operations (e.g., guru_etickets_write_create_invitations, guru_etickets_write_delete_check_in). The description lacks any contextual hints about appropriate usage scenarios, prerequisites, or conditions.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description says 'delete_check_in (code)' which implies a deletion operation, but it does not disclose what happens when deleting a check-in, whether it is reversible, or any side effects. The description does not contradict annotations, but it adds minimal behavioral context beyond the action name.

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

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

The description is short and lists actions in a compact format, but it is not well-structured for the specific tool. The '[Flattened action: delete_check_in]' line is helpful but the overall description is cluttered with multiple actions that are not relevant to this tool. It could be more focused.

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

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

Given the tool has 3 parameters, no output schema, and no annotations providing safety details, the description is insufficient. It does not explain the return value, error conditions, or prerequisites. The tool is a mutation (delete) but lacks context on what is deleted and how to use it correctly. Sibling tools exist for related operations, but no cross-referencing is provided.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions 'code' for delete_check_in but does not explain what 'code' represents (e.g., ticket code, check-in code). The 'data' and 'account' parameters are not mentioned at all, leaving their purpose unclear. The description adds minimal value over the schema.

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

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

The description lists multiple actions (do_check_in, delete_check_in, create_invitations, delete_invitations, delete) but the tool name and flattened action indicate this is specifically for delete_check_in. The purpose is muddled by listing all actions without clarifying which one this tool executes. It does not clearly distinguish from sibling tools like guru_etickets_write_delete or guru_etickets_write_do_check_in.

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

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

No guidance on when to use this tool versus alternatives. The description mentions 'Mutações em e-tickets Guru' (mutations in Guru e-tickets) but does not specify when to use delete_check_in vs other delete operations. Sibling tools like guru_etickets_write_delete and guru_etickets_write_delete_invitations exist, but no differentiation is provided.

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

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

The description mentions 'delete_invitations' and 'delete', implying destructive operations, yet the annotation destructiveHint is false. This is a direct contradiction. Additionally, the description does not disclose side effects, permissions, or any behavioral details beyond the action names. With no annotations to back up safety, this is misleading.

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

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

The description is short but poorly structured. The bracket note '[Flattened action: delete_invitations]' is cryptic and placed at the end. The description lists multiple actions without clarifying which one applies, leading to confusion rather than a clean, front-loaded specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 performs a write operation with no output schema, yet the description fails to specify the exact operation (delete invitations) or the effect on data. It doesn't explain required prerequisites, return values, or error behavior. The ambiguity makes it unusable for an agent to correctly invoke the tool.

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

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

Schema coverage is 0%, so the description carries the burden. It lists action-parameter pairs (e.g., delete_invitations (code)) but does not explain the meanings of code, data, or account in the context of the flattened action. data is shown for create_invitations but not for delete_invitations, yet it remains in the schema, causing ambiguity about its relevance.

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

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

The description states it performs 'Mutações em e-tickets Guru' and lists multiple actions, but it does not clearly specify that the tool's primary function is to delete invitations. The flattened action note indicates delete_invitations, but the description itself is ambiguous and does not distinguish from sibling tools like guru_etickets_write_delete_check_in or guru_etickets_write_create_invitations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 its alternatives. It does not mention that this is for deleting invitations or that other actions are handled by different tools. The list of actions could mislead an agent into thinking the tool can perform any of them, but no criteria or context is given for appropriate usage.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description says 'Mutações' (mutations), confirming a write action. However, it only says 'valida entrada' (validates entry) for do_check_in, without detailing side effects, consequences of invalid codes, idempotency, or any additional behavior. The listing of other actions not performed by this tool adds confusion rather than clarity.

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

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

The description is short but includes extraneous information listing other actions that are not part of this tool. It front-loads a generic 'Mutações' statement and then lists multiple actions before clarifying the flattened action. This wastes tokens and confuses the agent. A single concise sentence stating 'Performs check-in on an e-ticket using a code' would be more effective.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, and no additional annotations), the description should explain what check-in does, parameter usage, and potential outcomes. It only mentions that code validates entry, leaving data and account undefined, and no indication of return values or errors. The description is inadequate for an agent to use the tool correctly without additional assumptions.

Complex tools with many parameters or behaviors need more documentation. 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 3 parameters (code, data, account) with 0% description coverage. The description only mentions 'code' for do_check_in, and even that is only described as 'valida entrada' (validates entry), not explaining its format or purpose beyond that. The 'data' and 'account' parameters are completely unexplained. The description fails to clarify whether they are used for this action at all.

Input schemas describe structure but not intent. Descriptions should explain 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 multiple actions but explicitly identifies 'do_check_in (code, valida entrada)' as the flattened action. This provides a specific verb (check-in) and resource (e-ticket), though the inclusion of unrelated actions (delete, create_invitations) muddies the purpose. It does distinguish from sibling tools like 'guru_etickets_check_in' by implying a write operation, but not clearly.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools like 'guru_etickets_write_delete_check_in' and 'guru_etickets_check_in' exist, but the description does not contrast them. There is no mention of prerequisites, restrictions, or when not to use this tool.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds little beyond a vague hint of cursor-based behavior; it does not disclose pagination details, response shape, or any account/scope constraints. There is no contradiction with annotations.

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

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

The description is extremely short and front-loaded, which is good for conciseness. The parenthetical '(cursor)' adds slight ambiguity but does not meaningfully inflate length, so the description remains appropriately compact.

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

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

With two parameters at 0% schema coverage, no output schema, and no usage guidance, the description is too minimal to be fully actionable. A simple listing tool may not require extensive documentation, but key aspects like pagination behavior and account scoping are absent.

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

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters. It only echoes 'cursor' in parentheses without explaining its meaning or usage, and 'account' is left completely unexplained.

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

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

The description uses a specific verb ('Lista') and identifies the resource ('leads no Guru'), making the primary action clear. However, the parenthetical '(cursor)' is ambiguous and the description does not distinguish this tool from sibling tools by scope or 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 to use this tool versus alternatives, nor are any preconditions or exclusions mentioned. The description simply states the action without contextualizing its place among the many guru_* list and search tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safe read behavior is covered. The description adds the install-scoped listing context and output fields, but it does not disclose pagination, authentication needs, or the effect of the optional account parameter.

Agents need to know what a tool does to the 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 filler or repetition. It efficiently conveys the action, object, scope, and returned fields.

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

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

The description is minimally adequate for a simple list operation with strong annotations, and it helpfully states the output fields. However, the undocumented optional parameter, lack of alternative guidance, and absence of an output schema leave clear gaps for an agent trying 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?

The schema lists one optional 'account' parameter with no description, and the tool description does not mention it at all. With 0% schema description coverage, the description should compensate but leaves the agent to guess whether 'account' filters, selects, or is unused.

Input schemas describe structure but not intent. Descriptions should explain 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 verb and resource: lists Digital Manager Guru accounts linked to this install, returning id and alias. This clearly distinguishes it from sibling tools like guru_account by emphasizing the install-level listing scope.

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

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

The description implies use when an agent needs the IDs/aliases of accounts linked to the current install. However, it does not explicitly mention when not to use it or name alternatives such as guru_account or connect, so 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?

Annotations provide no behavioral hints (all false), so the description carries the full burden. It mentions 'POST' indicating a mutation, but does not disclose side effects, authentication requirements, rate limits, or the nature of the generated link. This is minimal transparency beyond the HTTP method.

Agents need to know what a tool does to the 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 directly states the action and input. It is front-loaded with the core purpose and contains no redundant information.

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

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

Given the tool has 3 parameters, no output schema, and no annotation hints, the description is incomplete. It does not explain the purpose of 'data' and 'account', nor the output format or any side effects. The description covers only the basic action and email input, leaving significant gaps.

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

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

Schema coverage is 0%, so the description must explain all parameters. It only mentions 'email' (through 'pelo email'), which clarifies its role, but 'data' and 'account' are not described. The description adds some value for email but fails to compensate for the lack of schema descriptions for other params.

Input schemas describe structure but not intent. Descriptions should explain 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 generates an SSO link for the MyOrders purchase area using a buyer's email, providing a specific verb and resource. It distinguishes itself from sibling tools by its narrow focus on SSO link generation, though it does not explicitly contrast with alternatives.

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

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

The description implies usage when an SSO link for MyOrders is needed, but it does not provide explicit context, prerequisites, or alternatives. There is no guidance on when not to use this tool or how it compares to other tools like guru_contacts_get, so usage is only implicitly inferred.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it's a read operation ('leitura', redundant), lists valid section values, and notes bulk support via plural IDs. No contradictions, but it doesn't go beyond annotations with useful context like response behavior or auth needs.

Agents need to know what a tool does to the 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 dense dump of actions and parameters, with the key 'Flattened action: checkout_options' note buried in brackets. It's not front-loaded and contains extraneous information about actions that aren't part of this tool, making it harder for an agent to quickly parse the actual purpose.

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

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

With no output schema and a 12-parameter input schema, the description should clarify expected inputs and outputs. It provides some context (sections, bulk support) but omits details on return values, pagination, and which parameters are valid for the flattened checkout_options action. 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 coverage is 0%, so the description needed to explain parameters. It lists action signatures and section values, and mentions bulk IDs, but leaves many schema properties (name, type, cursor, account, is_hidden, etc.) unexplained. The mapping between the flattened action's parameters (product_id, section) and the full schema is unclear.

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

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

The description lists many actions (list, get, subscription_options, checkout_options, offers, etc.) before clarifying that only checkout_options is flattened for this tool, creating ambiguity. It does specify checkout_options(product_id + section), but does not directly state that the tool retrieves checkout options for a product, nor does it distinguish this from the sibling offer_checkout_options 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?

No explicit guidance on when to use this tool versus alternatives. Bulk support is mentioned, but there's no statement like 'use this for product checkout options, not offer checkout options,' nor any reference to sibling tools such as guru_products_offer_checkout_options. The distinction is only implied through parameter lists.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the description's 'leitura' redundant. But the description adds genuine behavioral context beyond annotations: exact per-action parameter requirements (e.g., 'checkout_options (product_id + section)'), the section enum values, the '[Flattened action: get]' scoping note, and bulk execution support via plural ID arrays. 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 logically front-loaded: purpose, then the action/parameter matrix, then the current-action note, then bulk behavior. Every sentence carries information and the structure is easy to scan despite the dense semicolon-separated notation. The Portuguese language adds a minor parsing burden but does not obscure the structure.

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

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

Given the complexity — 12 parameters, 8 actions, 0% schema coverage, and no output schema — the description covers the action/parameter matrix and bulk behavior reasonably well. But it leaves notable gaps: the 'account' parameter is entirely undocumented, return values are not described despite the absence of an output schema, and the relationship to the 8 overlapping sibling tools is unaddressed.

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

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

With 0% schema description coverage, the description carries the full burden and compensates well: it maps each action to its required parameters (list uses name/type/marketplace_id/is_hidden/cursor; get uses product_id; etc.), explains the section enum, and documents bulk support for product_ids/offer_ids/marketplace_ids. However, the 'account' parameter appears in the schema but is never mentioned in the action list, and 'type'/'is_hidden' lack value ranges.

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

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

The description opens with 'Produtos e ofertas no Guru (leitura)' — a clear read-only scope over products and offers, then enumerates 8 specific actions (list, get, subscription_options, etc.) with their required parameters. This distinguishes it from siblings at a resource level. However, the multi-action listing somewhat conflicts with the tool name 'guru_products_get' and the '[Flattened action: get]' note, creating mild ambiguity about whether this is one tool or eight.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 flattened tool versus the nearly identical sibling tools (guru_products_list, guru_products_offer, guru_products_subscription_options, guru_products_checkout_options, etc.). The action→parameter mappings imply how to invoke each action but offer no when/when-not tool-selection advice — a critical gap given the 8 overlapping sibling names.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'leitura' label is consistent with that. It adds useful extra behavior via 'Bulk support: accepts product_ids, offer_ids, marketplace_ids for batched execution.' However, it does not disclose pagination behavior, return format, or any auth requirements beyond what annotations already convey.

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

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

The description is compact and front-loaded with the resource and read-only intent. However, the lengthy 'Ações:' list is largely redundant for a flattened list action and may mislead agents, and the section enum repeats information already available in the input schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 12-parameter read tool with no output schema, the description provides the list filters and bulk execution capability but omits details about response contents, cursor pagination behavior, and how products versus offers are returned. The annotations cover the safety profile, but operational completion is only partial.

Complex tools with many parameters or behaviors need more documentation. 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 does name the list-relevant filters and bulk array parameters, and it gives the section enum values. Still, it leaves parameters like `account` unexplained and does not clarify value formats or semantic constraints for filters such as `type` or `is_hidden`.

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

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

The description opens with 'Produtos e ofertas no Guru (leitura)', clearly identifying the resource and read-only intent. It also specifies the list action with concrete filters (name, type, marketplace_id, is_hidden, cursor), which distinguishes the core behavior. However, the long action enumeration before '[Flattened action: list]' muddies whether this tool is strictly a 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?

No explicit guidance is given on when to use this tool versus sibling tools like guru_products_get or guru_products_offers. The list filters imply usage, but the description does not state exclusions or name alternatives, and the duplicated action list adds confusion rather than clarifying decision boundaries.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false Mend Claims estado: read-only. The description labels itself as (leitura) and clarifies read-only. No extra behavioral detail (rate limits, auth, response shape) given.

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

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

Fairly concise but dense; a non-native-English description with inline code-style action list. The action-to-parameter mapping is clear but would benefit from a structured breakdown.

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

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

No output schema and no description of response shape, pagination details, or error behavior. Some context about actions and flattened actions, but an agent doesn't know what it will get back or what the product_id/offer_id values refer to beyond their names.

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

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

Lists actions and their input parameters (name, type, cursor, product_id, etc.), plus the enum values for section. However 0% parameter description coverage means each param lacks an individual description; the context that groups params per action is not formalized in the schema.

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

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

Clear verb+resource: reads products/offers with a list of actions (list, get, offers, etc.). However, it doesn't distinguish from sibling tools like guru_products_list and guru_products_offers, which seem to overlap.

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

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

Lists which action to use with which params but doesn't explicitly state when to prefer this tool over siblings such as guru_products_list, guru_products_offers, guru_products_checkout_options, etc. No when-not 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, idempotentHint, and destructiveHint, and the description reinforces the read-only nature with 'leitura'. It adds meaningful context beyond annotations by giving the exact action-to-parameter mapping, the section enum, and bulk support via product_ids/offer_ids/marketplace_ids.

Agents need to know what a tool does to the 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 scannable, starting with the read-only category and using a dense action/parameter list. It contains no filler, though the multi-action list is broader than the tool's actual flattened action, which adds slight noise.

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

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

The description provides key invocation details—action signature, section enum, and bulk support—and annotations cover the safety profile. However, with no output schema, it never explains what checkout options actually are or what the response contains, and the section values are listed without explanation of their functional meaning.

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

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

With 0% schema description coverage, the description compensates well by mapping actions to their required parameters—particularly offer_checkout_options (product_id + offer_id + section)—and by documenting the allowed section values and bulk array parameters. Some field meanings are left implicit, but the relevant parameters for the flattened action are clearly 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 labels the tool as read access to Guru products/offers and lists the flattened action signature (product_id + offer_id + section), so the primary purpose is inferable. However, it never states in plain terms that this tool returns checkout options for a specific offer section, and the long list of other actions (list, get, offers, etc.) makes the single tool's purpose less crisp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 distinguishes offer_checkout_options from checkout_options by requiring offer_id, and it enumerates valid section values, so usage is implied. It does not explicitly say when to use this tool versus sibling tools like guru_products_checkout_options or guru_products_offer_subscription_options, nor does it mention exclusions or preconditions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds bulk batching behavior and parameter-to-action mapping, but leaves 'Flattened action: offers' unexplained and doesn't mention pagination, authentication, or return behavior beyond the available filters.

Agents need to know what a tool does to the 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 with the core purpose, then uses a clear action/parameter list and a separate bulk-support note. The '[Flattened action: offers]' line is cryptic and consumes a sentence without adding clear value, preventing 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?

For a 12-parameter tool with no output schema, the description covers actions, filters, section enum, and bulk execution, which is substantial. Yet it lacks an explanation of how the tool selects an action given that the schema has no 'action' field, and it omits the 'account' parameter and any return-value guidance.

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

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

With 0% schema description coverage, the description compensates well by mapping parameters to each action (e.g., list uses name, type, marketplace_id, is_hidden, cursor; checkout_options uses product_id + section) and by explicitly enumerating valid section values. However, the 'account' parameter is not mentioned anywhere, and the semantics of 'is_hidden' and 'type' values are left to inference.

Input schemas describe structure but not intent. Descriptions should explain 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-only tool for 'Produtos e ofertas no Guru' and enumerates specific actions (list, get, offers, offer, etc.). It is more specific than the bare tool name, though 'Flattened action: offers' adds some confusion and sibling differentiation is not explicit.

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

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

The description gives useful context by saying 'leitura' and listing which parameters belong to which action, plus bulk support for arrays. However, it does not explicitly say when to choose this tool over similar sibling tools like guru_products_get, guru_products_list, or guru_products_offer.

Agents often have multiple tools that could apply. Explicit usage 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 'leitura' (reading) and the annotations include readOnlyHint and idempotentHint both true, and destructiveHint false. The description also mentions bulk support (accepts product_ids, offer_ids, marketplace_ids) for batched execution, which is beyond annotations and useful behavioral info. It clearly indicates this is a non-mutating, read-only operation, aligned 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 concise, using bullet points and a clear structure. It starts with a clear summary (read-only products and offers), then lists actions and parameters, and adds a note about bulk support. No wasted words, each sentence provides valuable information.

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

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

The description is comprehensive enough for this read-only operation with idempotent hints and bulk support. It lists the required parameters and the action's purpose. However, it doesn't explain return values (no output schema) but that's not required since the tool is read-only and the description implies it retrieves subscription options. The description covers parameter usage, bulk capabilities, and its placement within the Guru system, which is sufficiently complete given the 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?

The schema has 12 parameters with 0% description coverage, so the description carries the burden. It explains that for this flattened action, product_id and offer_id are required, and includes a section enum for related actions. It also explains bulk parameters (product_ids, offer_ids, marketplace_ids) for batched execution, which adds semantic meaning beyond the schema. However, it doesn't explain the meaning of parameters like cursor, is_hidden, name, type, which are less relevant to this specific action, but given the flattened context, it does provide key 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 explicitly lists offer_subscription_options as the flattened action for this tool, indicating it retrieves subscription options for a specific offer within the Guru products domain. It identifies the required parameters (product_id and offer_id) and how it differs from sibling actions like subscription_options and offer, providing clear purpose. However, the description groups multiple actions together and the specific purpose of this tool is only clear when parsing the flattened action line, which slightly reduces clarity.

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

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

The description clearly states the action is for reading subscription options for an offer within a product, and lists the parameters (product_id and offer_id) needed. It also provides a section enum for related checkout options but does not explicitly state when to use this tool vs. siblings like subscription_options (for products) or offer (for basic offer details). The sibling tool names (guru_products_subscription_options, guru_products_offer) hint at alternatives but the description doesn't explicitly differentiate usage.

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