DER BA: Nada Consta

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

Adds behavioral context beyond annotations by explaining the browser login flow, token usage, and the distinction between permanent and session logins. Does not contradict annotations and leverages idempotentHint appropriately.

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?

Three sentences, each dense with actionable information. Front-loaded purpose, then usage modes. No redundancy or filler.

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 both invocation paths, expected input, and implicit return (link). Lacks error handling details, but with no output schema, the description provides sufficient guidance for a simple auth tool.

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

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

Despite 0% schema description coverage, the description fully explains the single 'token' parameter: it's an optional JWT for session login, and absence yields a link. This exceeds schema value and guides correct invocation.

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 the tool's purpose: authentication via browser login and token handling. It specifies the resource (access token) and process, distinguishing from unrelated siblings like 'report_bug' or 'show_version'.

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?

Provides explicit usage instructions for two modes: permanent config header (outside tool) and session login via token or no-arg link retrieval. Lacks explicit 'when not to use' but context is clear given the focused domain.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context by detailing the two output scenarios (authenticated vs. missing credentials) and that it returns connect URLs. No contradictions, and it adds value beyond the annotations.

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

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

Two concise sentences, front-loaded with the core purpose. Every word earns its place—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 no parameters and no output schema, the description fully covers the tool's behavior: it states what it returns and the distinct cases (connected vs. missing credentials). It is complete for a simple read-only 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?

The tool has zero parameters ascending; the schema is empty (100% coverage). Per guidelines, baseline for 0 params is 4, and the description effectively explains the tool's behavior and output without needing to describe parameters.

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

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

The description clearly states the tool's purpose: 'Returns connection status and URLs.' It also distinguishes the two outcome scenarios (all connected vs. missing credentials), making it specific and distinct from siblings like 'authenticate' and '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 clearly implies this is a status-check tool, and the presence of 'authenticate' as a sibling suggests alternative usage. However, it doesn't explicitly state when to use this vs. other tools or any exclusions. It gives clear context about what it reports, but no direct 'use this when' guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond annotations: no platform credentials required, prepaid credit per query, data is not confidential, and client is data controller under LGPD. This helps the agent understand cost and legal responsibilities.

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, packed with essential information about source, credentials, payment, and legal compliance. It is not overly verbose and front-loads the primary purpose. Slightly dense but 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 description covers key contextual aspects such as payment, authentication, and data handling, but omits parameter guidance and output format. Given the simple query tool nature and strong annotations, it is mostly complete, yet the parameter gap prevents it from being fully self-sufficient.

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 and the description does not mention any of the three parameters (ait, placa, renavam) or their semantics. While the parameter names are somewhat self-explanatory, the tool description fails to compensate for the schema's lack of explanations, leaving the agent without guidance on required formats or optional usage.

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: 'DER BA: Nada Consta, consulta em fonte oficial' and explains that it queries official Brazilian sources. It uses a specific verb ('consultar') and resource ('DER BA Nada Consta'), distinguishing it from generic sibling tools like authenticate or show_version.

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 operational context such as 'sem credenciais da plataforma' and 'pague por consulta com crédito pré-pago', but does not explicitly state when to use this tool over alternatives or when not to use it. Since siblings are platform-wide tools, the usage context is implied but not explicitly articulated.

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?

No annotation contradiction: readOnlyHint=false aligns with the documented writes. The description adds rich behavior beyond annotations: 'invoke works even when the MCP is NOT installed,' the credential flow ('invoke returns a connect link'), the payment flow ('returns a checkout/top-up link... the user opens it, then you retry'), and permission requirements ('Writes... require workspace owner/admin').

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?

Every sentence earns its place and the content is genuinely dense with useful information, but it is delivered as one giant run-on paragraph with no visual organization — semicolons and dashes chain together marketplace flows, prompt library, auth, and permissions. The two distinct domains (marketplace + prompt library) are never separated structurally, making it hard to parse despite being front-loaded with the core purpose.

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

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

