RD Station

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

The annotations already declare idempotentHint true, destructiveHint false, and readOnlyHint false. The description adds value by explaining the login flow (session vs permanent) and the behavior of calling with/without token. It does not contradict annotations, but could elaborate on effects of repeated calls.

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

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

The description is well-structured with three sentences: context, best practice, and usage. It is front-loaded with key information. It is slightly verbose but every sentence contributes; minor streamlining possible.

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 implies return values (link or confirmation) but does not explicitly state them. Annotations cover idempotent and destructive hints. For a simple auth tool, it covers most needs, but lacks explicit return 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 fully compensates. It explains the sole parameter 'token' thoroughly: its role in session-only login, and that omitting it returns a login link. This adds 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 clearly states the tool's purpose: authenticating to the MCP server. It specifies the resource (MCP.AI for IDE agents) and the action (log in via browser, copy token). It also distinguishes between permanent and session-only login, providing clear scope.

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

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

The description provides explicit when-to-use guidance: for permanent connection, add token to config; for session-only, pass token or call with no args to get a link. It offers a best practice and covers alternatives, making it easy for the agent to decide.

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 mark it as read-only and idempotent. Description adds context: returns authenticated:true and empty pending[] when connected, or connect_url when missing credentials. No contradictions.

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

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

Two sentences, front-loaded with purpose, no wasted words. 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?

No output schema, but description adequately describes return values for both main scenarios. Covers all needed information for a simple status tool.

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

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

Input schema has no parameters, so description need not add param info. Baseline 4 for 0 parameters with 100% schema coverage.

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

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

The description clearly states the tool returns connection status and URLs, distinguishing it from siblings like authenticate. It specifies conditions for different outputs: all connected vs missing credentials.

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?

Implied usage for checking connection status, but no explicit when/why to use vs alternatives like authenticate or marketplace. No exclusion 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds crucial details: writes require owner/admin, invoke works without installation and returns connect/checkout links as needed. It also clarifies that invoke does not bloat the toolkit.

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 dense paragraph that covers many details. While it is well-written and front-loaded, it lacks structural elements like bullet points or sections, making it less concise than ideal. Every sentence adds value, but the length reduces readability.

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 13 parameters and no output schema, the description adequately explains the core flow (search → describe → invoke), auth/payment handling, and the distinction between install and invoke. It falls short in documenting all parameters and output behavior, but covers the most important aspects for typical usage.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'action' parameter with its enum values and implications, and mentions mcp_id, tool_id, arguments in context. However, other parameters (limit, query, message, immediate, tier_slug, conversation, request_name, report_context, request_details) are not explicitly described, 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 the tool is the official marketplace for discovering and running MCPs, with a specific verb ('marketplace') and resource ('MCPs/tools'). It distinguishes itself from sibling tools like rdstation_* by being a meta-tool for all MCPs, and explicitly says to use it before external registries.

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 and when-not-to-use guidance: use this tool first for any MCP capability, invoke for one-off use vs install for permanent, and notes that writes require owner/admin. It also explains when to retry (if credential/payment needed).

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 the tool returns the account name, which is consistent but provides minimal additional 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 very short but lacks necessary detail, making it under-specified rather than concise. It fails to earn its place with sufficient information.

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

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

For a simple tool with one parameter and no output schema, the description should explain the parameter and return value more thoroughly. It only mentions 'account name' without format details.

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

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

The input schema has one parameter (account) with 0% description coverage, and the tool description does not explain its purpose, format, or constraints.

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 returns active RD Station account data, specifically the account name. It distinguishes itself from sibling tools like rdstation_list_accounts which lists multiple 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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusion criteria.

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

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

Annotations are all false, and the description only states that 'funnel' relates to the contact's stage in the default funnel. It does not disclose side effects, permissions, or idempotency beyond the flat annotations.

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

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

The description is a bit cluttered with multiple actions and lacks focus on the primary 'funnel' action. It is not severely verbose 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 4 parameters including nested objects and no output schema, the description fails to explain return values, expected behavior per action, or prerequisites. It is incomplete for a tool of this complexity.

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

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

The description adds meaning for 'identifier_type' and 'identifier' (email/uuid) but does not explain 'fields' or 'account' for the funnel action. With 0% schema coverage, this incomplete clarification is insufficient.

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 deals with contacts in RD Station Marketing and mentions the 'funnel' action, but it also lists 'get' and 'upsert' actions which are separate sibling tools. This mixing blurs the primary purpose and may confuse agents.

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

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

No guidance is provided on when to use this tool versus siblings like rdstation_contacts_get or rdstation_contacts_upsert. There is no mention of prerequisites or scenarios.

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 implies a read-only operation ('get: busca UM contato'), but annotations set readOnlyHint to false, indicating potential side effects. This is a clear contradiction, and the description does not disclose any behavioral traits beyond the conflict.

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

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

