ANTT: Veículo

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

Beyond the readOnly annotation, it clarifies data is non-confidential, mentions LGPD compliance, and payment per query. No contradiction with annotations; adds useful operational details.

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 verbose and repetitive (e.g., 'fonte oficial' and 'LGPD' mentioned multiple times). Could be tightened without losing meaning.

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 cost and data sensitivity, but omits what the tool returns, which parameters are required, and any usage constraints. Since output schema is absent, more context 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?

No explanation of any of the four parameters (cpf, cnpj, placa, rntrc). Schema has no descriptions, and the description does not clarify their roles or requirements, making it hard to know what to supply.

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?

Clearly states it is a vehicle consultation from official sources (ANTT), distinguishing it from sibling tools like authentication or reporting. The verb 'consultar' and resource 'Veículo' are specific.

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?

Implies usage for querying vehicle information and mentions prepaid credit cost, but does not explicitly contrast with alternatives (though none exist). It gives sufficient context for when to invoke.

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 indicate idempotentHint=true, and description aligns with that: no contradictory claims. Adds context that config-based auth is non-expiring vs session-based, and that called with no args returns a link. Doesn't mention side effects but enough info.

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, front-loaded with audience and core action, then branches into two methods. Every clause adds value; 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?

Tool is simple (one optional param, no output schema). Description covers all necessary aspects: what it does, two ways to use, and what happens with no args. Complete for its 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?

Schema has only one optional parameter 'token' with 0% coverage. Description explains the token is a JWT and used when pasted by user. Though it doesn't detail format beyond JWT, it gives functional context. Baseline for low coverage would be lower, but description clarifies 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 explicitly states the tool authenticates the user by obtaining an access token via browser login and provides two methods: adding to config as a header or pasting the token. It clearly distinguishes from siblings involving vehicle consultation, marketplace, 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?

Provides explicit instructions on two usage scenarios: permanent config setup vs session-only login, and specifies exact call patterns (with or without token argument). Mentions IDE agents like Cursor, making 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?

Beyond the readOnlyHint annotation, the description adds concrete behavior details: it returns an authenticated flag, a pending list, and per-install URLs depending on credential status. This gives the agent a clear expectation of outputs and conditions, going beyond the basic annotation.

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, concise and well-structured. It logically presents the normal case (authenticated) and the missing-credentials case, without any 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?

Given the lack of an output schema, the description adequately covers the return values (authenticated, pending, connect_url) and the conditions under which they appear. It provides sufficient context for an agent to understand what to expect.

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, so the baseline score of 4 applies. The description does not need to explain parameter semantics, and it correctly omits any mention since there are none.

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 returns connection status and URLs. It distinguishes itself from sibling tools like 'authenticate' by focusing on status checking rather than authentication actions.

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

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

The description implies when to use it (e.g., to see if authentication is needed, as it returns connect_url when credentials are missing), but it does not explicitly contrast with alternatives like 'authenticate'. The guidance is somewhat implicit rather than directly stated.

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?

It discloses important non-obvious behavior: invoke runs a tool one-off even when the MCP is not installed, returned links matter for connect/checkout flows, and writes require workspace owner/admin. The annotations are generic (readOnlyHint=false, destructiveHint=false), so the description carries the burden and does so thoroughly.

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 earns its length given the tool's 14 actions and 23 parameters. It front-loads the core purpose and core flow, then layers in permissions, billing behavior, and the prompt library. A bulleted or sectioned structure would improve scannability, but there is little wasted 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?

For a highly complex tool with no output schema, the description is unusually complete: it covers the search/describe/invoke lifecycle, one-off execution semantics, auth/payment link flows, permission requirements, and the separate prompt-library feature. It does not document every parameter or return shape, but the agent gets enough context to select and invoke the correct 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?

