RD Station

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

The description explains the two authentication flows (permanent config vs session token), what happens when no token is provided (returns a link), and that the config method is for a 'permanent, non-expiring connection'. Annotations (idempotentHint true) are consistent with the description.

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 but well-structured, beginning with the tool's target audience and use case. It efficiently covers authentication options without unnecessary detail, though a few words could be trimmed.

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

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

The description provides complete context for an authentication tool: methods, permanence, token usage, and expected user action. Given the optional parameter and no output schema, it sufficiently informs the agent about invocation and 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 input schema has 0% description coverage for the 'token' parameter, but the description fully explains its semantics: if provided, it authenticates with that JWT; if omitted, it returns a login link. This adds complete meaning beyond the schema.

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

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

The description clearly states the tool's purpose: authenticate to the MCP server using a token, either permanently via config or session-only via the tool call. It distinguishes from sibling tools like 'connect' and 'marketplace' which serve different functions.

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

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

The description provides clear guidance on when to use each authentication method (config for permanent, call for session) and how to pass the token. It does not explicitly state when not to use the tool, but the context 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?

Annotations already indicate readOnly, idempotent, non-destructive. The description adds valuable context about conditional behavior (connected vs. missing credentials) and what fields are returned (authenticated, pending, connect_url), making it more than just repeating annotations.

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

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

Two sentences, no fluff. The first sentence states the main purpose, the second details the two states. Every word is necessary 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?

Despite no output schema, the description fully explains the return values for both connection states. No parameters need documentation, so the description is complete for the tool's 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?

With zero parameters, the input schema is empty. The description adds all meaning by explaining the output, which is the entire value of the tool. Per guidelines, 0 params earns baseline 4, but the description exceeds that by clarifying return behavior.

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 returns connection status and URLs, and explains the two possible states (all connected vs. credentials missing). This distinguishes it from siblings like authenticate, making the purpose unambiguous.

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

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

The description implies this tool is for checking connection status, not for performing authentication. It gives context on when it returns URLs versus empty pending, but doesn't explicitly exclude other uses or mention alternatives like authenticate.

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, openWorldHint=true. Description adds rich behavioral context: invoke works without installation, writes require workspace owner/admin, paid MCPs return checkout links, etc. 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?

Despite length, every sentence adds value. Front-loaded with main purpose and core flow. Efficiently packed with essential guidelines and caveats for a complex tool with multiple actions.

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?

Covers main use cases, credential/billing handling, write permissions, and differentiation between invoke/install. Lacks explicit mention of error handling or response format, but given no output schema, the description is comprehensive enough for a marketplace tool with 15 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?

With 0% schema description coverage, the description compensates by explaining the overarching structure and actions, though it doesn't detail every parameter individually. It clarifies how 'action' controls flow and mentions key parameters like query, mcp_id, tool_id, arguments implicitly within the usage narrative.

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 catalog and execution platform. It uses specific verb+resource ('search', 'describe', 'invoke', etc.) and distinguishes itself from sibling tools by being the central gateway for discovering and running MCPs.

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?

Extensive guidance on when to use this tool first over external registries, core flow with search→describe→invoke, when to use invoke vs install, and how to handle credentials/payments. Explicitly contrasts 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 and idempotentHint, so the description adds minimal value beyond stating the return type (account name). No mention of authentication requirements or behavior when no account parameter is provided.

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, efficient sentence. However, it is very brief and could benefit from a slightly more structured format (e.g., listing return attributes).

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

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

Given the simple tool (1 optional param, no output schema), the description is minimally adequate but lacks details on what 'active' means and the exact return value structure beyond 'nome da conta'.

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 does not explain the 'account' parameter's role. It only describes the output, leaving the parameter's purpose ambiguous.

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

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

The description clearly states the tool returns active RD Station account data, specifically the account name. It distinguishes from the sibling 'rdstation_list_accounts' by implying a single account context, 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_list_accounts'. The description does not mention prerequisites or context for 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 give no safety hints; the description does not clarify whether 'funnel' reads or writes the funnel stage. Ambiguity about side effects, with no explanation of what happens to the contact.

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 moderately sized with bullet points, but includes redundant actions (get/upsert) that do not belong to this tool. Could be more concise by focusing only on funnel.

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 of multiple potential actions, lack of output schema, and zero schema coverage, the description is insufficient. It does not explain return values, error conditions, or the effect of the funnel action.

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% description coverage. The description explains identifier and identifier_type for identification but does not clarify which parameters apply to the 'funnel' action (e.g., whether 'fields' is needed). Incomplete semantic mapping.

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 three actions (get, upsert, funnel) but the tool name and flattened action indicate it's specifically for 'funnel'. This confuses the tool's purpose with sibling tools rdstation_contacts_get and rdstation_contacts_upsert.

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 the sibling get/upsert tools. The description lists all actions without explaining which is appropriate or how to choose.

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

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