The description is short but includes irrelevant information about other tools, making it less focused. It lacks clear structure and could be redesigned to only cover the get 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?

Without an output schema and with incomplete parameter explanations, the description fails to provide a complete picture. Missing details on fields, account, return format, and error handling reduce its usefulness for an AI agent.

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

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

With 0% schema description coverage, the description must compensate but only explains identifier and identifier_type, omitting fields and account. It adds partial meaning but is insufficient for full parameter 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 states 'busca UM contato por email ou uuid' which clearly identifies the action of fetching a single contact. However, it unnecessarily includes descriptions of upsert and funnel actions, which are separate sibling tools, diluting 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 provides basic parameter instructions ('Identifique o contato por identifier_type + identifier') but does not offer guidance on when to use this tool versus siblings like upsert or funnel. No explicit when-to-use or when-not-to-use information.

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 correctly states it creates/updates (consistent with readOnlyHint=false), but lacks details on side effects, idempotency, or authentication requirements. With minimal annotation support, the description should offer more 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 verbose and includes irrelevant actions (get, funnel) that bloat the text. The 'Flattened action' note adds confusion. A concise, focused description on upsert alone would be more effective.

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

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

No output schema and no return value description. For a write operation, the agent needs to know expected response (e.g., created/updated contact ID). The description omits error handling, success criteria, and any usage context beyond basic parameter identification.

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 explains identifier and identifier_type minimally, and mentions 'fields' for contact fields, but does not describe the 'account' parameter or specify allowed field keys. Incomplete semantics for a 4-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 three actions (get, upsert, funnel) but the tool is specifically 'upsert'. The 'Flattened action: upsert' note is confusing and fails to clearly state that this tool only performs upsert operations. The verb 'cria/atualiza' is clear but diluted by extraneous actions.

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

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

No guidance on when to use upsert vs the sibling tools rdstation_contacts_get or rdstation_contacts_funnel. The description mentions identifier identification but does not provide context for choosing this tool over alternatives.

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

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

Annotations already indicate it is not read-only and not destructive. The description adds the HTTP method and endpoint, but does not disclose additional behavioral traits like authentication requirements, rate limits, or side effects. It provides moderate 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 succinct sentences in Portuguese, front-loading the action and then providing usage guidance. Every phrase adds value 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?

Given the simplicity (2 params, one nested object), the description covers the main input structure but does not mention return values or success/failure indication. It leaves out potential context about event processing 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?

The description adds meaningful structure to the 'event' parameter by specifying expected keys (event_type, event_family, payload with email), compensating for the schema's 0% property description coverage. However, it does not explain the optional 'account' parameter.

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

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

The description clearly states the tool creates a conversion event via POST to '/platform/events', providing a specific verb and resource. It distinguishes from sibling tools like 'rdstation_contacts_upsert' by focusing on events, but does not explicitly differentiate usage contexts.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only explains what the tool does, leaving the agent without context for appropriate invocation.

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 readOnlyHint, idempotentHint, destructiveHint = false. The description adds context by mentioning the specific data returned (account_id, label) and the scope (linked to this install), 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?

The description is a single concise sentence that directly states the tool's purpose and output. Every word is informative with no redundancy.

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

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

The description mentions the output fields (account_id, label) but omits information about the optional parameter and its effect. Without an output schema, more detail on return format 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?

The input schema has one optional parameter 'account' with 0% coverage. The description does not explain what the parameter does (e.g., filter by account). Given the low schema coverage, the description should add meaning but fails to do so.

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

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

The description clearly states 'Lists RD Station accounts linked to this install (account_id, label)', specifying the verb (list), resource (accounts), and scope (linked to install). It distinguishes from sibling tools like rdstation_account_info, though not explicitly.

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 rdstation_account_info. No explicit conditions or exclusions are provided, leaving the agent to infer usage from the purpose alone.

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

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

Annotations show readOnlyHint=false and destructiveHint=false, but the description doesn't add behavioral context such as idempotency, error handling, or side effects of creation. Minimal disclosure beyond stating it creates.

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

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

The description is verbose with irrelevant actions (list, delete) for a create-specific tool. The structure is messy and not front-loaded. Could be much shorter and focused.

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

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

Given the presence of sibling tools for list/delete and the complexity of a nested parameter, the description lacks prerequisites, typical usage, or return value. No output schema amplifies the gap.

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

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

Schema coverage is 0%, so description must compensate. It mentions that the 'webhook' object should contain 'url, event_type, entity_type…' but does not explain 'uuid' or 'account' parameters. Incomplete guidance on 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 indicates the 'create' action for webhooks, but also lists 'list' and 'delete' actions which are confusing given the tool is specifically for create due to flattened action. This ambiguity lowers clarity.

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

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

