Hotmart

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

Annotations show idempotentHint. Description adds context about permanent vs session login, which annotations don't cover. No contradiction. Could be more explicit about token storage 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?

Description is informative and front-loaded with 'MCP.AI for IDE agents'. A bit wordy but each sentence adds value. Could be slightly shorter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, but description covers what to expect (link or token). Single optional parameter, scenarios explained. Complete for a simple auth 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 has 0% coverage for 'token' parameter. Description explains its use: 'paste it here for a session-only login: call with { token: '<jwt>' }', adding meaning beyond schema.

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

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

The description clearly states the tool authenticates users, providing a login link or accepting a token. It distinguishes from siblings by being the authentication tool.

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

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

The description gives explicit guidance on two usage methods: permanent config or session-only token. It clearly explains when to use each but does not compare to sibling tools.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by explaining the return results in two cases (all connected vs. missing credentials), providing behavioral context beyond annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words. Every sentence adds clear value.

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

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

For a simple read-only status tool with no parameters and no output schema, the description covers the key behaviors (two scenarios) completely. No additional context is needed.

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

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

No parameters exist, so the description is not required to add parameter information. Baseline 4 is appropriate as the description does not conflict with schema (100% coverage).

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

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

The description clearly states the tool returns connection status and URLs, with specific details for two distinct scenarios. It effectively distinguishes the tool from siblings like 'authenticate' by indicating this tool is for checking status, not performing authentication.

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

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

The description does not explicitly guide when to use this tool versus alternatives. It implies it's for checking connection status but lacks clear when-to-use or when-not-to-use statements. Given the sibling 'authenticate', explicit guidance would be beneficial.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, so the description adds little beyond confirming it provides data. No contradictions, but no extra behavioral context.

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

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

Single sentence, directly states the tool's purpose with no redundancy. Efficient and front-loaded.

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

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

While the description gives a general idea of output fields, it lacks detail on return format or exact data structure. With no output schema, more specific behavioral info would be helpful.

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

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

The sole parameter 'account' is not described in the schema (0% coverage) and the description does not clarify its purpose or format. The agent is left guessing what value to provide.

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

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

The description clearly states the tool provides data from the connected Hotmart account, including name, document, and settings. It differentiates from sibling 'hotmart_list_accounts' which lists accounts, while this focuses on a single connected account.

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

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

No guidance on when to use this tool versus alternatives like 'hotmart_list_accounts'. No conditions or prerequisites are mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it requires a subdomain and supports bulk operations, but does not provide significant behavioral context beyond what annotations already convey. No contradictions.

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

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

The description is unnecessarily long and mixes Portuguese and English. It lists actions in bullet form but is not well-structured. There is redundancy and lack of focus, making it less concise than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 8 parameters, no output schema, and no parameter descriptions, the description attempts to cover functionality but is confusing and incomplete. It does not clarify the primary action (lessons) and the relationship to sibling tools, leaving the agent with insufficient information 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 description coverage is 0%, but the description explains the role of several parameters: subdomain (required), is_extra for modules, module_id for pages, student_email for students, user_id for lessons, and module_ids/user_ids for bulk. However, it does not explain all parameters (e.g., account is missing). Provides some meaning but incomplete.

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

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

The description states it inventories and accompanies course content, listing multiple actions (modules, pages, students, lessons), but the title and name suggest it is specifically for lessons. The mention '[Flattened action: lessons]' hints that lessons is the primary focus, but the mixed actions create confusion. Purpose is somewhat clear but not unambiguous.

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

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

No guidance is given on when to use this tool versus sibling tools like hotmart_club_modules, hotmart_club_pages, or hotmart_club_students. The description implies this tool can handle multiple actions, but it does not clarify the differentiation or when to use which.

Agents often have multiple tools that could apply. Explicit usage 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's mention of 'inventory and track' aligns. The description adds useful behavioral context like bulk support and required subdomain, but does not elaborate on side effects or error scenarios beyond what annotations imply.

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

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

The description is relatively concise and well-structured with a bulleted action list. It front-loads the tool's domain and then details each action with its parameters. The inclusion of 'Bulk support' 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?

Given no output schema and 8 parameters with multiple actions, the description provides essential invocation details (required subdomain, per-action parameters, bulk support). However, it lacks information on return values or pagination, which could be critical for a complete tool understanding.

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

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

With 0% schema description coverage, the description compensates by explaining most parameters in context (e.g., 'is_extra' filters extra modules, 'module_id' required for pages, 'user_id' for lessons). However, 'account' and 'user_ids' are only mentioned in bulk support without full clarification, leaving some gaps.

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

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

The description clearly states the tool is for a membership area (Hotmart Club) to inventory and track course content, listing specific actions like modules, pages, students, and lessons. While it covers multiple sub-tools, it provides enough specificity to distinguish its combined purpose from sibling tools that focus on individual actions.

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

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

The description does not explicitly state when to use this tool versus its siblings (e.g., hotmart_club_lessons, hotmart_club_pages, hotmart_club_students). It lists actions but provides no guidance on when the combined tool is preferable over individual ones, nor does it mention any 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 and destructiveHint false. Description adds bulk support and per-action requirements, but doesn't elaborate on rate limits or authentication.

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

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

Reasonably concise; lists actions with corresponding parameters. Mixed language (Portuguese/English) but no wasted words. Could be more consistently 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?

Missing explanation of how to select the action (likely inferred from provided parameters), and no details on return values. For a multi-action tool, this is incomplete.

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

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

With 0% schema description coverage, the description explains several parameters (subdomain, is_extra, module_id, student_email, user_id) but omits 'account', and the bulk parameters (module_ids, user_ids) are only mentioned in bulk support context.

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

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

The description states it inventories club content and lists actions, but the tool name 'pages' conflicts with listing multiple actions (modules, pages, students, lessons). The purpose is somewhat clear but ambiguous due to the multi-action 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?

