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 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no further behavioral context (e.g., pagination, authentication, or rate limits) beyond confirming it's a listing operation.

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

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

Single sentence efficiently states purpose and optional filters. No redundant information, front-loaded with main action.

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

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

Description lacks details on pagination behavior, response format, and how to use page_token. For a listing tool with no output schema, more context is needed to understand what the tool returns and how to iterate results.

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

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

Schema description coverage is 0%, but description mentions max_results and page_token as optional filters. However, the 'account' parameter is not mentioned, and no detail on parameter usage or data types is provided, leaving 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?

Description explicitly states the tool lists creator products on Hotmart with optional filters. The verb 'Lista' and resource 'produtos' are clear and distinct from sibling tools about sales, subscriptions, and accounts.

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

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

No guidance on when to use this tool versus alternatives like hotmart_sales_history or hotmart_subscriptions_list. The description only mentions optional filters but does not provide context for selecting this tool over 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?

The description aligns with annotations by stating 'Leitura de vendas' (reading sales), consistent with readOnlyHint=true and destructiveHint=false. It mentions returning raw data with pagination and bulk support via product_ids. However, it adds little beyond what annotations already convey. No contradictions found.

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

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

The description is somewhat lengthy and contains bullet points that mix actions and parameters. The 'Flattened action: commissions' note and 'Bulk support' add useful detail but could be more integrated. Overall, it's adequately sized 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 (9 parameters, no output schema, multiple siblings), the description is insufficient. It does not specify which parameters are required for the commissions action, nor does it fully describe the output beyond 'raw data with items and page_info'. Usage context and error conditions are missing.

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

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

Schema description coverage is 0%, so the description must compensate. While it lists some parameters in the context of the 'history' action (e.g., start_date format YYYY-MM-DD), it does not map parameters to the 'commissions' action which is the tool's focus. The bulk support mention clarifies product_ids usage, but other parameters' relevance for commissions is unclear.

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

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

The description mentions multiple actions (history, summary, commissions, price_details) but then indicates 'Flattened action: commissions' which suggests the tool is actually focused on commissions. This creates ambiguity about whether the tool can perform all listed actions or only commissions. The name hotmart_sales_commissions implies a specific focus, but the description blurs the boundary with sibling tools like hotmart_sales_history and hotmart_sales_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 explicit guidance is provided on when to use this tool versus its siblings (e.g., hotmart_sales_history, hotmart_sales_summary). The description lists parameters but does not explain the scenario for using commissions compared to other actions. Without this, an AI agent cannot easily decide which tool to invoke.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by stating it returns raw data with items and pagination info, and mentions flattened action and bulk support, which are behavioral traits 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 structured with bullet points but includes jargon like '[Flattened action: history]' and repeats 'Bulk support'. It could be more concise while retaining clarity.

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

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

Given the complexity (9 params, no output schema), the description covers return structure and most parameters. However, it lacks explanation for the 'account' parameter and does not fully address how to select among the multiple actions, leaving some ambiguity.

Complex tools with many parameters or behaviors need more documentation. 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 compensates significantly. It provides meaningful details for most parameters: date format (YYYY-MM-DD), lists filters for history action, and mentions product_ids for bulk. Only the 'account' parameter is undocumented, which is a minor gap.

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

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

The description clearly states it is for reading sales from Hotmart's Payments API, listing specific actions like history, summary, commissions, and price_details. However, it's confusing because sibling tools exist with the same names, and the tool bundles multiple actions without clear differentiation.

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

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

No explicit guidance on when to use this tool versus sibling tools like hotmart_sales_summary or hotmart_sales_commissions. The description lists actions but doesn't clarify context for choosing one over another.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds value by stating it returns raw data with paginated items and page_info, and supports bulk execution with product_ids. No contradiction with annotations.

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

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

The description starts with the main purpose but includes an unnecessary list of other actions that could be omitted. The flattened action note adds clarity but could be more prominent. Fairly concise overall, 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?

With 9 parameters, no required, no output schema, and multiple implied actions, the description is incomplete. It does not map parameters to actions, lacks details on return structure beyond pagination, and does not explain how the bulk support works.

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

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

Schema coverage is 0%, so description must compensate. It lists some parameters (start_date, end_date, etc.) only in the context of the 'history' action, not for price_details. The bulk support parameter product_ids is mentioned but not explicitly linked to the tool's primary action. No explanations of parameter formats or valid values.

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

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

