ECRVSP ATPV (Intenção de Venda): Consultar

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

Annotations indicate idempotent and non-destructive. The description adds context about token type (JWT), permanent vs session-based behavior, and the fact that no args yields a link. It does not contradict annotations; it supplements 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 compact and front-loaded with audience and purpose. Each sentence contributes meaning, though the informal 'Best:' structure slightly reduces formality. Still, it is well-organized and not padded.

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

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

Given the simple tool (1 param, no output schema), the description covers usage thoroughly, including return behavior ('get the link') and session persistence. It does not mention error cases but that is not critical for this 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?

With 0% schema coverage, the description fully explains the 'token' parameter: it's optional, expects a JWT, and the alternative of calling with no args. This is more than enough for a single parameter.

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

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

The description clearly states it is for MCP.AI authentication for IDE agents, with specific verb 'log in' and reference to browser and access token. It distinguishes from siblings like 'connect' by focusing on authentication rather than general connectivity.

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 provides two usage modes: permanent via config header and session-only via token or no-args to get link. This gives clear when-to-use guidance and an explicit recommended approach ('Best'), which is more than sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context about the return values in different states (authenticated:true vs. connect_url), which is useful. However, it does not disclose any additional side effects or limitations beyond what annotations provide, so a 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 two sentences, front-loaded with the main purpose, and every sentence adds value. It is concise and well-structured, with 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 has no parameters, no output schema, and annotations cover the safety profile, the description is complete enough. It explains the two possible outcomes and what the agent can expect. It could potentially mention that the tool is read-only and idempotent, but annotations already cover that, so the description is 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 tool has zero parameters, and the schema description coverage is 100% (vacuously). The description does not need to explain parameters, and it provides meaningful information about the output states. Since there are no parameters, the baseline is 4, and the description adds value by explaining the return behavior.

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

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

The description clearly states the tool returns connection status and URLs, and distinguishes between states (all connected vs. missing credentials). It is specific about the resource (connection status) and provides details on what is returned, though it does not explicitly differentiate from sibling tools like authenticate or toolkit_info.

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

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

The description implies when to use it (to check connection status and get URLs when credentials are missing) but does not explicitly state when not to use it or mention alternatives. It provides context on the two possible outcomes, which helps the agent decide, but lacks explicit guidance on 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 declare the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: no platform credentials are needed, it is paid via prepaid credit, the data is not confidential, and the client is the data controller under LGPD. This goes 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?

The description is a single paragraph with a clear opening line defining the resource and action, followed by compact operational and legal notes. It is not overly verbose, though it could be tightened by removing redundancy between 'Consultar' and 'consulta'.

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 six required parameters and no output schema, the description should explain parameter meanings and expected results. It provides useful operational context (payment, credentials, legal) but omits any detail on parameter semantics or return values, making it incomplete for an agent to correctly invoke the 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 description coverage is 0%, and the description does not explain the six required parameters (a3, a3_pin, login_cpf, login_senha, placa, renavam). The mention of 'sem credenciais da plataforma' hints that the login fields are external credentials, but the meaning of 'a3' and 'a3_pin' remains unclear, leaving the agent without sufficient guidance.

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 identifies the tool as a query ('Consultar') for ECRVSP ATPV (sales intention) against official Brazilian sources, which distinguishes it from generic sibling tools like 'authenticate' or 'connect'. The acronym expansion and scope ('consulta em fonte oficial') make the purpose unambiguous.

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

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

The description implies usage context by explaining the tool is hosted on the platform, requires prepaid credit, and involves LGPD compliance, but it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria. Since no sibling tools perform a similar function, the implied guidance is sufficient for a minimum viable score.

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

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

The description adds substantial behavioral detail beyond the sparse annotations: invoke works one-off even when the MCP is not installed, credential gaps return a connect link, unpaid/empty-wallet scenarios return a checkout link, and writes require workspace owner/admin. It also notes that prompt share links open without login.

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 dense and uses helpful signposting like 'Core flow', 'KEY', and 'Use install only'. It is a single long paragraph rather than structured bullets, but the length is justified by the 14 sub-actions and multiple workflows covered.

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 hub tool with 23 parameters and no output schema, the description covers a remarkable amount: search-to-invoke flows, auth/payment behavior, permanent vs one-off use, permission requirements, and the prompt-library subsystem. Minor gaps remain around actions like resume, tier_slug, and the specific semantics of cancel_* fields, but overall it is sufficient for an agent to navigate the 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?