No explicit guidance on when to use this tool vs sibling tools like 'hotmart_club_modules' or 'hotmart_club_students'. Only prerequisites (subdomain) are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by mentioning bulk support (module_ids, user_ids). However, it does not fully explain behavior like pagination, error handling, 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 structured as a bullet list but includes redundant 'Ações:' header and mixed languages. It could be shorter by focusing only on the students action as per the flattened note.

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

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

Given the 8 parameters, no output schema, and existence of sibling tools, the description is insufficient. It does not clarify which action is active, how bulk execution works, or the relationship with sibling tools.

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

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

Schema description coverage is 0%, and the description only partially explains a few parameters (is_extra, student_email, module_id) without full syntax or constraints. Parameters like account, user_ids are left undocumented, forcing reliance on schema 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 lists multiple actions (modules, pages, students, lessons) for a tool named 'students', creating ambiguity about its primary purpose. The 'Flattened action: students' note attempts to clarify but the schema still includes parameters for other actions, contradicting a focused purpose.

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

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

No explicit guidance on when to use this tool versus sibling tools like hotmart_club_modules or hotmart_club_pages. The description does not differentiate use cases or provide alternatives, leaving the agent to guess.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds no new behavioral context such as rate limits or authentication needs, so it adds little 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 two concise sentences with front-loaded purpose, efficient and without 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 no output schema and a moderate parameter count, the description covers the main functionality but lacks details on pagination behavior, error handling, or output format.

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

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

With 0% schema coverage, the description partially compensates by explaining that product_id is required, code and page_token are filters, and product_ids enables bulk. However, it omits the account parameter entirely.

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

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

The description clearly states the tool lists discount coupons for a product, specifying required product_id and optional filters. It differentiates from sibling write tools but does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 required parameter and filters, and introduces bulk support. However, it does not provide guidance on when to use this tool instead of siblings 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?

The description mentions both create and delete actions, which is confusing given the tool name and flattened action. Annotations indicate readOnlyHint false (mutations) but destructiveHint false, yet delete is destructive. The description does not clarify the actual behavior beyond the schema.

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

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

The description is somewhat messy, listing actions then stating flattened action and bulk support. It could be more streamlined 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 7 parameters with none required, no output schema, and a variety of sibling tools, the description is incomplete. It fails to explain all parameters and the exact behavior for bulk operations, leaving gaps for the 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 compensates by explaining product_id, code, discount, coupon_id, and bulk fields. However, it does not explain the 'account' parameter, leaving its purpose unclear.

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

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

The description clearly states 'create: cria um cupom num produto' (create a coupon on a product), specifying the verb and resource. It distinguishes from sibling tools like hotmart_coupons_write_delete by naming the action and having a flattened action marker.

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

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

The description implies usage for creating coupons and mentions bulk support, but does not explicitly state when to use this tool vs alternatives (e.g., when to use hotmart_coupons_write_delete). No exclusions or prerequisites are provided.

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

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

Annotations declare destructiveHint=false, but the description describes delete operations which are destructive. This is a contradiction. The description does not clarify whether delete is reversible or has side effects.

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

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

The description is moderately concise, listing actions and bulk support. However, it could be more streamlined; some details like the flattened action note add clutter.

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

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

With 7 parameters and no schema descriptions, the description covers some but not all fields (e.g., 'account' is unexplained). Lacks details on return values, error behavior, and prerequisites. Incomplete for effective tool use.

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

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

With 0% schema coverage, the description explains key parameters: product_id, code, discount (with decimal range), coupon_id for delete, and batch fields. This adds necessary meaning beyond the bare schema.

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

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

The description states it handles mutations (create/delete) for Hotmart discount coupons. However, the tool name 'write_delete' and flattened action 'delete' suggest it is primarily for delete, while creating is covered by a sibling tool, causing confusion.

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

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

No explicit guidance on when to use this tool vs the separate 'hotmart_coupons_write_create' tool. Mentions bulk support but does not clarify scenarios for create vs delete.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds bulk support via 'event_ids', but does not disclose other traits like rate limits or authentication 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 short but mixes Portuguese and English, and includes a confusing 'Flattened action: info' note. It could be more streamlined and clearly organized.

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

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

With no output schema and 5 parameters, the description does not explain return values or pagination details. It only hints at data about events and ticket types, leaving the tool's full behavior underdefined.

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

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

The description explains the 'event_id' requirement and bulk support for 'event_ids', but with 0% schema description coverage, it fails to clarify 'account', 'page_token', and 'max_results'. This leaves significant gaps.

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

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

The description mentions both 'info' and 'participants' actions but states 'Flattened action: info', creating ambiguity about the tool's actual purpose. It does not clearly separate from the sibling tool 'hotmart_events_participants'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 requires 'event_id' for info and participants but does not provide guidance on when to use this tool versus alternatives. No exclusions or sibling comparisons are included.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context such as requiring event_id, supporting bulk via event_ids, and implying pagination with page_token and max_results. No contradictions.

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

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

The description is verbose and unclear, starting with a header in Portuguese, listing actions in a bullet-like format, then including '[Flattened action: participants]' and 'Bulk support'. It could be more streamlined and front-loaded with the core purpose.

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

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

The tool has no output schema and low parameter documentation. The description should explain return values, pagination behavior, and the role of optional parameters. It does not, leaving significant gaps for an agent to effectively use 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%, so the description must compensate. It only explains event_id (required) and event_ids (bulk). It does not describe account, page_token, or max_results, leaving the agent unaware of their purpose. This is insufficient for 5 parameters.

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

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

The description states the tool retrieves participants (ingressos, compradores, participantes) for events. It distinguishes from hotmart_events_info, which is a sibling tool for event info. The mention of 'Flattened action: participants' clarifies the specific operation.

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

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

