INPI

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

The description adds behavioral context beyond annotations by explaining the difference between permanent (config header) and session-only (token paste) authentication, and the non-expiring nature of the config approach. Annotations already cover idempotency and non-destructiveness, so this extra context is valuable.

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 three sentences long and generally front-loaded with the tool's context. Each sentence covers a distinct aspect (overview, best practice, alternative). While a bit verbose, every sentence earns its place without redundancy.

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

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

For a tool with one optional parameter and no output schema, the description covers the essential workflow: how to initiate login, the two methods, and the parameter behavior. It does not describe the exact response shape, but that is not critical for this authentication tool.

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

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

Schema coverage is 0%, so the description must explain parameters. It does so by stating 'call with { token: "<jwt>" }' and 'or with no args to get the link', clarifying that the token is optional and what it represents. This compensates well for the schema's lack of description.

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: it facilitates authentication by providing a browser login link and accepting an access token. It distinguishes itself from siblings through specific references to MCP.AI for IDE agents and the two usage modes (permanent config vs session-only).

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?

Explicit guidance is given on when to use the tool: 'Best: add it to this server's config as a header...' and 'Or paste it here for a session-only login'. It also explains when to call with no args to get the link, making the usage context clear.

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 and idempotentHint=true, establishing a safe, non-mutating profile. The description adds useful behavioral details about two states: all providers connected (authenticated:true, empty pending[]) and missing credentials (connect_url and per-install URLs), which goes beyond what annotations provide.

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 main purpose, and each sentence provides distinct, useful information (general return type and conditional states). 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 tool's simplicity, the description adequately covers the main return behaviors. There is no output schema, so the description must explain return values, which it does for the two key scenarios. However, it does not elaborate on possible intermediate states (e.g., partial connectivity), but this is a minor 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?

The tool has zero parameters, so schema coverage is effectively complete. With no parameters to document, the description does not need to add parameter-level semantics, and the baseline of 4 applies.

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 connection status and URLs, which is a specific verb+resource pair. It implicitly distinguishes from the sibling 'authenticate' by focusing on status rather than the authentication action itself, but it does not explicitly contrast with siblings.

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

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

The description implies that this tool is for checking connection status, but it does not explicitly state when to use it versus alternatives like 'authenticate'. There is no direct guidance on when to invoke this tool or when to avoid it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by stating the tool returns up to 100 processes and lists the returned fields (marca, número, classe, situação, titular), which goes beyond basic annotations without contradicting them.

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

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

The description is two sentences long, front-loaded with the core action and result limit. Every sentence earns its place: the first states what it searches and the second explains the value and return payload. No fluff or redundant details.

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

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

While the description gives a clear purpose and result limit, it omits critical details for proper use: pagination, filtering options (ncl, tipo, pedidos_vivos), and what 'pesquisa_textual' means. With 6 parameters and no output schema, the description is insufficient for an agent to correctly invoke the tool beyond the simplest case.

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

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

The schema has 6 parameters with 0% description coverage, and the description only loosely clarifies the required 'marca' parameter via 'pelo nome/termo'. The other parameters (ncl, tipo, pagina, pedidos_vivos, pesquisa_textual) are left unexplained, and the description does not compensate for the lack of schema descriptions.

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

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

The description clearly states the tool searches trademarks at INPI by name/term for prior art/conflict checking. This distinguishes it from sibling tools like inpi_marcas_processo (process lookup) and inpi_marcas_titular (owner search). The verb 'Busca' and resource 'marcas no INPI' make the purpose specific and 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 says 'Útil pra ver se um nome de marca já está depositado ou registrado', which clearly indicates the intended use case (trademark availability/conflict checking). However, it does not explicitly mention alternative tools or when not to use it, so it lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by enumerating the content provided (situação, depósito, concessão, vigência, titulares, classes Nice/Vienna, petições, publicações), going beyond the annotations without contradicting them.

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

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

A single, front-loaded sentence communicates the tool's purpose, input, and expected output content in a compact parenthetical list. There is no redundant or filler 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?

Despite the lack of an output schema, the description richly enumerates the types of data returned, making the tool's behavior clear. With one simple parameter and strong annotations, the description is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

The only parameter 'numero_processo' has no schema description (0% coverage). The description clarifies it is the process number, but provides no format, examples, or additional constraints, so it only minimally compensates for the schema 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 states a specific verb ('Detalhes completos') and a clear resource ('processo de registro de marca no INPI') queried by process number. It distinguishes itself from the sibling 'inpi_marcas_processo_resumido' by emphasizing 'completos' (complete details).

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 implies use when full trademark process details are needed, listing specific data areas. It does not explicitly mention alternatives or exclusion cases, but the 'completos' wording provides clear context that differentiates it from the summary sibling tool.

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

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