The description states it reads sales price details from Hotmart Payments API, and the flattened action is price_details. However, it also lists other actions (history, summary, commissions) which causes ambiguity about the tool's specific purpose, especially given 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 explicit guidance on when to use this tool vs siblings. The description lists multiple actions but doesn't clarify that this tool is specifically for price_details, nor does it exclude using sibling tools for other actions. The presence of sibling tools for history, summary, commissions implies alternatives, but no comparative guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it returns raw Hotmart data with items and page_info, which is useful. However, it lists multiple actions that may not all be available, potentially misleading about behavior. No explicit contradiction with annotations.

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

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

Description is verbose and includes a list of actions that likely do not all apply, leading to confusion. The '[Flattened action: summary]' note suggests extraneous content. Could be more concise and front-loaded with the actual operation.

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

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

Given many sibling tools, the description fails to differentiate this tool from hotmart_sales_history, hotmart_sales_commissions, etc. No output schema, so agent does not know the return structure beyond generic 'items + page_info'. Response format for a summary is ambiguous.

Complex tools with many parameters or behaviors need more documentation. 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%. Description mentions 6 of 9 parameters (start_date, end_date, product_id, transaction_status, buyer_email, max_results, page_token), missing account and product_ids interaction. It adds 'Bulk support: accepts product_ids' but does not explain relation to product_id. Incomplete for a 9-parameter tool.

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

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

The description lists multiple actions (history, summary, commissions, price_details) causing confusion about the actual function. The '[Flattened action: summary]' hint suggests only summary is used, but this is not explicit. Sibling tools exist for the other actions (e.g., hotmart_sales_history), so the tool's scope is unclear.

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

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

No clear guidance on when to use this tool versus siblings. It mentions 'Bulk support: accepts product_ids' but does not explain when to use bulk vs single product_id. The description does not specify prerequisites 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, idempotentHint=true, and destructiveHint=false. The description adds context like bulk support for product_ids but does not disclose other behavioral traits such as authentication requirements or rate limits.

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

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

The description is structured with bullet points but includes extraneous information about summary and purchases actions that are not part of this tool. This increases length without adding value for the tool's core 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?

Given 8 parameters and no output schema, the description covers filtering and bulk support but does not explain return format, pagination behavior beyond page_token, or any error cases. It is adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. 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 listing key parameters (product_id, subscriber_email, status with acceptable values, max_results, page_token) and their roles. It misses the 'account' parameter but provides good context overall.

Input schemas describe structure but not intent. Descriptions should explain 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 'Leitura de assinaturas' (reading subscriptions) and lists specific filters. It distinguishes from sibling tools like hotmart_subscriptions_summary and hotmart_subscriptions_purchases by noting they handle summary and purchases actions, while this tool is flattened to 'list'.

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

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

The description mentions other actions (summary, purchases) but does not explicitly state when to use this tool versus those siblings. It implies usage for listing subscriptions with filters, but lacks direct guidance on 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 idempotentHint=true, so the core safety profile is clear. The description adds context about batched execution via product_ids and a cryptic 'Flattened action: purchases', but lacks details on pagination behavior, error handling, or how actions are selected.

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

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

The description is moderately structured with bullet points but is somewhat messy. The inclusion of '[Flattened action: purchases]' is unclear, and the overall flow could be more concise and logically organized.

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

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

Given the tool's complexity (multiple actions, 8 parameters, bulk support, no output schema) and overlap with sibling tools, the description is insufficient. It does not explain return values, how to invoke specific actions, or error handling, leaving an agent with significant gaps.

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

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

With 0% schema description coverage, 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 subscriber_code and product_ids for other actions, but does not describe the account parameter or clarify which parameters apply to which action. The partial enum listing for status is helpful but incomplete.

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

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

The description states it reads subscriptions and lists three actions (list, summary, purchases), but the tool's name and bundling with multiple actions obscure its primary purpose, especially given sibling tools like hotmart_subscriptions_list and hotmart_subscriptions_summary that seem to duplicate functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 separate sibling tools for listing or summarizing subscriptions. The description lists actions but does not clarify the trade-offs or prerequisites.

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

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

Annotations indicate read-only and idempotent behavior, which aligns with 'Leitura' in the description. The description adds value by detailing the actions, filters, and bulk support, going beyond annotations.

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

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

The description is somewhat verbose with bullet points and includes jargon like '[Flattened action: summary]'. It could be more concise and structured.

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

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

Given 8 parameters, no required ones, and no output schema, the description fails to explain how the three actions are triggered based on parameter combinations. Bulk support interaction with actions is unclear, leaving behavior ambiguous.

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

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

Schema coverage is 0%, so description must compensate. It describes many parameters for list (e.g., status with enums) and mentions subscriber_code for purchases, but lacks description for 'account' parameter and does not clarify how actions are selected.