For an extremely complex tool (23 params, 14 actions, a prompt library sub-domain, no output schema, 0% schema coverage), the description is remarkably complete: it covers the search→describe→invoke flow, one-off vs permanent semantics, auth/payment retry logic, write permissions, installed flags, and the full prompt library lifecycle. Remaining gaps are minor — some params (limit, query, immediate, cancel flow) lack textual explanation, but given the scale this is an excellent effort.

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 and 23 parameters, the description carries the full burden but only covers the core params: the action enum flow, tool_id/arguments ('every tool with its id + params'), and tier_slug (pricing). Many params remain unexplained (limit, query, immediate, cancel_reason/cancel_comment, request_name/request_details, report_context, prompt_targets, conversation, prompt_body). The description adds meaning for the central flow but cannot compensate for all 0% coverage 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 immediately states 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' giving a specific verb+resource with clear scope. It distinguishes from siblings by naming report_bug for feedback and request_mcp for building new MCPs, and explicitly separates the marketplace flow from the prompt library sub-domain.

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 when-to-use guidance is abundant: 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT,' 'request_mcp asks us to build a NEW MCP when nothing fits,' and 'Search/describe flag installed_in_toolkit vs installed_in_workspace.' It also names alternatives for the prompt library (search_prompts vs get_prompt vs publish_prompt).

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 provide idempotentHint=true and destructiveHint=false, and the description adds the instruction to include conversation history for reproduction, which is useful. It doesn't disclose what happens after submission, but given the simple nature of the tool, this is acceptable and not contradictory.

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 clearly states the purpose and the key usage detail. Every word earns its place with no redundant or vague phrasing.

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 3-param tool with no output schema, the description covers the core action and the conversation parameter, but it omits explanations for message and context, and doesn't clarify the post-report behavior. It is adequate but leaves notable gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It only explicitly mentions the 'conversation' parameter, leaving the required 'message' and the optional 'context' undocumented. This is a significant gap for agents to know what to fill in.

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 the specific verb 'Report' with explicit targets (bug, missing feature, feedback), which immediately distinguishes it from sibling tools like authenticate or show_version. The scope is clear 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?

It explicitly lists the three relevant use cases (bug, missing feature, feedback) and instructs to include the conversation array for reproduction, giving the agent strong contextual guidance. However, it does not explicitly mention alternatives or exclusions, so it stops short of a 5.

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, so the description's statement 'Show the current versions' is consistent but adds no extra behavioral context beyond what's in the annotations. No contradiction, but no additional clarity either.

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 fully conveys the tool's function. Every word earns its place, and there is no unnecessary verbosity. Perfectly concise for the tool's 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?

Given the tool's low complexity, zero parameters, and rich annotations (readOnly, idempotent, non-destructive), the description fully covers what is needed. No output schema or nested objects create additional burden. The description is complete for an agent to use this 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 tool has zero parameters, and the schema coverage is 100% (trivially). With no parameters to describe, the baseline of 4 is appropriate; the description doesn't need to add parameter semantics and doesn't lose points.

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: 'Show the current MCP platform and adapter versions.' It uses a specific verb ('Show') and resource ('MCP platform and adapter versions'), and it's distinct 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 usage context is implied; an agent would understand when to use this tool (to check versions), but there is no explicit when-to-use or alternatives discussed. Given the tool's simplicity, this is adequate but not outstanding.

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 provide readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds value by specifying the concrete content of the returned state—installed MCPs, connection status, accounts, and catalog tool counts—which goes beyond the generic annotation signals.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and then lists the key output components. Every phrase contributes meaning, with no unnecessary repetition or filler.

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

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

Given the tool has no parameters, no output schema, and a simple informational purpose, the description fully covers what an agent needs to select and invoke it correctly. It explains both the scope ('current toolkit state') and the specific data points returned.

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 there is no schema burden for the description to carry. The description correctly focuses on the return value, which is all that is needed for a no-argument introspection 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 uses a specific verb ('Returns') and resource ('current toolkit state'), and enumerates exactly what is included: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly distinguishes it from sibling tools like show_version or marketplace, which address different concerns.

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 clear the tool is for inspecting toolkit state, so when an agent needs connection status or account bindings, this is the right choice. It does not explicitly state when not to use it or name alternatives, but the context is strong enough for selection.

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