As anotações já declaram readOnlyHint, idempotentHint e destructiveHint=false, cobrindo o perfil de segurança. A descrição adiciona contexto comportamental relevante: a ferramenta é mais rápida e barata, e retorna um resumo com campos específicos. Não há contradição com as anotações.

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 descrição é concisa (duas frases) e direta, sem redundâncias. A primeira frase estabelece o propósito e os campos retornados; a segunda contextualiza o uso. Nenhuma palavra é desperdiçada.

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?

A ferramenta é simples (1 parâmetro, sem output schema), e a descrição cobre bem a finalidade, a condição de uso e o conteúdo do retorno. Poderia incluir um exemplo de resposta ou mencionar possíveis erros, mas, dado o escopo, é suficiente.

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?

O schema tem 0% de cobertura de descrição para o parâmetro, mas a descrição compensa ao indicar que a operação é 'pelo número do processo'. Isso esclarece o significado de 'numero_processo' além do que o schema fornece. Faltam detalhes de formato ou validação, mas é um único parâmetro autoexplicativo.

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?

A descrição afirma explicitamente que a ferramenta fornece um resumo de um processo de registro de marca no INPI por número do processo, listando os campos (marca, titular, classe, situação). Ela também se distingue do sibling 'inpi_marcas_processo' ao se apresentar como 'versão enxuta do detalhe completo'.

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?

A descrição dá uma orientação clara de quando usar: 'quando você só precisa do status', indicando que é uma alternativa mais rápida e barata. Embora não nomeie explicitamente o sibling 'inpi_marcas_processo', a referência ao 'detalhe completo' sugere a alternativa. Falta uma exclusão explícita como 'não use se precisar de todos os detalhes'.

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, covering safety. The description adds domain context about trademarks by holder but does not disclose additional behaviors such as whether both CPF and CNPJ can be provided or what happens for invalid inputs. This is acceptable given the strong annotation coverage.

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 that directly states the tool's subject matter. It is front-loaded with the key resource and scope, and contains no filler or 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 tool has only two string parameters and no output schema, so complexity is low. The description is sufficient to understand the core purpose, but it lacks usage guidance and parameter interaction details. It is adequate but leaves clear gaps regarding when to choose this tool over siblings and how to combine CPF/CNPJ.

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

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

Schema coverage is 0%, so the description must compensate. The phrase 'por titular (CPF ou CNPJ)' correctly associates both parameters with the holder identifier, which the schema alone does not convey. However, it omits details like whether both parameters can be used together, format expectations, or if at least one is required. It provides basic meaning but not full 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 uses a specific noun phrase 'Marcas registradas no INPI por titular' indicating the resource (trademarks at INPI) and scope (by holder). It clearly distinguishes from siblings like 'inpi_marcas_busca' (search) and 'inpi_marcas_processo' (process) by focusing on the holder dimension. A verb like 'lists' would make it 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not state 'use this when you have a CPF/CNPJ' or mention that general searches should use 'inpi_marcas_busca'. Given multiple related siblings, this is a notable gap.

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, covering the safety profile. The description adds minimal behavioral context beyond the holder filtering, which is already reflected in the params. No additional behaviors such as return format, pagination, or limitations are disclosed.

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 in Portuguese that conveys the essential purpose without any extraneous text. 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?

The tool is simple with two optional parameters, and annotations cover safety. However, there is no output schema, so the description should explain what is returned (e.g., list of patents with details), but it does not. This is a notable gap for an agent needing to use the tool effectively.

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

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

Schema coverage is 0%, so the description must compensate. It provides meaning by indicating that CPF and CNPJ are holder identifiers and that either can be used (as implied by 'ou'). However, it does not clarify whether both can be provided together, their formats, or any constraints, so it only partially compensates.

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

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

The description identifies the resource as patents registered at INPI and the scope as filtering by holder (CPF or CNPJ), which clearly distinguishes it from the sibling trademark tools. However, it lacks an explicit verb like 'list' or 'search', making the action slightly implied rather than explicit.

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

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

The description implies the tool is used to retrieve patents by holder, but does not explicitly state when to use it versus alternatives. It does not mention exclusions or refer to sibling tools, leaving the usage context to inference.

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 the annotations (readOnlyHint false, openWorldHint true, etc.), the description discloses critical behavioral traits: invoke runs tools even when not installed without bloating the toolkit, returns connect links for missing credentials, returns checkout/top-up links for empty wallet, and that install/uninstall/subscribe/cancel plus the one-off install behind invoke require workspace owner/admin. No annotation contradiction is present.

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

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

The description is long but every sentence earns its place given the tool's complexity. It is front-loaded with a clear definition, then follows a logical structure: core flow, key invoke behavior, action-specific guidance, and permission requirements. There is minimal redundancy (e.g., 'without bloating the tool list' slightly repeats 'without adding the MCP to the toolkit'), but overall it is appropriately sized for a meta-tool with 15 parameters.

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

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

