DETRAN: Restrições (Unificada)

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

The description discloses that passing a token results in a session-only login, while adding to config provides a permanent, non-expiring connection. This goes beyond the annotations (idempotent, non-destructive) by explaining the persistence of the authentication state.

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

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

The description is verbose and slightly disorganized, starting with a vague phrase 'MCP.AI for IDE agents' before clarifying the purpose. Multiple alternatives and conditions are crammed into a single run-on sentence, making it harder to parse than necessary.

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 (no output schema), the description covers the main use cases: obtaining a link and authenticating with a token. It mentions both permanent and session-only options, which is sufficient context for a user to decide how to proceed.

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 one parameter 'token' with zero description, but the tool description explains that it expects a JWT token obtained from the login link. It also clarifies that the parameter is optional by stating you can call with no args to get the link. This sufficiently compensates for the missing schema 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 indicates this tool is for authentication to the MCP server, mentioning login and token usage. It distinguishes from siblings like 'connect' and 'report_bug' by focusing on credential handling.

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 usage instructions: either call with no args to receive a login link, or call with a token for session-only login. It implies when to use this tool (when authentication is needed) but does not explicitly compare to alternatives since none exist for authentication.

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 establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by explaining the two states (connected vs. missing credentials) and what URLs are returned, which goes beyond the annotation metadata.

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 compact sentences, front-loaded with the core purpose and followed by useful conditional details. Every sentence contributes meaningful information with 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?

For a simple zero-parameter read-only status tool, the description fully explains the return values and the two relevant connection states. Even without an output schema, the agent has enough behavioral detail to invoke the tool and interpret its response.

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 100% and there is no parameter ambiguity. The description adds no parameter detail, but none is needed; a baseline of 4 is appropriate due to the absence of 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 states a specific action ('Returns connection status and URLs') and names concrete outputs (authenticated, pending[], connect_url). It clearly distinguishes this from sibling tools like authenticate by focusing on status/URL reporting rather than performing authentication.

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

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

The description gives clear contextual scenarios: when all providers are connected vs. when credentials are missing. It does not explicitly name alternatives or say when not to use it, but the usage context is well implied by the conditional behavior described.

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

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

Beyond annotations (readOnly, idempotent), the description discloses that it is a paid service with prepaid credits, does not require platform credentials, and that the client is responsible under LGPD, adding meaningful behavioral context.

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

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

The description is concise (three sentences) and gets to the point, though it includes some non-essential phrases like 'Hospedado pela plataforma' that add little value. Overall, it is appropriately brief.

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 omits essential context: no parameter meanings, no output description, and no guidance on how to obtain or use the required credentials. Given the tool's complexity, the description is wholly 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?

The description provides no explanation for any of the 11 parameters (e.g., uf, placa, renavam, login credentials). With 0% schema coverage, it fails to compensate, leaving users unsure what inputs are 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 performs a query ('consulta') on official sources for DETRAN restrictions ('Restrições'), distinguishing it from sibling tools like authenticate or connect.

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

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

The description implies usage for querying official Brazilian data but does not explicitly state when to use this tool over alternatives or provide scenarios. It lacks explicit '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?

Goes well beyond the generic annotations by revealing concrete behaviors: invoke works even when the MCP is not installed, returns connect/checkout links, writes require workspace owner/admin, and install makes MCP permanent in the toolkit. This adds context about side effects and permission requirements.

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

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

The description is a single dense paragraph with many run-on sentences. Despite covering complex functionality, it lacks bullet points or clear sections, making it harder to parse. It is long but every sentence adds information, so it earns a middle score.

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 (23 params, no output schema), the description covers the core flow, permissions, auth/checkout behaviors, and the prompt library subsystem well. It doesn't detail every action or return format, but provides enough for correct tool selection and 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?

With 0% schema description coverage, the description compensates by explaining the action enum values (search, describe, invoke, install, list_tools, etc.) and core parameters like mcp_id/tool_id/arguments via the flow. However, several parameters (tier_slug, request_name, cancel_reason, prompt_category, etc.) remain undocumented, preventing a perfect 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 opens with 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' which clearly identifies the resource and its dual role. It then enumerates the core action flow (search → describe → invoke), distinguishing this tool from siblings like authenticate or report_bug.

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 when-to-use guidance: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', and maps sibling-like functions: 'list_tools lists what is callable right now', 'subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits.'

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 (idempotentHint=true, readOnlyHint=false, destructiveHint=false) are not contradicted by the description. The description adds context by mentioning that conversation messages are used for reproduction. It does not reveal other behavioral traits like rate limits or what happens after submission, but given the annotations, this is acceptable.

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 extremely concise: two sentences with no filler. It front-loads the purpose and then gives a specific usage instruction. Every word earns its place.

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

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

The tool is simple with no output schema; the description adequately covers the primary use case. However, it could elaborate on what happens after reporting or the expected format of 'conversation' (though that's a param detail). For its simplicity, it is mostly complete but leaves a few 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 mentions the 'conversation' parameter, while 'message' and 'context' are left undescribed. Since message is required, its absence weakens semantic clarity. The description fails to explain the format or purpose of context, missing a chance to add value 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?

Description clearly states the tool reports bugs, missing features, or feedback. The verb 'report' and resources are specific and distinguish it from unrelated siblings like authenticate or show_version. No ambiguity.

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

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

The description implies usage for bug/feedback reporting and gives an instruction to include the conversation array for reproduction. However, it does not explicitly state when not to use this tool or mention alternatives, though siblings are unrelated. Usage context is implicit rather than explicit.

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 useful context about the scope ('current MCP platform and adapter versions') but does not disclose additional behavioral traits such as return format or potential errors. This aligns with the get_calls calibration example.

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 states exactly what the tool does with no filler or redundancy. Every word earns its place.

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

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

Given the tool's simplicity, zero parameters, and strong annotations, the description is complete. It explains the return subject ('current MCP platform and adapter versions') even though no output schema exists, making it sufficient 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 tool has zero parameters, and schema description coverage is 100%, so there are no parameter semantics to clarify. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description adds no unnecessary parameter information.

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

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

The description uses a specific verb ('Show') and identifies the exact resource ('current MCP platform and adapter versions'). This clearly distinguishes it from sibling tools like authenticate or report_bug, which serve different purposes.

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

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

The description implies when to use the tool—when version information is needed—but provides no explicit guidance on when not to use it or which alternative to choose. For a simple zero-parameter version tool, this is adequate but not explicit.

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 goes beyond the annotations by detailing the content of the returned state, including specific data points. It confirms that the tool is read-only and idempotent, consistent with annotations, but adds clarity about what the state includes. No additional side effects or caveats are mentioned, but the description is transparent about the data returned.

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

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

The description is a single, concise sentence that lists the key information returned. It is well-structured and avoids unnecessary details, making it easy to understand.

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 a clear picture of what the tool returns without an output schema. It mentions the main categories of information, which is sufficient for a user to know what to expect. It does not detail the format, but for a simple state query, this is acceptable.

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, and the description does not need to explain any input. The schema is empty, so coverage is trivially 100%, and the description does not add anything about parameters because there are none. This is appropriate.

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

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

The description clearly states that the tool returns current toolkit state and enumerates the specific aspects: installed MCPs, connection status, accounts, and catalog tool counts. This makes the purpose unambiguous and distinguishes it from sibling tools that perform actions like authentication or connection.

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

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

The description does not explicitly mention when to use this tool versus alternatives. It simply describes what it returns, without indicating scenarios such as before connecting or when troubleshooting state. Thus, usage guidance is not provided.

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