The description explicitly notes two actions (info and participants) and indicates this tool handles participants. It also mentions bulk support with event_ids, guiding use for batched queries. However, it doesn't explicitly state when not to use it or provide alternatives beyond the sibling tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety and idempotency are clear. The description adds scoping context ('vinculadas a este install') but no further behavioral details like error handling or response structure.

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

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

The description is a single short sentence, efficient and front-loaded. However, it lacks completeness for a non-English audience and does not elaborate on the parameter.

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

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

Given no output schema, the description partially covers the return fields but not fully. The parameter is undocumented, and there is no explanation of filtering or behavior with different values. Significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. 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 single optional parameter 'account' at all. The meaning and usage of the parameter are completely missing, leaving the agent with no guidance beyond the schema type.

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

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

The description clearly states the tool lists Hotmart accounts (creators) linked to this install, with specific returned fields (id, label, apelido). It uses a specific verb and resource, and distinguishes from siblings that deal with products, sales, subscriptions, etc.

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

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

No guidance on when to use this tool versus alternatives; no prerequisites or context like needing authentication. The description only states what it does without indicating when 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 indicate this is a write operation (readOnlyHint false) and not destructive (destructiveHint false). The description adds that it creates a negotiation for a late subscription, but it does not disclose side effects, required permissions, or error conditions. Without annotations, this would be more critical, but it's still minimal.

Agents need to know what a tool does to the 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, well-structured sentence that conveys the core purpose and a key requirement without unnecessary words. It fits within a few lines and is easily scannable.

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

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

Given the tool has 2 parameters, no output schema, and limited annotations, the description is minimally adequate. It explains the primary function and required input, but lacks details on the 'account' parameter, the negotiation process, expected outcomes, or error scenarios. It does not leverage the output schema (none exists) to compensate.

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

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

With 0% schema description coverage, the description only mentions that 'subscriber_code' is required, adding minimal semantic meaning. It does not explain the 'account' parameter or the format or constraints of 'subscriber_code'. The description partially compensates by stating the requirement, 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 clearly states the verb 'cria' (creates) and the resource 'negociação (recuperação) de uma assinatura em atraso' (negotiation/recovery of a late subscription). It distinguishes itself from sibling tools by focusing on negotiation for late subscriptions, though it does not explicitly name 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 the tool is for creating negotiations for overdue subscriptions and requires 'subscriber_code'. However, it provides no explicit guidance on when to use this tool versus other subscription-related tools (e.g., hotmart_subscriptions_write_cancel) 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 and destructiveHint=false, so the description need not repeat this. The description adds that the tool operates on 'da conta Hotmart', which is useful context.

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

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

The description is a single concise sentence that efficiently communicates the tool's purpose with no wasted words.

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

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

The description is adequate for a simple list tool but lacks details on parameter usage and output format. Without an output schema, some description of return values would improve completeness.

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

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

Schema description coverage is 0% and the description does not explain the purpose of the three parameters (account, page_token, max_results). It fails to 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 clearly states the verb 'lista' (lists) and the resource 'os links de pagamento (payment links) da conta Hotmart', distinguishing it from write siblings like hotmart_payment_links_write_create.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for listing payment links but does not exclude alternatives or mention context compared to sibling 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 states 'gera cobrança, mexe em dinheiro' (generates charges, manipulates money), indicating a mutation that affects financial state. Annotations show no readOnly, destructive, or idempotent hints, which aligns. However, the description does not disclose required permissions, consequences, or error conditions beyond a basic mutation hint.

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

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

The description is verbose and includes a list of all actions rather than focusing on the specific tool. The 'Flattened action' line helps, but the initial paragraph is redundant. It could be condensed to a single sentence explaining the add_offer action 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 no output schema, 0% parameter coverage, and a complex nested object, the description lacks completeness. It does not explain return values, required fields in 'data', or error handling. For a mutation tool, it provides only minimal behavioral context.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'payment_link_ucode + data' for the add_offer action, covering two of three parameters. However, 'account' is not described. The description adds partial meaning but lacks full parameter semantics, especially for the 'data' object which remains undefined.

Input schemas describe structure but not intent. Descriptions should explain 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 'adiciona oferta a um link' (adds offer to a link) and specifies the action as 'add_offer', making the verb and resource clear. It also lists sibling actions like 'add_plan' and 'charge_offer', distinguishing the tool's specific purpose. However, the initial general description about mutations may cause slight confusion.

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

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

No explicit guidance is provided on when to use this tool versus its siblings (e.g., add_plan, charge_offer). The description only lists other actions without context. The usage context is implied by the tool name and flattened action, but there is no when-not or alternative recommendation.

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

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

While annotations show this is a mutation (readOnlyHint false), the description adds context by noting it 'gera cobrança, mexe em dinheiro' (generates charges, touches money). However, it does not disclose side effects, permission needs, or idempotency, leaving gaps in behavioral understanding.

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

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

The description is unnecessarily verbose by listing all unrelated actions before focusing on add_plan. The first sentence is general, and the list could be omitted to focus solely on the tool's purpose. This reduces conciseness.

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

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

Given the tool has nested objects, no output schema, and no required parameters, the description is incomplete. It does not explain what the plan addition entails, the expected response, or how to use the 'data' object. More detail is needed for a mutation affecting finances.

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

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

With 0% schema description coverage, the description partially compensates by naming that add_plan uses 'payment_link_ucode' and 'data' (the config), but it does not explain the 'account' parameter nor the structure of the 'data' object. This leaves uncertainty about all parameters.

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

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

The description clearly states that this tool adds a plan to a payment link ('adiciona plano a um link de pagamento'), and the flattened action indicator specifies the relevant action. However, the listing of all possible actions in the description could cause confusion about the tool's specific purpose.

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

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