The description covers the main behaviors, special cases (connect/checkout links), and permission requirements comprehensively given the absence of an output schema. However, it omits the 'resume' action entirely (present in the enum but not mentioned) and does not describe return values or error handling. Minor gaps remain, but the description is highly complete for the tool's core use cases.

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 key parameters like action, query, mcp_id, tool_id, and arguments through the core flow and examples. However, it leaves many other parameters unexplained (e.g., limit, message, conversation, tier_slug, cancel_reason, immediate). Despite this, it adds significant meaning for the primary actions, meriting a score above the baseline for low-coverage schemas.

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 mcp.ai marketplace, serving as both a catalog and a way to run MCPs/tools. It distinguishes itself from sibling tools (authenticate, connect, INPI-specific tools) by positioning itself as the in-platform catalog and execution layer. The core flow (search → describe → invoke) is explicitly outlined, leaving no ambiguity about the tool's purpose.

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

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

The description provides explicit guidance on when to use each action: prefer invoke for one-off use, use install for permanent addition, list_tools for currently callable tools, subscribe/cancel for billing, etc. It also explains the decision flow (search by intent → describe to pick tool_id → invoke) and notes that writes require workspace owner/admin. This clearly differentiates when to use this tool versus 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=false and destructiveHint=false, so the description doesn't need to restate those. It adds the behavioral note about including the conversation array for reproduction, which is useful. However, it doesn't disclose what happens after reporting (e.g., whether a ticket is created, if it's logged remotely, or if duplicate submissions are ignored). This is a minor gap given idempotentHint=true.

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 with front-loaded purpose: the first sentence states exactly what the tool does, and the second sentence provides a single key usage tip. Every word earns its place, with no redundancy or 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?

For a simple 3-parameter tool with no output schema and no nested objects, the description is largely sufficient. It covers the purpose and the most important parameter (conversation). The only missing piece is clarifying the 'context' parameter, but overall it's complete enough for an agent to use correctly.

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

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

The schema itself provides no descriptions (0% coverage), so the description must compensate. It explains the 'conversation' parameter by saying to include recent messages for reproduction, and implies the 'message' parameter is the bug/feedback text. However, it does not explain the 'context' parameter, which remains ambiguous. This partial coverage justifies a middle score.

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 uses a specific verb ('report') and identifies the resource (bug/feature/feedback), making it easily distinguishable from sibling tools which are all external services like trademark searches 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?

The description gives clear context on when to use the tool: when a user wants to report a bug, missing feature, or send feedback. It also provides a concrete usage tip: 'Include the conversation array with recent messages for reproduction.' No explicit exclusions or alternatives are necessary since the sibling tools are clearly unrelated domains.

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, covering the safety profile. The description adds the specific scope of 'MCP platform and adapter versions', but does not disclose additional behavioral traits such as output format or error potential. It neither contradicts annotations nor enriches them significantly.

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, direct sentence that immediately conveys the tool's purpose without any redundancy or filler. It is optimally concise for its simplicity.

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, read-only information tool, this description captures the essential purpose effectively. However, the lack of an output schema and the presence of a similarly-sibling 'toolkit_info' mean the description could be more complete by clarifying what exact version data is returned and how this differs from other informational tools.

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

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

The tool has no parameters, making the schema trivially complete. The description correctly omits parameter details, and the baseline of 4 applies for zero-parameter tools. No additional parameter context is 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 clearly states the tool's function with a specific verb and resource: 'Show the current MCP platform and adapter versions.' It is unambiguous and informative, though it does not explicitly distinguish this tool from the sibling 'toolkit_info', which could potentially also display version details.

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 usage guidance is provided. The description simply states what the tool does without explaining when to use it versus alternatives like 'toolkit_info'. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage independently.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context about what the tool reports (installed MCPs, connection status, counts), which goes beyond the annotations. No side-effect details are needed for a read-only info 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, front-loaded sentence that delivers the essential information without any fluff. It lists the exact components of the returned state, earning a perfect score for conciseness.

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

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

Given the tool is simple (no parameters, no output schema), the description fully explains what the tool returns and its purpose. It provides sufficient contextual detail for an agent to invoke the tool correctly and understand the response without 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?

The tool has zero parameters, so the schema already provides complete coverage (100%). Per the rubric, a baseline of 4 applies when no parameters exist. The description appropriately focuses on the return value rather than parameters, which adds no semantic burden.

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 the current toolkit state, specifically listing installed MCPs, connection status, and catalog tool counts. This is a specific verb+resource combination that distinguishes it from sibling tools like authenticate or search tools.

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

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

The description makes the tool's usage context clear: whenever an agent needs an overview of the toolkit's MCPs and their status. It doesn't explicitly exclude alternatives, but no sibling tool serves this same purpose. The context is self-evident from the purpose.

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