The description claims it is a 'get' action (read-only), but annotations set 'readOnlyHint' to false, implying the tool may modify state. This is a direct contradiction, reducing transparency to the lowest possible score per instructions.

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 mixes multiple actions (get, upsert, funnel) in one block, which is not ideal for a single tool. The flattened action helps, but the structure 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?

The tool has 4 parameters and no output schema. The description only states that it retrieves a contact, but omits return format, error handling, and the purpose of the optional 'account' and 'fields' parameters. This leaves significant gaps for an agent.

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

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

Schema description coverage is 0%, so the description should compensate. It explains identifier and identifier_type meaningfully, but does not cover the 'account' or 'fields' parameters for this tool. The mention that 'fields' is for upsert is only partially helpful.

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 retrieves a single contact ('busca UM contato') by email or UUID. It distinguishes from sibling tools like rdstation_contacts_funnel and rdstation_contacts_upsert. However, the description is cluttered with other action descriptions, slightly reducing 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 specifies how to identify the contact using identifier_type and identifier, with examples of 'email' and 'uuid'. While it does not explicitly contrast with sibling tools, the usage context is clear and the required parameters are indicated.

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 hints (readOnlyHint=false, destructiveHint=false), and description confirms the create/update behavior. However, it lacks details on merge behavior, authentication needs, or side effects. Adds some value but not deep 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?

Description is somewhat cluttered with bullet points for multiple actions, including irrelevant ones for this tool. The flattened action note helps, but the structure could be more streamlined 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?

Lacks any mention of return values, which is a gap given no output schema. Also does not describe the account parameter. For a mutation tool, more completeness about response and prerequisites 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?

With 0% schema description coverage, the description compensates by explaining the fields, identifier, and identifier_type parameters. Only the account parameter remains unexplained. This adds meaningful context beyond the schema.

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

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

Tool description explicitly states it performs upsert (cria/atualiza) on contacts, clearly distinguishing from sibling tools get and funnel. However, the description also includes unrelated actions (get and funnel) which slightly muddles the focus on the upsert action.

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 indicates how to identify the contact (by email or uuid), but does not explicitly state when to use upsert versus the sibling tools get or funnel. The usage context is implied but not directly guided.

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 that it creates an event and hints at payload structure (event_type, event_family, email). However, no details on idempotency, rate limits, or side effects beyond creation.

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, no fluff. First sentence states purpose clearly, second gives parameter guidance. Perfectly concise 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?

Minimally adequate: explains creation and payload hint, but missing explanation for optional 'account' parameter, no return value info, no error handling. Given complexity (nested object), more detail would help.

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% description coverage; the description provides necessary guidance on the 'event' parameter's structure (event_type, event_family, payload with email), compensating for the schema's lack of detail. However, the 'account' parameter remains 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?

Description explicitly states it creates a conversion event in RD Station Marketing, specifying the HTTP method and endpoint. This clearly distinguishes it from sibling tools dealing with contacts, webhooks, accounts, 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 mention of prerequisites, limitations, or when not to use. The description only says to pass the event payload.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds scope 'vinculadas a este install' and return format (account_id, label), providing helpful 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?

Single sentence, no waste. Concise and front-loaded with key verb and resource.

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 partially covers return format. Lacks details on pagination, limits, or parameter usage. Adequate for a simple list but incomplete for full clarity.

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 one undocumented parameter 'account' with 0% description coverage. Description does not explain the parameter's purpose or behavior, missing an opportunity to clarify filtering options.

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 'Lista' (lists) and resource 'contas RD Station' with scope 'vinculadas a este install'. Mentions returned fields account_id, label. However, does not differentiate from sibling 'rdstation_account_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?

No guidance on when to use this tool versus alternatives. Does not specify context, prerequisites, or when not to 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?

Annotations are all false, so the description carries the full burden. It only mentions the creation action but does not disclose side effects (e.g., whether existing webhooks are modified), authentication requirements, or error scenarios. 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 includes extraneous information about list and delete actions, and the note '[Flattened action: create]' adds meta-complexity without value. It could be reduced to a single focused sentence: 'Creates a webhook. Provide a webhook object with url, event_type, and entity_type.'

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

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

Given the lack of output schema, annotations, and parameter descriptions, the tool requires more context. The description does not explain success/error responses, required permissions, or the relationship between uuid and account parameters. Incomplete for reliable invocation.

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

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

Schema description coverage is 0%. The description adds some value by hinting that the 'webhook' parameter should contain fields like url, event_type, entity_type, etc. However, it does not explain the 'uuid' or 'account' parameters, leaving them ambiguous. The guidance on the webhook object 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 'create: cria um webhook (passe 'webhook' com url, event_type, entity_type…)' which clearly indicates the tool creates a webhook. It identifies the verb (create) and resource (webhook). However, the inclusion of list and delete actions in the same description for a flattened create tool adds slight confusion, but the core purpose is still 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?

No guidance is given on when to use this tool versus alternatives. The sibling tools rdstation_webhooks_list and rdstation_webhooks_delete exist but are not referenced. The description does not specify when creation is appropriate or any prerequisites.

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

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