The description does not provide guidance on when to use this tool versus its siblings (e.g., add_offer, charge_offer). It only lists the required parameters for add_plan but lacks context on prerequisites 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. Description adds only a generic note about 'mexe em dinheiro' but does not explain specific side effects, prerequisites, or idempotency not already 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?

Description includes a list of actions that likely belong to other tools, making it longer than necessary and potentially misleading. Could be more concise by focusing solely on charge_offer.

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

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

Given no output schema, nested objects, and sibling complexity, description lacks return format, error states, or differentiation from similar write tools. Incomplete for confident use.

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

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

Schema has 0% parameter description coverage. Description partially explains that 'data' should contain 'token/oferta' for charge_offer, but does not describe 'account' or 'payment_link_ucode'. Some value added but incomplete.

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

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

The description lists multiple actions (create, add_offer, etc.) that likely belong to sibling tools, but then states [Flattened action: charge_offer], creating confusion about this tool's specific purpose. It does not clearly distinguish what this tool does versus 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?

No guidance on when to use this tool vs. alternatives like hotmart_payment_links_write_create or hotmart_payment_links_write_charge_value. The description omits context for selection.

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

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

Descriptino mentions 'mexe em dinheiro' indicating financial impact, but does not elaborate on behavioral details beyond what annotations provide (readOnlyHint false). No information about side effects, required permissions, or error handling.

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

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

Reasonably concise but includes extraneous listing of other actions, which adds clutter. The core action is clearly stated, but could be more streamlined.

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

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

Given the complexity and lack of output schema, the description is incomplete. It does not specify return values, error conditions, or prerequisites, 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 partially compensates by noting that 'data' should contain 'token/valor', but leaves 'account' and 'payment_link_ucode' unexplained. Lacks comprehensive parameter guidance.

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

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

The description states 'charge_value: cobra por valor' which clarifies the specific action, but it also lists other actions, creating confusion about whether this tool performs all or only charge_value. The overall purpose is somewhat clear but not neatly focused.

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

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

No explicit guidance on when to use this tool versus alternatives like charge_offer. The sibling tool naming provides implicit differentiation, but the description offers no contextual advice.

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

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

The description explicitly states it performs mutations ('gera cobrança, mexe em dinheiro'), implying destructive behavior, but the annotation 'destructiveHint' is false. This is a direct contradiction. Additionally, the description does not clarify whether operations are reversible or have 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 overly verbose, listing actions that belong to sibling tools, which adds confusion. The core information (that this tool only performs 'create') is buried at the end. It fails to be front-loaded or efficient.

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

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

For a mutation tool with no output schema, nested objects, and critical implications (money handling), the description is severely incomplete. It omits return format, error conditions, authorization needs, and prerequisites.

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

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

With 0% schema description coverage, the description should compensate but only vaguely mentions 'data com a config do link' for create and 'payment_link_ucode + data' for other actions. It does not explain the 'account' parameter or provide details on the structure of the 'data' object.

Input schemas describe structure but not intent. Descriptions should explain 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, add_offer, add_plan, charge_offer, charge_value) but the tool name indicates only 'create', and the note '[Flattened action: create]' suggests only create is intended. This inconsistency makes the purpose unclear and potentially misleading.

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

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

No guidance is provided on when to use this tool versus its siblings (e.g., hotmart_payment_links_write_add_offer). The description implies it can handle all mutation actions, which is contradictory to the tool name and sibling structure.

Agents often have multiple tools that could apply. Explicit usage 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 read-only and idempotent behavior, but the description introduces offers/plans actions that may mislead about actual capabilities. It fails to clarify that ucode is irrelevant for the list action, causing potential confusion.

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

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

The description includes a redundant action list that detracts from the tool's primary function. It is not front-loaded or concise; the flattened action note adds confusion rather than clarity.

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

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

Given no output schema and high parameter count with zero coverage, the description fails to explain return values, pagination behavior, or all parameters. It is insufficient for an agent to understand the tool's complete 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?

With 0% schema description coverage, the description only mentions max_results and page_token as filters. It does not explain the purpose of ucode or account for the list action, leaving parameter semantics 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 ambiguously lists three actions (list, offers, plans) without clarifying that only the 'list' action is active due to the flattened action note. The purpose is not clearly defined as a product listing tool, as it conflates multiple functionalities.

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

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

No guidance is provided on when to use this tool vs. siblings like hotmart_products_offers or hotmart_products_plans. The description does not mention exclusions or scenarios for choosing this list action.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's mention of listing and offers is consistent. However, it adds nothing beyond the annotations, such as authentication requirements or data scope.

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

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

The description is structured with a list of actions, but includes redundant phrasing ('requer ucode' twice) and a confusing '[Flattened action: offers]' line. It could be more concise.

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

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

There is no output schema, and the description does not explain return values or how the actions are organized. The tool has multiple implied actions without clear documentation, leaving gaps for the 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 description briefly explains ucode (for offers/plans), max_results, and page_token (for list), but does not cover the account parameter. With 0% schema coverage, the description partially compensates but is incomplete.

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

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

The description lists multiple actions (list, offers, plans) but the tool name and last line suggest it is specifically about offers. This ambiguity makes it unclear what the tool's primary purpose is, and it fails to distinguish from sibling tools like hotmart_products_list and hotmart_products_plans.

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

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

No guidance is provided on when to use this tool over the separate list and plans tools. The description mentions that ucode is required for offers and plans, but does not contrast with alternatives or specify 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds little beyond identifying it as a catalog. It does not explain the behavior of the 'plans' action, such as output format or pagination behavior, and the multi-action list is inconsistent with the tool's flattened focus.

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

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

The description includes irrelevant actions (list, offers) that belong to sibling tools, making it verbose and unclear. The structure is not front-loaded for the 'plans' purpose, and the final 'Flattened action: plans' note is confusing rather than clarifying.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 0% parameter descriptions, the description is severely incomplete. It does not describe the return values, how to use parameters for the plans action effectively, or any constraints. The user cannot determine how to invoke the tool correctly for listing subscription plans.

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

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