Input schemas describe structure but not intent. Descriptions should explain 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 in Hotmart and lists three actions: list, summary, and purchases. It distinguishes from siblings by covering multiple actions, though the primary purpose is 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?

The description mentions bulk support and that purchases require subscriber_code, but it does not explicitly explain when to use this tool versus the sibling list or purchases tools, nor when to choose summary over list.

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

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

With annotations providing no behavioral hints (readOnlyHint false, destructiveHint false), the description carries full burden. It discloses that send_mail (default true) notifies the subscriber but does not mention prerequisites (e.g., subscription must be active), side effects (e.g., immediate termination), or reversibility. The 'charge' parameter's relevance to cancel is not explained, creating ambiguity.

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

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

The description is short and uses a bullet-like structure for clarity. However, it includes both cancel and reactivate descriptions, which is redundant for a tool dedicated to cancel. Trimming to only cancel would improve 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 4 parameters, no output schema, and minimal annotations, the description leaves gaps. It does not explain the return value, error cases, or the role of the 'account' parameter. The 'charge' parameter's inclusion without context is confusing. The tool is a mutation but lacks information on state changes or confirmations.

Complex tools with many parameters or behaviors need more documentation. 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 add meaning. It explains 'subscriber_codes' (required) and 'send_mail' (default true), but not 'account' or 'charge'. The explanation of 'charge' is only given for the reactivate action, leaving its role in cancel unclear. Thus, only 2 of 4 parameters are meaningfully documented.

Input schemas describe structure but not intent. Descriptions should explain 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 title and description clearly indicate this tool cancels Hotmart subscriptions. The 'cancel' action is explicitly listed, and the flattened action [cancel] resolves ambiguity. However, the inclusion of the 'reactivate' action in the same description could cause confusion, though the title and final note clarify the focus.

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

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

The description mentions both cancel and reactivate actions but does not explicitly guide when to use this tool versus the sibling 'hotmart_subscriptions_write_reactivate'. It lacks a clear statement like 'Use this tool to cancel subscriptions; use the sister tool to reactivate.' The presence of the 'charge' parameter, which seems only relevant for reactivate, further muddies usage context.

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

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

The description adds behavioral info: charge defaults to false. However, it lacks detail on side effects, prerequisites, or response behavior. Annotations already indicate mutation (readOnlyHint=false), so non-contradictory but minimally additive.

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

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

The description is short but includes both cancel and reactivate actions, making it less concise for this tool. It could be trimmed to focus solely on reactivate, removing the cancel-specific lines.

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

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

As a mutation tool with no output schema, the description should explain expected outcomes, success/failure indicators, and side effects. It provides only basic action info and one default value, leaving significant gaps.

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

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

With 0% schema description coverage, the description must explain parameters. It covers subscriber_codes and charge (partially), but omits account and send_mail for the reactivate action. send_mail is only mentioned in the cancel context, not for reactivate.

Input schemas describe structure but not intent. Descriptions should explain 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 on Hotmart subscriptions and specifies the reactivate action: 'reativa 1+ assinaturas'. Although it also mentions cancel, the tool name and flattened action clarify it is for reactivation. The purpose is clear but slightly diluted by extraneous info.

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

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

The description implies usage through action definitions and sibling tools (e.g., hotmart_subscriptions_write_cancel), but does not explicitly state when to use this tool versus alternatives, nor provide criteria for setting parameters like charge.

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

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

Discloses key behaviors beyond annotations: invoke works even when MCP is not installed (one-off), returns connect/checkout links for auth/payment, and describes the install vs invoke distinction. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

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

The description is effective but lengthy (12+ sentences). While front-loaded with purpose and flow, it includes redundant details that could be streamlined. Every sentence earns its place, but the density 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?

For a complex tool with 13 parameters, 0% schema coverage, and no output schema, the description provides a good high-level understanding of workflows and behaviors. However, it lacks detailed parameter documentation and does not describe return values, leaving some gaps in completeness.

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

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

Schema coverage is 0%, but the description explains the 'action' enum values and the overall use of mcp_id, tool_id, arguments in the workflow. However, many parameters (limit, query, message, immediate, tier_slug, conversation, request_name, report_context, request_details) are not defined in the description, leaving 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 it is 'THE official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It specifies a verb (discover/run) and resource (MCPs/tools), and distinguishes from sibling tools that are specific (e.g., hotmart_*) rather than the meta-discovery 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?

Explicitly says 'use THIS tool FIRST, before any external/generic registry' when the user wants a capability. Provides a core flow and clear guidance: prefer invoke for single use, use install for permanent toolkit addition. Also notes write operations require workspace owner/admin, and describes credential/payment handling.

Agents often have multiple tools that could apply. Explicit usage 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.