No guidance on when to use this tool vs alternatives like list or delete. The description merely lists actions without context on which tool to use for each.

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 the tool removes a webhook, which is a destructive action. However, the annotation 'destructiveHint' is set to false, directly contradicting the described behavior. No additional behavioral context (e.g., irreversibility, side effects) is provided. This contradiction renders the description misleading.

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

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

The description includes extraneous actions (list, create) that are not relevant to the delete operation, adding clutter. While the relevant line is clear, the overall structure could be more focused and 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?

For a simple delete tool with three parameters and no output schema, the description is incomplete. It omits details on how the 'account' and 'webhook' parameters are used, what constitutes a successful deletion, potential errors, and whether the operation is idempotent. The lack of completeness may hinder correct invocation.

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

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

The description clarifies that 'uuid' is required for the delete operation, adding value beyond the schema (which lacks required field and descriptions). However, the parameters 'account' and 'webhook' are not explained in the context of deletion; their purpose remains unclear. Given zero schema coverage, the description partially compensates but leaves 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 explicitly states 'delete: remove um webhook (requer uuid).' This clearly identifies the tool's purpose: to delete a webhook identified by its UUID. The tool name reinforces this purpose, leaving no ambiguity.

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

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

The description indicates that the uuid is required for deletion, providing basic context. However, it lacks guidance on when to use this tool versus alternatives like list or create, and does not mention prerequisites or scenarios where deletion is inappropriate. No explicit when-to-use or when-not-to-use instructions 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?

Description claims list (read) but annotations show readOnlyHint=false; includes destructive actions but destructiveHint=false. Contradicts 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?

Verbose and includes irrelevant create/delete details. Could be reduced to a single sentence about listing webhooks.

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?

Incomplete for a list tool; no explanation of parameters, return format, or how to filter/limit results. Misleading due to extra actions.

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

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

Schema coverage is 0%; description vaguely mentions webhook object for create but doesn't clarify which parameters apply to list. No parameter descriptions for uuid or account.

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

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

The name and flattened action indicate 'list', but the description includes create and delete actions, obscuring the tool's primary purpose.

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

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

No guidance on when to use this list tool versus the sibling create/delete tools; the description conflates all three actions.

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

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

Annotations declare idempotentHint=true, destructiveHint=false, readOnlyHint=false. Description does not add behavioral details beyond what annotations provide. No contradictions.

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

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

Two sentences: first states purpose, second gives usage tip. No unnecessary 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?

Tool is simple with no output schema. Description covers purpose and one parameter hint, but lacks explanation for two parameters. Still, minimal viable feedback 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 description must compensate. It mentions conversation parameter but not context or message. Message is required but description does not clarify its content or format.

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

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

Description clearly states verb 'report' and resources 'bug, missing feature, or send feedback'. It distinguishes from sibling tools which are mostly RD Station operations or 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?

Description explicitly tells to include the conversation array for reproduction. However, it does not provide when-not-to-use scenarios, but for a feedback tool this is sufficient.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description does not add additional behavioral context beyond what is stated in annotations, which is acceptable for a straightforward read tool.

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

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

The description is a single, clear sentence with no extraneous words. It is well front-loaded and 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?

Given the tool's simplicity (no parameters, no output schema, simple read operation), the description is fully adequate. It explains what the tool does without requiring additional context.

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

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

The input schema has zero parameters, so the description does not need to explain them. The baseline for 0 parameters is 4, and the description adds no further parameter information, which is appropriate.

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

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

The description uses a specific verb ('show') and identifies the resource ('current MCP platform and adapter versions'). It is distinct from sibling tools, none of which display version information.

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

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

The description clearly states the purpose, and there is no ambiguity about when to use it. However, it does not explicitly exclude alternative use cases or provide context for non-use, though none are needed given the tool's simplicity.

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 value by specifying exactly what information is returned (installed MCPs, connection status, catalog counts), which is not covered by annotations. No contradictions.

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

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

A single concise sentence that is front-loaded with the main action and includes all necessary information. No extraneous 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?

Given the tool's simplicity (no parameters, no output schema), the description adequately conveys the return information. While it could be slightly more precise about format, it is sufficient for a read-only info tool.

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

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

The tool has zero parameters and schema coverage is 100% (trivially). Per guidelines, a baseline of 4 is appropriate when no parameters exist to describe.

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 what the tool does: 'Returns the current toolkit state' with specific details (installed MCPs, connection status, catalog tool counts). This clearly distinguishes it from sibling tools like authenticate or marketplace.

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

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

The description implies usage for checking toolkit state but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.

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