Schema coverage is 0%, so the description must compensate. It mentions that 'plans' requires ucode, providing some meaning for that parameter, but it does not explain account, page_token, or max_results in the context of the plans action. The description mainly references parameters for the 'list' action, which is not this tool's primary function.

Input schemas describe structure but not intent. Descriptions should explain 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, offers, plans) but the tool name and flattened note indicate it's specifically for plans. This creates confusion about the tool's primary purpose, and it does not differentiate from sibling tools like hotmart_products_list and hotmart_products_offers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 its siblings. The description mentions 'plans' requires ucode and 'list' uses max_results/page_token, but fails to clarify that this tool should be used for subscription plans while other tools handle lists and offers.

Agents often have multiple tools that could apply. Explicit usage 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 readOnly and idempotent, matching the description's 'Leitura de vendas' (reading sales). The description adds context about returning raw Hotmart data with pagination and bulk support, which goes beyond annotations but does not cover further behavioral details.

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

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

The description is somewhat lengthy and mixes a list of actions with a bulk note. The 'Flattened action: commissions' is confusing and not well integrated. Could be more streamlined 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?

With 9 parameters, no output schema, and zero schema descriptions, the description should provide more comprehensive guidance. It lacks details on how to select the specific action, pagination mechanics, error handling, or prerequisites. Incomplete for an agent to use 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?

Schema coverage is 0%, so the description must explain parameters. It lists many parameters (start_date, end_date, product_id, etc.) but lacks detailed explanations, formats, or constraints. The 'account' parameter is omitted. Partially compensates for missing schema descriptions.

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

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

The description lists multiple sub-actions (history, summary, users, commissions, price_details) that overlap with sibling tools, then states '[Flattened action: commissions]' which is contradictory and unclear. The tool name suggests it is specifically about commissions, but the description implies a broader scope, causing confusion.

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

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

No explicit guidance on when to use this tool versus the many sibling tools (e.g., hotmart_sales_history, hotmart_sales_summary). The mention of bulk support is useful but does not help an agent decide among alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns raw data with pagination (items + page_info) and mentions bulk support, which provides some behavioral context beyond annotations.

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

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

The description is moderately concise but includes a bullet list of actions and extra notes. It could be tighter, but the structure is acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 (9 parameters, no output schema, many siblings), the description is incomplete. It does not clarify the relationship with sibling tools, fully document parameters, or explain pagination behavior beyond mentioning 'page_info'.

Complex tools with many parameters or behaviors need more documentation. 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 several parameters (e.g., start_date, end_date, buyer_email, product_ids) with some format hints, but misses the 'account' parameter and does not provide full semantics for all inputs.

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

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

The description states it is for reading sales data, but it lists multiple actions (history, summary, users, commissions, price_details) while the tool name is 'sales_history'. The note '[Flattened action: history]' is ambiguous, and the description fails to clearly define the tool's specific scope, especially given the existence of sibling tools for those actions.

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

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

No guidance is provided on when to use this tool versus alternative sibling tools like hotmart_sales_commissions or hotmart_sales_summary. The description does not specify prerequisites or context for use.

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

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

The description inconsistently lists multiple actions without an 'action' parameter in the schema, suggesting behaviors not actually supported. Annotations (readOnlyHint) are consistent, but the description creates confusion about what the tool does.

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

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

The description includes a list of actions that are likely irrelevant to this specific tool, making it longer than necessary. The 'Flattened action' note adds confusion rather than clarity. Could be more focused on price_details.

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

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

Given the existence of many sibling tools for specific queries, this description fails to clearly define its unique role. It does not provide enough context to distinguish itself or fully explain its behavior, especially the relationship between the listed actions and the actual functionality.

Complex tools with many parameters or behaviors need more documentation. 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 while the description lists some parameters (start_date, end_date, etc.) with partial format info (date format YYYY-MM-DD), it omits 'account' and 'product_ids' and provides no detailed semantics or constraints. Does not 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 lists multiple actions (history, summary, users, commissions, price_details) and then states 'Flattened action: price_details', creating ambiguity about the tool's actual purpose. The name suggests it is specifically for price details, but the description implies it can perform other queries, which overlaps with sibling tools like hotmart_sales_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 for history, summary, users, or commissions. The description mentions bulk support but does not clarify use cases or alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it returns raw data with items and page_info, which is consistent. However, it does not disclose additional behavioral traits beyond what annotations provide, so the score is average.

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

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

The description is overly long with a bullet list of actions that may be irrelevant if this tool is only for summary. The phrase '[Flattened action: summary]' is confusing. It is not front-loaded with the core purpose.

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

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

Given the existence of sibling tools for each action, this tool's description is incomplete and contradictory. It does not explain how this tool differs from siblings, does not describe pagination or output structure beyond a mention, and lacks clarity on required parameters. The complexity is high (9 params, no required), but the description fails to provide adequate context.

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

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

Schema description coverage is 0%, so the description must compensate. It provides date format (YYYY-MM-DD) and mentions parameters like start_date, end_date, product_id, etc., in the history action context. But it does not explain parameters like account, product_ids, or buyer_email in detail. The bulk support mention is vague. Parameter info is partial.

Input schemas describe structure but not intent. Descriptions should explain 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 (history, summary, users, commissions, price_details) but the tool name is 'hotmart_sales_summary', and there are sibling tools for each of those actions. This creates ambiguity about what this specific tool does. The phrase '[Flattened action: summary]' suggests it is only for summary, but the rest of the description contradicts that.

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

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