The description states 'remove um webhook' implying a destructive action, but annotations set destructiveHint to false. This is a contradiction. No further behavioral details are provided.

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 poorly structured, mixing general information about webhooks with a list of three actions, only one of which pertains to this tool. The flattened action note adds clutter. It is not concise and contains redundant information.

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

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

The description lacks details on return values, error conditions, or how to obtain the uuid. Given the lack of output schema and the complexity of the tool (3 parameters, nested objects), more context is needed for correct 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?

The description specifies that uuid is required for delete, which adds some semantics, but the input schema shows all parameters optional and does not enforce a requirement. The webhook parameter is described for create, but for delete it is irrelevant. Schema coverage is 0%, so the description should compensate but does so inadequately.

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 includes a bullet for delete ('remove um webhook (requer uuid)') but also lists list and create actions, making the purpose less distinct. The tool's primary function is clear but diluted by extraneous 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?

No guidance is provided on when to use this tool versus alternatives like rdstation_webhooks_list or rdstation_webhooks_create. The description does not mention context, prerequisites, or exclusions.

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

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

The description includes both read (list) and write (create, delete) actions, while annotations set readOnlyHint: false and destructiveHint: false, implying the tool is neither read-only nor destructive. This is contradictory. The description fails to disclose that only the list action is intended.

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 contains irrelevant details (create/delete) for a tool meant to list. The structure is not front-loaded for the list purpose; the vital info ('[Flattened action: list]') is at the end.

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 format. The description provides no context on how listing works, what filters apply (if any), or pagination. For a tool with nested objects and zero schema coverage, this is severely incomplete.

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

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

Schema description coverage is 0%, and the description provides no explanation of parameters for the list action. The create/delete parameter hints are irrelevant. The parameters uuid, account, and webhook remain unexplained for listing.

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 tool name suggests a listing action, but the description enumerates three actions (list, create, delete) without clearly indicating that only 'list' is valid for this tool. The '[Flattened action: list]' note at the end attempts to clarify, but the preceding instructions for create and delete cause 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 guidance is given on when to use this tool versus siblings like rdstation_webhooks_create or rdstation_webhooks_delete. Instead, the description includes create/delete instructions, misleading the agent into thinking it can perform those actions here.

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 idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that the tool accepts a conversation for reproduction, which implies a non-destructive logging or reporting action. It does not contradict annotations. However, it does not disclose any specific side effects or response behavior, leaving some behavioral details unaddressed.

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 to the point, with two sentences. The first sentence announces the purpose, and the second provides a critical usage instruction. Every word is necessary, and it is front-loaded with the main action. There is no fluff.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description is adequate but lacks details on return values or parameter format. For a feedback tool, it might be sufficient, but the description does not explain what happens after reporting (e.g., response, storage). It is minimally complete for a basic 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?

Schema description coverage is 0%, so the description must compensate for missing parameter details. It partially explains the 'conversation' parameter as needing recent messages for reproduction, but it does not describe 'context' or the expected format for 'message' (beyond a string). The 'conversation' is said to be a string with default '[]', but the description does not clarify its structure (e.g., JSON array). Thus, the description adds limited meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It is specific about the resource (bug/feature/feedback) and the verb (report/send). It distinguishes itself from sibling tools which are largely RDStation-specific operations (e.g., rdstation_contacts_get) or authentication, making it unique as a general feedback mechanism.

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

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

The description provides clear context for use: it handles bug reports, missing features, or feedback. It also gives a usage hint: 'Include the conversation array with recent messages for reproduction.' However, it does not explicitly state when not to use this tool or name alternative tools for other purposes, though the context (sibling tools are all different) implies distinct 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 adds value beyond annotations by specifying that it shows 'MCP platform and adapter versions'. Annotations already indicate read-only, idempotent, and non-destructive behavior, which is consistent.

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 unnecessary words. It is front-loaded and efficient.

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

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

For a tool with no parameters and no output schema, the description fully explains its purpose. No additional context is necessary.

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 no parameters, so the description does not need to add parameter information. The baseline of 4 applies as schema coverage is 100%.

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 displays current MCP platform and adapter versions. It distinguishes itself from sibling tools like 'authenticate' or 'connect' which have 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?

The tool is straightforward and self-explanatory; no explicit usage guidelines are needed. However, it could mention that it is safe to call anytime without side effects, though this is implied by its nature.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds specific return content (MCPs, status, counts), which is valuable 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?

Single, front-loaded sentence that conveys all essential information without any extraneous text.

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 no parameters, the description provides sufficient detail about the returned data (installed MCPs, connection status, catalog tool counts). Could mention the format (e.g., list/object) but adequate.

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; schema coverage is 100% (trivially). Description has no need to add parameter info, and baseline for zero-param tools is 4.

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?

Specific verb 'returns' and resource 'toolkit state'; clearly describes what is returned (installed MCPs, connection status, catalog tool counts). Distinguishes from sibling tools like show_version or authenticate.

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 vs alternatives. Context suggests it is general-purpose state introspection, but does not exclude other use cases or mention alternatives.

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