CVM: Processos Sancionadores Julgados

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

Describes session-only vs permanent connection and that it provides a link, but does not explicitly state side effects on config; annotations indicate idempotent and non-destructive, but description adds useful 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?

A bit verbose with multiple conditional paths, but each sentence adds necessary operational detail; not excessive.

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 (one optional param), it covers authentication methods and token usage adequately; lacks explicit mention of output format but that is covered by 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?

Single parameter 'token' is fully explained: it can be provided to authenticate directly or omitted to receive a link; coverage is complete.

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?

Purpose is explicit: 'authenticate' as a verb with specific resource (MCP server) and distinguishes from siblings like 'connect' or 'cvm_sancionadores_consultar'.

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?

Clearly explains when to use each method (browser login, config header, paste token) and when to call with no args to get a link.

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 read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by specifying conditional results: when all providers are connected, it returns authenticated:true with empty pending[], and when credentials are missing, it returns connect_url and per-install URLs. No contradiction 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 two compact sentences, front-loads the core purpose, and includes essential conditional behavior without any filler. Every sentence adds necessary 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?

For a zero-parameter status/inspection tool with strong annotations and clear output states, the description is complete enough. It explains what will be returned in both primary conditions (all connected vs. credentials missing), and no output schema exists to duplicate the result 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%, so there are no parameter semantics for the description to clarify. With no parameters, the baseline is 4, and the description does not need to add parameter-level detail.

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 explains the resource (connection state) with a specific verb ('returns'), and effectively distinguishes itself from sibling 'authenticate' by being a status/read operation rather than an authentication action. However, it does not explicitly name alternatives or contrast itself with siblings.

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?

Usage context is implied rather than explicit: the description explains what the tool reports and when different output is returned, so an agent can infer 'use this when checking connection status.' It does not explicitly state when not to use this tool or recommend alternatives such as 'authenticate.'

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 context beyond annotations by disclosing payment requirements ('pague por consulta com crédito pré-pago') and stating the data is official and not confidential ('não é dado sigiloso'). It also notes LGPD compliance responsibility. These are helpful operational traits, and they align with the readOnlyHint and idempotentHint 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 a single dense sentence that front-loads the primary purpose before adding payment and privacy details. It is not overly verbose, but it packs multiple clauses together, which slightly reduces readability. Still, it is concise and avoids 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?

