CND Federal

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about non-expiring vs session-only login and the browser link flow, but does not disclose behaviors like whether calling with no args invalidates existing sessions or how the token is validated/stored beyond the config header recommendation. Given annotation coverage, a 3 is fair, but more detail about the exact side effects (e.g., does session token overwrite config?) would improve it.

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, front-loaded with the audience and purpose, and covers all critical usage paths. It is slightly dense and could be broken into clearer steps, but every sentence adds necessary information about login modes and the recommended config approach. 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?

For an auth tool with minimal schema (one optional string) and no output schema, the description covers the workflow well: browser login link, token paste, session vs permanent. It lacks explicit mention of what the tool returns (e.g., success message) or error handling, but given the simplicity of the inputs and adequate annotations, the description is largely complete. Minor gap around post-login state verification.

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% and the only parameter 'token' has no description, so the description carries the full burden. The description clarifies that 'token' is an optional JWT for session-only login, and that omitting it yields the link. This compensates well for the schema's lack of detail, but does not explain token format/expiry beyond calling it a JWT.

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 this tool handles authentication for MCP.AI IDE agents: it provides a browser login flow, accepts a pasted JWT token for session login, and explains the permanent config-based alternative. The verb 'log in' plus the resource (MCP.AI server access) and the distinct paths make the purpose unambiguous, even though there are no direct sibling login 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 explicitly explains when to use each mode: 'call with { token: "<jwt>" } after the user pastes' for session-only login, or 'no args to get the link' for browser login. It also recommends the config-header approach as the best permanent alternative, giving clear decision 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 the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond these hints: it discloses the payment model (pay per query), the public nature of the data, the lack of credentials, and the LGPD responsibility of the client as data controller. This provides a clear operational and compliance picture without contradicting 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?

The description is concise and well-structured. It leads with the primary purpose, then adds essential operational and legal context in a few sentences. Every sentence earns its place, and there is no redundant or filler content.

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 absence of an output schema and the 0% parameter description coverage, the description should provide more detail on expected inputs and outputs. It explains the high-level context and legal responsibilities, but it does not describe what the response contains or how to properly fill all parameters. This leaves gaps that an agent would need to resolve through inference or trial, making the tool under-documented 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?

The schema has 0% description coverage on parameters, so the description must compensate. It mentions 'a partir do CPF ou CNPJ', which gives a clue that one of these fields identifies the entity, but it does not explain the format, semantics, or purpose of the required fields 'ie' and 'Uf', nor the optional 'completo' flag. The description also implies that only CPF or CNPJ is needed, while the schema requires both, creating confusion for the agent.

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: to issue a federal Certidão Negativa de Débitos (CND) for an individual or company using CPF or CNPJ. The verb 'Emite' is specific, the resource is precisely identified, and the scope is unambiguous. It uniquely distinguishes itself from sibling tools, none of which perform similar certificate-issuing functions.

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 clear contextual guidance: it states the tool is hosted on the platform, requires no credentials, and charges per query with prepaid credit. It also clarifies that the data accessed is public, which sets expectations for legitimate use. However, it does not explicitly mention when not to use the tool or name alternative approaches, though no sibling tools offer a comparable function.

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, and the description adds behavioral details on return values (authenticated:true, empty pending[], connect_url). This adds value beyond annotations without contradiction.

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 contains no extraneous information. Every clause 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?

For a zero-param, read-only status tool with no output schema, the description covers the key states and returned fields (authenticated, pending, connect_url). It is sufficiently complete for this simple tool, though it could have included a note about response format or error conditions.

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 no parameters and coverage is 100% (empty schema). Per rubric, 0 params earns baseline 4; the description does not need to elaborate on parameter 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 clearly states 'Returns connection status and URLs' and explains the conditional outcomes for connected vs missing credentials. This distinguishes it from sibling tools like authenticate, which likely performs authentication rather than status checking.

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 for checking connection/auth status and provides clear context about when its output is relevant, but it does not explicitly state when to use it over alternatives or mention exclusions. The context is clear enough without explicit alternative 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?