With 23 parameters and 0% schema description coverage, the description must compensate heavily. It explains the core action values, tool_id selection through describe, and some prompt-related fields like prompt_vars and prompt_slug. However, many params such as limit, immediate, tier_slug, cancel_reason, cancel_comment, prompt_body, and conversation remain only implied by name rather than explained.

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 identifies the tool as the official mcp.ai marketplace and catalog, explicitly covering both discovery and execution: 'catalog of every MCP/tool, AND the way to run them'. It defines a concrete core flow with search, describe, and invoke, and covers secondary actions like prompts, clearly distinguishing it from sibling 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 gives strong usage guidance within the tool: 'prefer invoke for a single/occasional use', 'Use install only to make an MCP PERMANENT', and 'request_mcp asks us to build a NEW MCP when nothing fits'. It lacks explicit comparison to sibling tools like authenticate or connect, so it doesn't fully address external 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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the write and non-destructive nature is covered. The description adds the requirement to include a conversation array for reproduction, which is useful context, but doesn't specify what happens after reporting or whether the action is truly idempotent.

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 short sentences that front-load the purpose and then give a specific instruction. Every word is meaningful, with no repetition of the title or schema.

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 3 parameters and no output schema. The description covers the core function and one parameter's purpose, but missing context on parameter 'context' and the behavior after submission. It is adequate but has clear 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 mentions the conversation array and its purpose, but does not explain 'context' or provide details on how 'message' should be formatted. Additionally, it calls conversation an array while the schema type is string, creating potential confusion.

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 with a specific verb ('Report') and resources ('bug, missing feature, or send feedback'). It distinguishes itself from sibling tools like 'authenticate' or 'marketplace' by explicitly naming the target 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 clearly indicates when to use this tool ('Report a bug, missing feature, or send feedback'), giving clear context. No exclusions or alternative tool references are provided, but none are needed given the distinct purpose among siblings.

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 aligns with annotations (readOnlyHint, idempotentHint, destructiveHint). It does not add extra behavioral details, but the annotations already cover the essential read-only and idempotent nature. No contradiction exists, and the simplicity of the tool means no further disclosure is needed.

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 directly states the purpose. Every word earns its place, and it is appropriately brief for a tool with no parameters or complex behavior.

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 (no parameters, no output schema), the one-line description fully explains what it does. There is no missing context; users can immediately understand the tool's function and leverage it without further details.

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 coverage is 100% (empty schema). Per guidelines, with 0 parameters the baseline is 4. The description correctly omits parameter details, as none exist, so it adds appropriate value.

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 clearly identifies the resource as 'the current MCP platform and adapter versions.' It is unambiguous and distinguishes itself from sibling tools like authenticate or connect, which have different purposes.

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

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

The description implies usage for checking version information, which is clear for a standalone informational tool. It does not explicitly mention alternatives or exclusions, but the simplicity of the tool makes this unnecessary. It provides adequate context without being verbose.

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 safety profile is fully covered. The description adds value by specifying exactly what state is returned (installed MCPs, connection statuses, accounts, count of tools), which is useful behavioral context. There is no contradiction; it accurately reflects a read-only, informational capability.

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-formed sentence that lists the key output elements in order. No extra words or fluff; every word earns its place. It's front-loaded with the action ('Returns') and then the resource with enumerations.

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 that there are no parameters, a clear read-only annotation set, and no output schema, the description covers the key aspects: what is returned (state, MCPs, connections, accounts, tool count). It could potentially mention that there are no parameters or that it's a read-only query, but those are already implicit in annotations and schema, so the description itself is fairly complete for this simple 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, so the input schema provides no burden. The description explains what the tool does without needing to elaborate on parameters. The absence of parameters is clear from the schema, and the description focuses on the output scope, which is all that's needed. A baseline of 4 is appropriate for a zero-param 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 clearly states what the tool does: returns current toolkit state, including installed MCPs, connection status, connected accounts, and number of catalog tools. The verb 'returns' plus specific resource elements (toolkit state, MCPs, accounts, catalog tools) makes it distinct from siblings like 'show_version' 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 communicates the tool's purpose well, and since it's a read-only informational tool with no side effects, it's clearly used when an overview of the toolkit state is needed. However, it doesn't explicitly contrast with alternatives like 'show_version' or 'marketplace' — though its broader scope (state beyond version) implies a distinction.

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