For a tool with 4 unannotated string parameters and no output schema, the description is very incomplete. It fails to explain the meaning of parameters, the nature of the query (e.g., how to filter), or what data is returned. The payment and legal notes do not fill the gap, leaving agents unable to confidently construct valid requests.

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 4 parameters (termo, data_fim, data_inicio, tipo_filtro) with zero description coverage, and the tool description provides no explanation of these parameters or their expected formats. The description does not compensate for the schema gap at all, leaving parameter usage entirely ambiguous.

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 queries CVM judged sanctioning processes from an official source ('CVM: Processos Sancionadores Julgados, consulta em fonte oficial'). It specifies the verb 'consulta' and the resource 'Processos Sancionadores Julgados', and it is distinct from sibling tools (which are platform utilities like authenticate, 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 does not provide explicit guidance on when to use this tool or when not to. It mentions payment and data responsibility but no comparison to alternatives or situational context. Usage is implied by the name and description but not explicitly 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?

The description richly discloses behavior beyond the minimal annotations: invoke runs tools even when not installed, returns connect or checkout links for credentials/payment, and requires retry after user action. It also states that writes (install/uninstall/subscribe/cancel) need workspace owner/admin. This adds substantial operational context that the annotations do not provide.

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 every sentence adds value, covering the catalog flow, invoke edge cases, install vs invoke guidance, permissions, and the prompt library. It is dense and structured as a continuous block without bullet points, but the information is efficiently organized by flow. It earns its length.

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 (14+ actions, 23 params, no output schema, minimal annotations), the description is remarkably complete. It explains the search/describe/invoke flow, the one-off execution behavior, credential/payment handling, permission requirements, and the separate prompt library subsystem. This covers virtually every aspect an agent would need to use 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?

With 0% schema description coverage, the description compensates by explaining the meanings of key parameters indirectly: tool_id is chosen from describe output, arguments are passed to invoke, action values map to the enumerated workflow. However, many parameters (limit, immediate, tier_slug, cancel_reason, prompt_* fields) are not individually explained, so the compensation is strong but incomplete for a 23-parameter 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 this is 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It uses specific verbs and resources (search, describe, invoke, install, list_tools) and distinguishes its multi-action nature from any single-purpose sibling tools. The scope is unmistakable.

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 guidance: 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT in the active toolkit.' It outlines the core flow (search → describe → invoke) and mentions when connect/checkout links require user action. It does not explicitly compare against sibling tools like connect or authenticate, but the internal alternatives are well addressed.

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 does not disclose any side effects beyond the act of reporting. Annotations indicate non-destructive and idempotent behavior, but the description adds no new behavioral details. It does not mention potential system impact or data handling, but the annotations provide baseline transparency.

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 to the point, with two sentences. It efficiently conveys the main purpose and an important usage detail without unnecessary 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?

The description covers the tool's purpose and hints at usage, but it lacks elaboration on parameters, expected output, or any side effects. Given the simple nature of the tool, this might be adequate, but it is not comprehensive.

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 three parameters but the description only explains 'conversation' (as an array of recent messages). 'message' and 'context' are not described, and the schema itself has zero descriptions. Thus, the description adds minimal value for most 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 states the tool's purpose: to report a bug, missing feature, or send feedback. It uses a specific verb and object, 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 provides little guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or contexts where reporting is appropriate. The only instruction is to include the conversation array, which is more about how to use it than when.

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 is consistent with the annotations (readOnlyHint=true, destructiveHint=false) but adds minimal behavioral context beyond naming the versioned components. It does not discuss side effects, network calls, or return details, but the annotations already cover the safety profile.

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?

A single declarative sentence that is front-loaded and to the point. Every word adds value, and there is 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?

For a parameterless tool with no output schema, the description is sufficiently complete. It names the two pieces of information returned (platform and adapter versions), which is sufficient for the tool's simplicity.

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 zero parameters, the schema is fully covered and no parameter semantics are needed. The tool needs no parameter documentation, so the baseline score of 4 applies.

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 'Show' and clearly identifies the resource 'current MCP platform and adapter versions'. It cleanly distinguishes itself from sibling tools like connect or authenticate by pinning down the exact version-related scope.

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?

No usage guidance is provided. The description does not explain when to use this tool, when not to, or how it relates to alternatives such as toolkit_info.

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 value by specifying the type of content returned (installed MCPs, connection status, accounts, counts), which is behavioral context beyond the annotations. It does not contradict any annotations and provides useful transparency about the response contents.

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, efficient sentence that leads with the core action ('Returns the current toolkit state') and then lists the details. Every word earns its place; there is no fluff or redundant phrasing. It is excellently front-loaded and concise.

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 read-only state tool with no parameters and no output schema, the description covers the key information an agent needs: what the tool returns and the categories of data. It doesn't specify exact formatting or potential error conditions, but those are not critical for this tool, especially given the strong annotations. It is complete enough for practical use.

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 in the schema, and per the rules, the baseline for 0 params is 4. The description adds no parameter information because none exist. It correctly doesn't attempt to explain nonexistent parameters, so 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 the tool's purpose: 'Returns the current toolkit state' and enumerates exactly what it includes (installed MCPs, connection status, accounts, catalog tool counts). This uses a specific verb ('returns') and resource ('toolkit state'), and it implicitly distinguishes from sibling tools like show_version (which focuses on version only) and connect/authenticate 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 provides clear context on when to use it: when you need the current toolkit state and its components. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent would know to call it for status overviews. It lacks explicit 'when not to use' guidance, so it stops short of a 5.

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