CEAF (Expulsões)

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

Beyond the annotations (idempotent, non-destructive), the description reveals how the tool behaves: calling with no args returns a login link, calling with a token sets a session, and config-based authentication is permanent and non-expiring. It also implies the tool is non-destructive and idempotent, which aligns with annotations. This contextualizes the auth flow without contradicting 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 somewhat lengthy but each sentence carries essential information. It is front-loaded with the primary use case and provides concrete steps. The structure could be tidier (e.g., separating config auth from session auth), but it remains concise enough for an agent to parse quickly.

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 one optional parameter and no output schema, the description is fairly complete: it explains the main flows (no args → link, with token → session, config → permanent), and mentions the return value ('the link'). It could mention potential error scenarios or the exact response format after token submission, but for an auth tool this is adequate.

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 a single 'token' field with no description, and schema coverage is 0%. The description compensates fully by explaining that 'token' should be a JWT for session-only login, and that omitting it retrieves a login link. It also mentions the config header format, offering complete parameter semantics despite the sparse 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?

The description clearly states the tool's purpose: to authenticate an IDE agent to the MCP.AI server. It specifies the resource (MCP.AI server) and the action (log in, obtain access token). It distinguishes from siblings by detailing the authentication flow, including browser login and token handling, which is unique among the listed 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 provides clear usage guidance: it recommends adding the token to the server config for a permanent connection, and explains when to pass the token for session-only login or call with no args to get the login link. It doesn't explicitly exclude sibling tools, but the guidance is sufficient for this self-contained authentication tool.

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 annotations (readOnly, idempotent, non-destructive), the description adds significant behavioral context: it is hosted, requires no credentials, is paid per consultation, accesses only public data, and designates the client as LGPD controller. This fully discloses the operation's nature and data source.

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 and front-loaded with the core action. It then adds operational and legal details without unnecessary fluff, though the LGPD clause is slightly wordy but still relevant.

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 consultation tool with strong annotations, the description covers the main purpose, payment model, and data public nature. The main gap is the undocumented 'completo' parameter and lack of return format, but the essential required parameter (CPF) is clearly present, so the tool can be invoked 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 schema has no descriptions, and the description explicitly ties the CPF parameter to the query input. However, it completely ignores the 'completo' boolean parameter, leaving its purpose ambiguous. Thus, it partially compensates for the schema's 0% coverage.

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 verifies if a person appears in the CEAF registry using CPF, using a specific verb (Verifica) and resource. This distinguishes it from sibling tools like authenticate or connect, 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?

It provides context on how to use the tool: hosted, no credentials, pay-per-query with prepaid credit. However, it does not explicitly mention when not to use it or name alternatives, so it slightly misses the full guideline bar.

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, and the description adds meaningful behavioral context: it describes the return values under different credential states (all connected vs. missing credentials). 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 two sentences, front-loads the core purpose, and then provides conditional details. Every sentence adds value with no filler or repetition.

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 tool, the description covers the two main scenarios (all connected, credentials missing) and mentions key return fields. It doesn't cover partial connection states or exact URL structures, but the simplicity and annotations reduce the need for more.

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 no parameters, so the description doesn't need to explain parameter semantics. The baseline for 0 parameters is 4, and the description provides no irrelevant 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 clearly states the tool returns connection status and URLs, with a specific verb and resource. It distinguishes from siblings by focusing on status rather than authentication or other actions, though it doesn't explicitly name alternatives.

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 connection status and explains conditional outcomes, but it doesn't explicitly state when to use this tool instead of siblings like authenticate. There's no explicit exclusion or 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 goes far beyond the sparse annotations by detailing key behaviors: invoke works even for uninstalled MCPs, returns connect/checkout links for auth/payment, performs a one-off install without bloating the toolkit, and flags installed status in search/describe. It also discloses that writes require workspace owner/admin. No contradictions with 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 information-dense with no fluff, but it is a single unbroken block of text that is lengthy and lacks clear structure. The 'KEY:' marker and a few commas help, but the overwhelming amount of detail makes it harder to parse than it could be.

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 the main flows, auth/payment edge cases, permission requirements, and the prompt library. However, it omits some actions (e.g., resume) and does not explain what certain parameters do, leaving gaps for an agent trying to fully understand the tool's capabilities. Still, given the tool's complexity, it is largely complete.

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 must compensate, and it does explain the most critical parameters: action, mcp_id, tool_id, arguments, and the prompt_* fields. However, it leaves some parameters unexplained (e.g., immediate, conversation, message, cancel_reason, request_details), so while it adds substantial meaning, it doesn't fully cover all 23 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 identifies the tool as the official mcp.ai marketplace and explains its dual role as catalog and runner of MCPs/tools. It also distinguishes itself from sibling tools by outlining its unique capabilities (search, describe, invoke, prompt library), making it highly specific 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?