The description reveals behaviors beyond annotations: invoke works even when the MCP is not installed and triggers a one-off install; it returns connect/checkout links for auth/payment flows; writes require workspace owner/admin; and the prompt library is a separate feature. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false).

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 information-dense, front-loading the core purpose and then detailing workflow and key edge cases. It could be better structured with bullets, but every sentence contributes meaningful guidance for a complex multi-action tool.

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 23 parameters, no output schema, and multiple action modes, the description covers the main flows, auth/payment requirements, install vs invoke distinction, and the auxiliary prompt library. It gives enough context to select actions and understand return-link behaviors, making it complete for the tool's 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?

With 23 parameters and 0% schema description coverage, the description compensates well by explaining the core flow: action=search, describe returns profiles with tool_id, invoke runs with arguments, and prompt-related actions handle prompt variables. However, several parameters (like conversation, cancel_reason, prompt_targets, tier_slug) are not explained, so full compensation is incomplete.

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 mcp.ai marketplace catalog and execution engine, with a specific verb+resource structure. It distinguishes the main actions (search, describe, invoke) and contrasts it with siblings by explaining that it covers capability requests and runs tools, which is not indicated for other 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?

Provides explicit when-to-use guidance, e.g., 'prefer invoke for a single/occasional use' vs 'Use install only to make an MCP PERMANENT', and explains list_tools for what is callable right now. It also notes that search/describe flag installed status and that writes require owner/admin, offering clear decision criteria for action selection.

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 mark this as non-read, non-destructive, and idempotent. The description adds context beyond annotations by explicitly instructing to include the conversation array with recent messages for reproduction, which is a key behavioral expectation for the tool's effective use.

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 highly concise, using two sentences with no redundant information. The first sentence states the core action, and the second provides the critical usage detail, making it 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?

For a simple tool with three parameters and no output schema, the description covers the core function and the necessary reproduction step. It does not explain the 'context' parameter, but this is a minor omission given the tool's simplicity and the presence of a default value in the schema.

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 explicitly mentions the 'conversation' parameter and its purpose ('recent messages for reproduction'), but does not clarify the 'context' parameter or the exact content of 'message' beyond the tool's general purpose. This is partial compensation.

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 distinguishes the resource types ('bug, missing feature, or send feedback'). It also explains the required context for reproduction, making it unambiguous when compared to unrelated siblings like 'authenticate' or '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 provides clear context for when to use the tool: whenever a bug, missing feature, or feedback needs to be reported. It does not explicitly exclude other scenarios, but the action is obvious. The instruction to include the conversation array gives a specific usage guideline for effective reproduction.

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 readOnly and idempotent hints, so the safety profile is covered. The description adds that both platform and adapter versions are shown, which is useful but minimal, similar to the get_calls example where the constraint was significant; here the addition is just scope of output.

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, clear sentence that is front-loaded with the verb and resource. It is appropriately terse for a tool that takes no parameters and performs a simple read-only operation.

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 (no parameters, read-only, no output schema), the description provides enough info to understand what the tool does and what to expect in return. It is complete for its scope.

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 zero parameters, and schema description coverage is vacuous (100%). Per the rules, the baseline for 0 params is 4, and the description need not compensate for any undocumented parameters since none exist.

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 shows the current MCP platform and adapter versions, using the specific verb 'Show' and identifying the resource. This distinguishes it from siblings 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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It is a bare statement of functionality without contextual usage cues.

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 this as read-only, idempotent, and non-destructive. The description adds value by specifying exactly what aspects of state are returned (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond the annotations. It does not add any caveats about errors or volatility, but given the strong annotation coverage, this is sufficient.

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 action ('Returns') and then provides a clear, comma-separated list of the returned contents. Every word earns its place; no filler or 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?

Given the tool's simplicity (no parameters, no output schema), the description fully captures what an agent needs: what the tool does and what the return value contains. The listed items (installed MCPs, connection status, accounts, catalog tool counts) give a complete picture of the toolkit state without requiring an output schema.

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 takes zero parameters, so there is nothing to explain in the description. The schema fully covers the (empty) parameter set, and the description provides no additional parameter semantics needed. Baseline for zero params is 4.

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 'Returns' and identifies the resource as 'current toolkit state', then enumerates the key pieces of information (installed MCPs, connection status, accounts, catalog tool counts). This clearly distinguishes it from sibling tools like authenticate or show_version, 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 provides a clear context for when to use the tool (whenever you need to inspect toolkit state). It does not explicitly mention alternatives or when not to use it, but the context is unambiguous enough that an agent can infer its appropriate use.

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