The prose adds meaning to key parameters like action, mcp_id, tool_id, prompt_slug, and prompt_vars, and it explains the overall action flow. However, schema description coverage is 0% across 23 parameters, and many parameters such as limit, immediate, tier_slug, message, conversation, cancel_reason, and request_name remain unexplained either in the schema or the 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 opens with 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them,' immediately identifying the tool's function. It then lays out the core search/describe/invoke flow and names the sub-actions, clearly distinguishing this dispatcher-style tool from siblings like `toolkit_info` and `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?

The description gives explicit usage rules: 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT in the active toolkit.' It also maps each sub-action to its purpose: list_tools lists callable tools, subscribe/cancel handle billing, report_bug sends feedback, request_mcp asks for a new MCP. This is strong when-to-use/when-not-to-use 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 indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description only adds a usage hint about the conversation array but does not disclose any behavioral traits beyond what annotations provide, such as side effects, error conditions, or required permissions. No contradiction, but also no added 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 a single concise sentence, front-loaded with the primary purpose. It wastes no words, though it could add more detail without becoming verbose. It earns a 4 for being succinct but potentially under-informative.

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 (no nested objects, no output schema, 3 params with defaults). The description covers the main purpose and hints at the conversation usage, but it doesn't explain what 'message' and 'context' are or how the tool behaves beyond reporting. Given the low complexity, this is adequate but not fully complete for an agent to know how to fill parameters 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 description mentions 'Include the conversation array with recent messages for reproduction,' which explains the 'conversation' parameter. However, it does not explain the 'message' parameter (the required one) or the 'context' parameter. With schema coverage at 0%, the description should compensate for all parameters but only partially covers one, leaving others without semantic clarity.

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 action: 'Report a bug, missing feature, or send feedback.' It uses a specific verb (report) with a clear resource (bug/feature/feedback), distinguishing it from sibling tools like 'authenticate' or 'marketplace' 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 description provides a specific instruction to 'Include the conversation array with recent messages for reproduction,' which is a clear usage guideline. It does not explicitly state when not to use the tool, but among siblings, none overlap with bug reporting, so usage context is clear without needing 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 and idempotentHint true, so the description doesn't need to state safety. It adds no extra behavioral context (e.g., network calls, auth needs, rate limits), but it doesn't contradict annotations either. Given the tool's trivial nature, a neutral 3 is appropriate.

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 sentence that directly states the tool's function with no redundancy or filler. 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?

For a simple version-query tool with no parameters, no output schema, and read-only annotations, the description fully covers what the tool does. It states it returns platform and adapter versions, which is sufficient context for an agent to select and invoke it.

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 baseline is 4. There is no parameter information to add beyond the schema, and the description correctly implies no 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 uses a specific verb 'show' and names the resource 'MCP platform and adapter versions,' making the tool's purpose unambiguous. It distinguishes from siblings by being a dedicated version query, even though no sibling is similar.

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

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

The description implies usage for checking current versions, but provides no explicit guidance on when to use it versus alternatives or when not to use it. There is no mention of context like diagnostic or compatibility checks, so it relies on the agent to infer.

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, idempotentHint, and destructiveHint, covering safety. The description adds behavioral detail by enumerating the exact contents of the returned state (installed MCPs, connection status, accounts, catalog tool counts), which is valuable beyond the annotations. No contradictions.

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

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

The description is a single sentence that is front-loaded with the primary purpose ('Returns the current toolkit state') and lists specifics efficiently. 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 is simple with no parameters and no output schema. The description fully explains what the tool returns, covering all essential aspects for an info-gathering tool. It is complete for the agent's needs.

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?

There are 0 parameters, so the baseline is 4. The description correctly indicates that no input is required and focuses entirely on output, which is sufficient given the schema has no properties.

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 clearly specifies the resource 'toolkit state', listing concrete details (installed MCPs, connection status, accounts, catalog tool counts). It distinguishes from siblings like show_version (version info) and marketplace (store) by focusing on overall toolkit state.

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 when to use this tool (to inspect toolkit state) but does not explicitly state when not to use it or name alternatives. However, the context is clear enough for an agent to select it for informational queries, so it meets the 'clear context, no exclusions' level.

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