No guidance is provided on when to use this tool versus its siblings like hotmart_sales_history, hotmart_sales_users, etc. The description lists all these actions without indicating that there are separate, more specific tools available.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds that it returns raw data with items and page_info pagination, and that bulk execution is supported. This adds moderate 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 verbose and includes irrelevant actions (history, summary, commissions, price_details) that do not apply to this tool. The core purpose is buried. A concise version would focus on users and bulk support.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 optional parameters, no output schema, and 0% schema coverage, the description is insufficient. It does not fully explain how parameters filter the users action or what the response contains beyond vague 'items and page_info'. The agent lacks details to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only lists parameters for the history action, not for users. The only param mentioned for users is product_ids for bulk. Other 8 parameters (account, end_date, etc.) are left unexplained.

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

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

The description clearly states it is for reading sales on Hotmart (Payments API) and specifies that the action is 'users', which indicates getting participants. The sibling tools include other sales-specific tools (e.g., hotmart_sales_history), so the differentiation is clear.

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

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

The description mentions bulk support via product_ids, which is a usage hint. However, it does not explicitly state when to use this tool over alternatives, though the action name and siblings make it somewhat implicit. No exclusion or alternative guidance is given.

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

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

Description adds that the operation is irreversible and returns value to the buyer, which goes beyond annotations. However, there is a potential contradiction: the description claims 'irreversible' while annotations set destructiveHint=false. Despite this, the description still offers useful behavioral context.

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

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

The description is short and efficient, listing the action and key detail (irreversibility). The '[Flattened action: refund]' is slightly redundant but not harmful. Front-loading is good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 it is a write/mutation tool with no output schema and low parameter documentation, the description lacks completeness. Missing description for 'account', no mention of prerequisites or side effects beyond irreversibility, and no guidance on return values.

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

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

The description mentions 'transaction_code' in context of refunding a transaction, adding meaning beyond the schema (which only specifies type string). However, the 'account' parameter is not described, and schema description coverage is 0%, so the description partially compensates.

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

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

The description clearly states the tool performs refunds on Hotmart sales, specifying the action 'refund' and the resource 'transaction_code'. It distinguishes itself from sibling tools as the only refund-specific write tool.

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

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

The description mentions the action is irreversible but provides no guidance on when to use this tool versus alternative tools (e.g., hotmart_sales_history for viewing transactions). No explicit 'when not to use' or comparisons to siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly read-only. The description adds bulk support (product_ids for batched execution), which is useful. However, the description's listing of other actions may mislead about the tool's scope, but it does not contradict annotations.

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

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

The description includes a bullet list of actions that are not all performed by this tool, leading to unnecessary verbosity and confusion. The flattened action note helps, but the extra actions should be omitted or referenced as separate tools.

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

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

With no output schema and 0% schema description coverage, the description is the only source of parameter meaning. While it partially covers list filters, it mixes in irrelevant actions and does not fully explain all 8 parameters. The bulk support is noted, but overall incomplete for a tool with many 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 coverage is 0%, so the description must compensate. It lists some parameters for the list action (product_id, subscriber_email, status with enum values, max_results, page_token) and mentions product_ids for bulk. However, it also mentions parameters for other actions (subscriber_code for purchases/transactions) and does not explain account or other parameters. Partial value added.

Input schemas describe structure but not intent. Descriptions should explain 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, summary, purchases, transactions, switch_plan_plans) but the tool is specifically for the 'list' action as indicated by '[Flattened action: list]'. This overloads the purpose and confuses what the tool actually does. The title is null, so no clarity from that.

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

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

No guidance on when to use this tool vs sibling subscription tools (e.g., hotmart_subscriptions_purchases). The description does not exclude alternatives or provide context for when to use the list action specifically.

Agents often have multiple tools that could apply. Explicit usage 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 aligns by stating 'Leitura' (reading) and lists actions that are all read-only. It adds context about action-specific requirements (e.g., subscriber_code needed for purchases), which is helpful but not extensive.

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

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

The description is structured with bullet points for actions, which aids readability. However, lines like '[Flattened action: purchases]' are confusing and the length could be optimized. Some redundancy exists.

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

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

With 8 parameters, no output schema, and 0% schema coverage, the description needs to be comprehensive. It covers multiple actions but leaves many parameters unexplained (e.g., 'account') and the 'flattened action' concept is unclear. The tool appears to be a meta-tool, but the description does not fully explain its behavior or limitations.

Complex tools with many parameters or behaviors need more documentation. 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 explains parameters for the list action (product_id, subscriber_email, status with enum values, max_results, page_token) and mentions subscriber_code is required for other actions. However, some parameters like 'account' and 'product_ids' are not fully described.

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

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

The description states it is for reading subscriptions on Hotmart, but the tool name includes 'purchases' and the description lists multiple actions (list, summary, purchases, transactions, switch_plan_plans) without clearly differentiating which action is primary or how it relates to sibling tools like hotmart_subscriptions_list. This vagueness 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 gives some filter parameters for the list action but does not provide explicit guidance on when to use this tool versus the many sibling tools. It lacks when-not-to-use instructions and does not mention alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds context about bulk support via product_ids, which is useful. However, it does not explain summary behavior (what aggregates) or the exact behavior of other listed actions.

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

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

The description uses bullet points for actions and includes a note on bulk support. It is somewhat lengthy due to multiple actions, but the flattened action is highlighted. Could be more concise by focusing on the primary summary function.

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

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

With 8 parameters, no output schema, and multiple actions, the description is incomplete. It lacks details on return values, pagination behavior, error handling, and how the summary action specifically differs from list. The existence of sibling tools further complicates context.

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

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

Schema description coverage is 0%, so the description must provide parameter meaning. It explains several parameters (product_id, subscriber_email, status with enum examples, max_results, page_token) and mentions subscriber_code for certain actions. However, not all 8 parameters are fully covered (e.g., account is not explained).

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

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