The description provides explicit guidance on when to use each action: '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 also outlines the core flow (search → describe → invoke) and clarifies when to use list_tools, subscribe/cancel, and report_bug. This is exemplary usage 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 idempotentHint=true and destructiveHint=false. The description adds the behavioral nuance that the conversation array is included for reproduction, which aids the agent in understanding the expected input utility, though it does not disclose side effects or post-send behavior.

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, front-loaded with the core purpose, and every word adds value. No filler or redundant details.

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 bug-reporting tool, the description covers the essential aspects: what to report and the key parameter (conversation). The absence of an output schema makes return-value details unnecessary. Minor gap is the context parameter, but overall it is adequately complete.

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 must compensate. It explains the conversation parameter explicitly but does not mention context or message. Message is inferable from the purpose, but context remains undefined, leaving a gap in parameter understanding.

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 resource ('a bug, missing feature, or send feedback'). It distinguishes itself from unrelated sibling tools 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 instruction 'Include the conversation array with recent messages for reproduction' provides clear context on how to use the tool effectively. While no explicit when-not-to-use guidance is given, the tool's purpose is distinct from siblings, so exclusion is unnecessary.

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 agent knows this is a safe read operation. The description adds the specific scope of 'MCP platform and adapter versions' but no additional behavioral traits such as pagination or return format, which is acceptable given the simplicity.

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 with no wasted words. It immediately identifies the action and target, making it highly scannable for an agent.

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-information tool with no parameters and no output schema, the description fully covers what an agent needs to know. The scope is clear, and no additional context is necessary.

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 is empty and there is no parameter semantics burden. The baseline for no parameters is 4, and the description correctly focuses on what the tool does rather than inventing parameter details.

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 exact resource ('current MCP platform and adapter versions'), making the tool's purpose unambiguous. It clearly distinguishes itself from sibling tools such as authenticate or connect, which serve different 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 context by stating exactly what information the tool returns, allowing an agent to infer when to use it. However, it does not explicitly mention alternatives or when not to use it, so it misses the top tier for excluding other tools.

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, establishing a safe read-only operation. The description adds context about what the response includes (installed MCPs, connection status, accounts, catalog tool counts), which is beyond the annotations' coverage.

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 entire description is one well-structured sentence that front-loads the core purpose ('Returns the current toolkit state') and then specifies exactly what is included. There is no wasted wording.

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 0-parameter read-only tool with no output schema, the description is sufficiently complete. It tells the agent what to expect from the return value, which is the main requirement 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 semantic information. The description does not need to compensate for parameter documentation; the baseline of 4 applies 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 uses a specific verb ('Returns') with a clear resource ('current toolkit state') and enumerates the contents (installed MCPs, connection status, accounts, catalog tool counts). This clearly distinguishes it from sibling tools like authenticate, connect, or show_version, which handle 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 implies the tool is for checking toolkit state but does not explicitly state when to use it over alternatives or provide exclusions. Sibling tools are semantically different, so the context is clear, but the description lacks direct guidance on usage scenarios.

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