The description lists multiple actions (list, summary, purchases, transactions, switch_plan_plans) but the flattened action is 'summary'. This creates ambiguity about the tool's primary purpose, especially given sibling tools for each action. The purpose is vaguely defined as 'reading subscriptions' but not sharply distinguished.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 dedicated sibling tools (e.g., hotmart_subscriptions_list, hotmart_subscriptions_purchases). The description does not explain scenarios where this combined tool is preferable or how it differs from alternatives.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description does not contradict these, but it adds minimal behavioral context beyond stating it reads available plans. No mention of rate limits, pagination, or error handling.

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

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

The description is excessively long and includes documentation for multiple unrelated actions (list, summary, purchases, transactions). For this specific tool, only a small portion is relevant, violating conciseness. The structure is poor and not front-loaded.

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

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

The tool has no output schema, so description should clarify return values. It does not. While it mentions bulk execution, it lacks pagination details, error handling, or example output. Given the complexity (8 parameters, no schema descriptions), the description is incomplete.

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

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

With 0% schema description coverage, the description must explain parameters. It only mentions subscriber_code as required and product_ids for bulk support, leaving 6 other parameters completely unexplained. The description mixes parameters from other actions, causing confusion.

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

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

The description states that the action is to list available plans for switching subscriptions, but it is embedded within a broader description for multiple actions, reducing focus. The tool name itself implies the purpose, but the description does not clearly separate it from other actions.

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

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

The description mentions that subscriber_code is required for this action, but it does not provide explicit guidance on when to use this tool versus alternatives like hotmart_subscriptions_write_switch_plan. No contextual cues for when to choose this tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's mention of 'Leitura' (reading) is consistent. It adds the behavioral detail about bulk support (accepts product_ids for batched execution), but no further insights on rate limits, authentication, or side effects beyond annotations.

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

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

The description uses bullet points for actions but is somewhat lengthy and includes redundant formatting. It could be more concise while retaining key information.

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

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

Given the tool's complexity (8 parameters, no output schema, many siblings), the description is incomplete. It does not explain the return format, pagination behavior, or precisely how this tool differs from sibling tools like hotmart_subscriptions_list.

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

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

Schema coverage is 0%, but the description explains some parameters within action contexts (e.g., status enums, product_id, subscriber_email for list action). However, it does not cover all 8 parameters (e.g., account, page_token, max_results are only implicitly mentioned). The description adds moderate value over the bare schema.

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

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

The description lists multiple actions (list, summary, purchases, transactions, switch_plan_plans) under one tool, but the tool name suggests it is specifically for transactions. This creates confusion about the tool's primary purpose. It does not distinguish itself from sibling tools like hotmart_subscriptions_list or hotmart_subscriptions_summary.

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

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

No guidance is provided on when to use this tool versus its siblings. The description merely lists actions without explaining the context for choosing this tool over others.

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

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

The description indicates cancellation is a destructive action, but annotations set destructiveHint=false, creating a contradiction. Additionally, no details are provided about rate limits, authentication needs, or side effects beyond the send_mail 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 moderately concise but includes extraneous details about actions (reactivate, change_due_day, switch_plan) that are not relevant to the specific tool, potentially confusing the agent. The structure is clear but could be streamlined.

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

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

Given 7 parameters, no output schema, and no schema descriptions, the description lacks completeness. It omits return values, error handling, prerequisites, and explanations for several parameters, making it insufficient for a production 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?

With 0% schema coverage, the description partially compensates by explaining subscriber_codes and send_mail for cancel, and other parameters for alternate actions. However, it fails to explain the 'data' and 'account' parameters, leaving gaps in understanding.

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

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

The description clearly states that the tool performs mutations on Hotmart subscriptions and specifies the flattened action is 'cancel'. This distinguishes it from sibling tools like hotmart_subscriptions_write_reactivate and hotmart_subscriptions_write_switch_plan, which handle other specific actions.

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

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

The description implies the tool is for cancellation by noting the flattened action, but does not explicitly state when to use this tool versus alternatives (e.g., for reactivation use another tool). No explicit exclusions or alternatives 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?

Annotations indicate readOnlyHint=false, destructiveHint=false, but the description includes actions like 'cancel' which are destructive. The description does not disclose side effects, permissions, or rate limits, and provides minimal behavioral context beyond the annotations.

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

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

The description is verbose and includes irrelevant actions. It is not front-loaded; the key action 'change_due_day' is buried. Every sentence does not earn its place.

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

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

Given the complexity (7 parameters, nested objects, no output schema), the description lacks information on return values, errors, prerequisites, and behavior for edge cases. It is incomplete for an agent to use safely.

Complex tools with many parameters or behaviors need more documentation. 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 partially explains parameters (e.g., mentions subscriber_codes, send_mail, charge, due_day). It inconsistently references 'data' object for switch_plan but not for change_due_day. The 'account' parameter is not explained. Incomplete and contradictory.

Input schemas describe structure but not intent. Descriptions should explain 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 (cancel, reactivate, change_due_day, switch_plan) despite the tool's name indicating only change_due_day. The purpose is vague and confusing; the agent cannot clearly discern what this specific tool does.

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

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

No guidance is provided on when to use this tool versus alternative sibling tools like hotmart_subscriptions_write_cancel, hotmart_subscriptions_write_reactivate, or hotmart_subscriptions_write_switch_plan. The description does not help an agent choose correctly.

Agents often have multiple tools that could apply. Explicit usage 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 do not indicate read-only or destructiveness, and the description claims this tool can cancel, reactivate, change due day, or switch plans—contradicting the tool name's focus on reactivation. The actual behavior is unclear, and the description does not disclose side effects like email notifications or billing charges.

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

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

The description is verbose and includes information about multiple actions, making it unfocused for a tool intended to perform only reactivation. It lacks front-loaded clarity and contains redundant enumeration.

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

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

Despite having 7 parameters and no output schema, the description covers few details. It does not explain the behavior of the 'data' field, the interaction between parameters, or the return value, leaving the agent with critical gaps.

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

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

Input schema has 0% description coverage. The description only partially explains parameters for some actions (e.g., 'charge' for reactivate, 'send_mail' for cancel) but leaves many parameters (data, account, due_day, subscriber_code) unexplained, especially the nested 'data' object.

Input schemas describe structure but not intent. Descriptions should explain 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 (cancel, reactivate, etc.) but does not clearly state that this tool is specifically for reactivation. The phrase '[Flattened action: reactivate]' is ambiguous and does not resolve the confusion. The purpose is vague and not distinct from sibling tools.

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

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

The description provides no guidance on when to use this tool versus its siblings (e.g., hotmart_subscriptions_write_cancel). It does not state prerequisites, exclusions, or alternatives, leaving the agent to infer 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, but the description lacks details on the effects of switching plans (e.g., timing, billing changes). The vague reference 'conforme doc' adds no transparency.

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

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

The description is verbose and cluttered with irrelevant actions. The switch_plan action is buried in a list, making it inefficient to parse.

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

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

No output schema, no return value description, and prerequisites are omitted. The description is insufficient for an agent to invoke the tool correctly without external documentation.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'data com subscriber_code + novo plano' but does not explain the structure of the 'data' object or other parameters. The schema's 7 parameters remain mostly undocumented.

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

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

The description lists multiple actions (cancel, reactivate, change_due_day, switch_plan) but the tool is only for switch_plan. This ambiguity misleads the agent into thinking the tool can perform other mutations, which are covered by separate sibling tools.

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

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

No guidance on when to use this tool versus alternatives like hotmart_subscriptions_write_cancel. The description does not mention that separate tools exist for the listed actions.

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

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

The description goes beyond annotations (readOnlyHint=false, openWorldHint=true) by disclosing that invoke runs one-off without installing, that writes require workspace owner/admin, and that it returns connect or checkout links for auth/payment. No contradictions with annotations.

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

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

The description is well-organized, starting with purpose, then core flow, then details. It is fairly concise given the amount of information, though slightly long. Every sentence adds value.

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

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

Given the tool's complexity (15 params, no output schema), the description covers the main flow, action semantics, edge cases (credentials, payment), and permissions. However, it lacks explanation of output formats for search/describe and does not clarify parameters like conversation, report_context, request_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 15 parameters and 0% schema coverage, the description should compensate but only explains the action enum in detail. Parameters like query, limit, mcp_id, tool_id, arguments, etc. are not described, leaving the agent to infer their meaning from context.

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

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

The description clearly states the tool is the official marketplace for discovering and running MCPs, with a specific verb-resource pairing. It distinguishes itself from siblings by emphasizing it should be used before external registries and explains the core flow (search→describe→invoke).

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when-to-use guidance: use this tool first for capabilities, prefer invoke over install for occasional use, and details prerequisites (owner/admin for writes, handling credentials/payment). It also names alternatives like list_tools, subscribe, etc.

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

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

Annotations provide basic safety hints (idempotentHint=true, destructiveHint=false). The description adds that the tool submits feedback or bug reports, implying a network call with side effects. However, it does not detail any prerequisites, rate limits, or response behavior beyond the conversation hint. With annotations present, a score of 3 is appropriate.

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

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

Two concise sentences: first states purpose, second gives actionable usage guidance. No wasted words, front-loaded, and easy to parse.

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

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

The description covers purpose and one parameter, but lacks explanation for the 'context' parameter, does not describe return values (no output schema), and omits any caveats or limitations. For a simple feedback tool with 3 parameters, it is adequate but could be more thorough.

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

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

Schema has 3 parameters with 0% description coverage. The description only explains the 'conversation' parameter: 'Include the conversation array with recent messages for reproduction.' It omits guidance on 'context' and 'message' semantics, leaving the agent to infer their meaning from names alone. This provides partial compensation but is not comprehensive.

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

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

The description explicitly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It clearly identifies the action and resource, distinguishing it from sibling tools that focus on authentication, marketplace, or Hotmart operations.

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

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

The description provides a specific usage instruction: 'Include the conversation array with recent messages for reproduction.' This guides the agent on what to include. While it does not explicitly outline when to use versus alternatives, the purpose is self-evident given the unique functionality.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds value by specifying the exact output (platform and adapter versions), complementing the annotations 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?

A single, concise sentence that efficiently communicates the tool's purpose without any wasted words.

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

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

The description is adequate for a simple tool with no parameters and clear annotations. However, since there is no output schema, a brief note on the return format could enhance completeness, but it is not essential.

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

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

There are no parameters, so baseline is 4. The description does not need to add parameter semantics.

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

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

The description explicitly states it shows MCP platform and adapter versions, using specific verb and resource. It clearly distinguishes from sibling tools which serve different purposes.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not indicate prerequisites or exclusions, leaving the agent to infer 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, idempotentHint, and destructiveHint, indicating no side effects. The description adds value by specifying exact return content (installed MCPs, connection status, catalog counts), which goes beyond the annotations.

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

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

A single sentence conveys all necessary information without redundancy. Every word earns its place.

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

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

For a zero-parameter tool with no output schema, the description fully explains what the tool returns. It is complete for its simplicity.

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

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

There are no parameters, so baseline is 4. The description correctly does not add parameter info, as none exist. No further clarification needed.

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

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

The description explicitly states the tool returns toolkit state including installed MCPs, connection status, and catalog tool counts. This clearly distinguishes it from sibling tools like 'authenticate' or 'show_version' which serve different purposes.

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

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

While no explicit 'when-to-use' or alternative guidance is given, the read-only nature and focus on toolkit state implicitly guide the agent to use this for status checks, not for actions. The sibling tools are mostly action-oriented, providing enough context.

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