Compliance & Sanções

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

Description details the side effects: token added to config gives a permanent non-expiring connection, while pasting here gives session-only. It also notes that calling with no args produces a login link. Annotations are simple (idempotent, non-destructive) and the description does not contradict them, adding meaningful behavior context beyond the schema.

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?

Three sentences that are informative and front-loaded, but the first sentence mixes tool purpose with user instructions (logging in in the browser), making it slightly longer than necessary. Still, each clause 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?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the complete behavior: what the token is, how to provide it, and what happens in each scenario. It effectively compensates for the lack of schema parameter descriptions.

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 only defines 'token' as a generic string, but the description explains it as a JWT, distinguishes between providing it for session login vs. permanent config, and specifies calling with no arguments. This fully compensates for the 0% schema description 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 that the tool authenticates the MCP server for IDE agents, with a specific verb ('log in') and resource ('server'). It distinguishes itself from all sibling tools, which are compliance search tools, by focusing purely on authentication.

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?

Explicitly explains when and how to use: call with a token for a session-only login, call with no arguments to get a link, and recommends adding the token to config for a permanent connection. This provides clear context on when to invoke it and how the token should be supplied.

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, so the description adds context about the data source (Civil Police criminal records) but nothing about return format, response structure, or limitations. Given the annotations cover the safety profile, the description provides moderate additional context without 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, front-loaded sentence conveying the core purpose efficiently. No filler or redundant text, though it could be slightly expanded to cover more parameters without becoming verbose.

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?

With eight parameters, no output schema, and no descriptions of return values or behavioral nuances, the description is too thin. It fails to explain required vs optional parameters, expected input formats, or what the response contains, making it incomplete for a tool with this 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 0% schema description coverage, the description must compensate, but it only mentions CPF, name, and UF as query methods. The remaining five parameters (RG, GENERO, NOMEMAE, completo, DATANASCIMENTO) are unexplained, leaving the agent with insufficient understanding of their meaning or 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 clearly states the tool retrieves criminal records specifically from the Civil Police (Polícia Civil) and indicates it can be queried by CPF, name, or UF. This verb+resource phrasing distinguishes it from siblings like compliance_antecedentes_pf (Federal Police), making 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 by listing queryable fields (CPF, name, UF) but provides no explicit guidance on when to prefer this tool over alternatives like compliance_antecedentes_pf or other compliance tools. It does not mention exclusions or prerequisites, so it's only implied rather than explicit.

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 read-only, idempotent, and non-destructive behavior. The description does not add further detail (e.g., rate limits, authentication requirements) but also does not contradict annotations. Minimal extra disclosure is provided.

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 with no redundant information. It efficiently conveys the core purpose without verbosity.

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?

There is no output schema, so the description need not explain return values. It provides sufficient context for the tool's basic operation, though it lacks details on prerequisites or edge cases. Overall, it adequately covers the essential context for a simple query 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 description mentions only 'CPF/nome' (CPF and NOME) among the six schema parameters. It does not explain the purpose of NOMEMAE, NOMEPAI, DATANASCIMENTO, or 'completo', leaving most parameters underdocumented. Given the low schema coverage, the description fails to compensate.

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: retrieving criminal records from the Federal Police by CPF or name. This is specific and distinguishes it from sibling tools that handle other compliance checks (e.g., civil, ANTT, 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?

The description implies usage (for criminal record checks) but does not explicitly state when to choose this over alternatives. It lacks guidance on criteria like when to use PF vs other compliance tools, though the name provides some context.

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 operation is read-only, idempotent, and non-destructive, so the description's burden is lower. It adds that the query is based on CPF/CNPJ/RNTRC, but does not disclose whether inputs are alternatives, how 'completo' behaves, or what the response contains. It does not contradict 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?

A single, front-loaded Portuguese sentence communicates the tool's domain, target, and query identifiers with no waste. Every phrase earns its place, and the structure is appropriate for a small compliance-lookup 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?

The description covers the main purpose and safety profile, and the annotations make the read-only nature clear. However, with no output schema, no parameter descriptions, and an unexplained 'completo' parameter, the description leaves meaningful gaps for an agent deciding how to invoke 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 must compensate for the schema's bare property names. It adds meaning by naming CPF, CNPJ, and RNTRC as query keys, but it does not explain the fourth parameter 'completo', nor does it clarify if any identifier is required or how they relate.

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's purpose as checking ANTT carrier regularity and explicitly names the query keys (CPF/CNPJ/RNTRC). It distinguishes itself from sibling compliance tools through the specific ANTT/transportadora domain, though it lacks an explicit verb such as 'consulta' or 'verifica'.

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 domain ('Regularidade de transportadora na ANTT') lets an agent infer when to use this tool: when checking Brazilian land carrier compliance status with ANTT. However, it gives no explicit guidance on when not to use it or how it relates to the many sibling compliance 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. The description adds that the tool covers a 'quadro geral de inabilitados' keyed by CPF/CNPJ, which is modest context but does not contradict annotations. No return format, pagination, or other behavioral details are disclosed.

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, compact phrase with no filler or redundant words. It is front-loaded with the most important information (Banco Central and the list type) and is appropriately sized for a simple lookup 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 simple read-only tool with strong annotations, this is minimally serviceable. However, clear gaps remain: the 'completo' parameter is undefined, there is no output format description, and no distinction from similar compliance_bacen_proibidos is provided. The description is adequate but not rich.

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 provides zero descriptions for its two parameters, so the description must compensate. It partially does by indicating 'por CPF/CNPJ', clarifying that the CPF parameter accepts CNPJ as well, but it leaves the 'completo' boolean parameter completely unexplained.

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 identifies the resource ('quadro geral de inabilitados' — general list of disqualified persons) and scope ('por CPF/CNPJ'), making the tool's function reasonably clear. However, it is a noun phrase rather than an explicit action statement, and it does not distinguish this from the sibling tool compliance_bacen_proibidos.

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 the many sibling compliance_* tools, nor does it state any prerequisites, exclusions, or alternative tools. It simply names the resource without contextualizing its appropriate use.

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 and idempotentHint true, so there is no contradiction. The description adds only the dataset scope but does not disclose behavior such as whether results require exact matches, what 'completo' changes, or the response shape—useful context that would go beyond 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 a single front-loaded phrase with no filler, efficiently naming the resource and the core query parameter. It is concise, though its brevity contributes to the lack of parameter semantics.

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?

With no output schema and no parameter documentation, the description is too sparse for confident invocation. It does not specify required inputs, the meaning of 'completo', expected results, or how this list differs from the BACEN 'inabilitados' 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%, so the description must compensate. It clarifies that CPF and CNPJ are lookup keys, but it does not explain whether at least one is required, what format they should take, or what the 'completo' boolean does.

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 identifies the specific resource ('Banco Central — quadro geral de proibidos') and the lookup dimension ('por CPF/CNPJ'), making the tool's purpose clear. It also helps distinguish it from sibling tools like compliance_bacen_inabilitados, though it lacks an explicit verb such as 'consult' or 'search'.

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 phrase 'quadro geral de proibidos' implies use when checking whether a CPF/CNPJ appears on the Central Bank's general prohibited list. However, it does not explicitly say when to choose this tool over related compliance siblings, nor does it mention exclusions or 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 indicate read-only and idempotent behavior, and the description adds the subject matter without contradicting; however, it does not mention any return format or side-effect details not covered by 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 a single short phrase, extremely concise, with no unnecessary 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 lack of output schema and minimal parameter descriptions, the description does not provide enough context for a user to understand what data is returned or any usage caveats; it is merely a label.

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 three of the four parameters (UF, CPF, CNPJ) but omits 'completo' and provides no details on formats, requiredness, or relationships between 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 querying state CADIN (debtors with the treasury) by CPF/CNPJ/UF, distinguishing it from other compliance-related 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 does not provide explicit guidance on when to use this tool versus the many sibling compliance tools, relying solely on the name and minimal description.

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 covered. The description adds only the data source (CARF) and lookup key (CPF/CNPJ); it does not disclose response shape, pagination, or behavior when both identifiers are supplied.

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 one compact, front-loaded sentence with the acronym expanded in parentheses. Every word is useful and there is no extraneous detail.

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 3-parameter tool with no output schema, this description is incomplete. The optional 'completo' parameter, the expected output format, and how CPF/CNPJ are expected to be provided are all missing, leaving an agent to guess at correct invocation.

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 schema description coverage at 0%, the description must compensate, but it only mentions CPF/CNPJ as lookup keys. The 'completo' boolean parameter is entirely unexplained, and the relationship/alternation between CPF and CNPJ is 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 states the tool returns processes in CARF (an administrative tax appeals council) keyed by CPF/CNPJ. It is distinct from sibling compliance tools due to the specific CARF data source, though there is no explicit verb like 'list' or 'search'.

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 context is given for when to use this tool versus any of the many sibling compliance_* tools. The description does not say when CPF vs CNPJ should be used or mention any alternative for similar queries.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds no behavioral context such as response shape, no-result behavior, or data coverage. It only restates the domain content and does not go beyond the structured 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 very short and free of filler, but it is a terse noun-phrase fragment rather than a complete, self-contained sentence. Under-specification limits the value of the brevity.

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 the tool has no output schema and minimal parameter documentation, the description should explain what CEAF is, what 'completo' controls, and how to interpret results. It provides none of that, so it is not adequate for an agent to invoke confidently.

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 'por CPF', which aligns with the CPF property, but it does not explain the 'completo' boolean parameter at all. With 0% schema description coverage, the description should compensate for both parameters; it fails to do so.

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 identifies the data source (CEAF), its scope (expulsões da administração federal), and the key input (CPF), which distinguishes it from sibling compliance tools. However, it lacks an explicit verb such as 'consulta' or 'verifica', so it reads as a noun phrase rather than a clear tool action.

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 guidance is provided about when to use this tool instead of the many sibling compliance tools, nor are prerequisites or exclusions mentioned. The only implicit usage hint is the CPF parameter in the description.

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 well covered. The description adds domain context about the CEIS registry's content (unfit/suspended companies), but does not disclose behavior like pagination, result format, or any special data source nuances. No contradiction with annotations exists.

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 phrase with no fluff or repetition. It front-loads the essential registry name and scope. However, it is so terse that it sacrifices useful detail, so it does not reach the top tier of conciseness that balances brevity with explanatory value.

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 3 parameters with no schema descriptions, no output schema, and no usage guidance, the description is too sparse to fully enable correct tool invocation. It does not address what 'completo' controls, whether both identifiers can be supplied, or what the response looks like. The tool's simplicity offsets some of this, but the coverage gap remains significant.

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% for the three parameters (CPF, CNPJ, completo). The description clarifies that CPF and CNPJ are lookup identifiers, but it does not explain the 'completo' parameter at all. It also omits format expectations (e.g., digits only, requiredness) despite missing schema descriptions, leaving a significant semantic gap.

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 identifies the specific registry (CEIS) and its content ('empresas inidôneas e suspensas'), plus the lookup key ('por CNPJ/CPF'). This distinguishes it from sibling compliance tools for other registries. However, it lacks an explicit verb like 'consult' or 'search', relying on the tool name and context to imply the query action.

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 guidance is provided on when to use this tool versus alternatives. It simply states the registry and lookup key, without mentioning exclusions, prerequisites, or which sibling tools cover overlapping or complementary registries. The agent must infer usage from the name and domain context.

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, so the safety profile is clear. The description adds only that it concerns 'private entities impeded' but doesn't elaborate on return format, pagination, or authorization needs, providing minimal extra 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 extremely short, which is concise but under-specified. It lacks any structure or detail; while it has no fluff, it also doesn't earn full marks for conciseness because it omits essential 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 tool with 0% parameter coverage and no output schema, the one-line description is insufficient. It doesn't explain expected inputs, output semantics, or how 'completo' changes behavior, making it hard for an agent to use 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?

Schema description coverage is 0%, and the description does not explain the 'CNPJ' or 'completo' parameters at all. With no compensation, the agent has no idea what values to provide or what 'completo' controls.

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 identifies the specific registry (CEPIM) and key (CNPJ), implying a lookup/check operation. It's clear but lacks an explicit verb like 'check' or 'query', and it doesn't differentiate from the many sibling compliance tools other than by name and registry type.

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 guidance is given on when to use this tool vs. the extensive list of sibling compliance tools. It doesn't mention any exclusions, dependencies, or typical use cases.

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 read-only nature is covered. The description adds the specific data source (CGU penalties) and the query identifiers (CPF/CNPJ), but does not disclose any additional behavior such as format of results, pagination, or limitation of 'completo' parameter. With annotations covering safety, 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 a single, concise sentence in Portuguese that directly states the purpose. It is front-loaded with the main verb 'Consulta' and the resource 'penalidades CGU', with no wasted words. It perfectly fits a short-structure style.

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 4 parameters including a required TIPO that is not explained, and no output schema, the description is incomplete. It does not clarify how to invoke the tool correctly (e.g., what TIPO values are expected, whether CPF or CNPJ must be provided conditionally, what 'completo' does). For a compliance query tool, users need more guidance to use it 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. The description mentions CPF/CNPJ as identifiers, which helps, but it does not explain the semantics of 'TIPO' (required parameter) or 'completo' (boolean). The description is insufficient to understand how to fill the parameters correctly, especially since TIPO is required but its possible values are undocumented.

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 says "Consulta de penalidades CGU por CPF/CNPJ" (Query CGU penalties by CPF/CNPJ), which clearly indicates the tool performs a read-only query of penalties from the CGU (Comptroller General of the Union) based on a Brazilian individual (CPF) or company (CNPJ) identifier. It distinguishes from siblings by mentioning the specific CGU source and the query-by-document approach.

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 penalties from CGU by document, but it does not explicitly state when to use this tool versus alternatives like compliance_ceis, compliance_cnep, or compliance_ceaf, which might also be penalty-related lists. No when-not-to-use or alternative tool naming is provided. Given the large sibling set, more guidance on selecting this specific tool would be helpful.

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 specify read-only, idempotent, and non-destructive behavior. The description adds that it returns a certificate, consistent with annotations, but no further behavioral detail is provided.

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, concise sentence with no redundant words, effectively conveying the tool's core function.

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?

Description is sparse; lacks details on output format, purpose of 'completo', and any prerequisites, though it covers the essential purpose and required municipality parameter.

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?

Mentions CNPJ/CPF and municipality, but does not explain the 'IM' or 'completo' parameters, leaving uncertainty about their meaning or optionality.

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?

Description clearly states it provides a municipal negative debt certificate via CNPJ/CPF, distinguishing it from other compliance tools that target different scopes (e.g., antecedentes, CEAF).

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?

Indicates the need to inform the municipality, implying this tool is for municipal-level debt checks, but does not explicitly mention when to use this over sibling tools or list 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 destructiveHint=false, so safety is covered. The description adds minimal context by indicating the registry covers punished companies and is searchable by CNPJ/CPF, but it does not disclose result shape, pagination, or whether CPF and CNPJ are mutually exclusive or combinable.

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 extremely concise with no filler or repetition; the key terms CNEP, empresas punidas, and CNPJ/CPF are front-loaded. However, the brevity sacrifices essential operational detail, making it more under-specified than genuinely well-structured.

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?

With 3 optional parameters, no output schema, and 30+ similar compliance siblings, the description is too sparse for an autonomous agent to reliably select and invoke the tool. It omits how parameters combine, what 'completo' changes, and any behavioral distinctions from analogous registries.

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 carry parameter meaning. It only clarifies that CNPJ and CPF are accepted query identifiers; the 'completo' boolean parameter is left entirely undefined, and no formats, combinations, or optionality semantics are provided.

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 identifies the specific registry (CNEP), the subject matter (empresas punidas/punished companies), and the query keys (CNPJ/CPF). While it lacks an explicit verb such as 'consulta', the intent as a lookup tool is clear and distinct from the many other compliance_* sibling registries.

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 guidance is provided on when to choose CNEP over sibling tools like compliance_ceis, compliance_cgu, or compliance_leniencia. There are no exclusions, prerequisites, or alternative-comparison cues to help an agent decide among the large set of compliance registries.

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 read-only, idempotent, and non-destructive behavior. The description adds only the domain context (CONFEA/CREA, engineering/agronomy) and does not disclose return format, authorization needs, or any other behavioral traits beyond what the annotations 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 a single, short sentence with no filler or redundant information. It is appropriately sized for the amount of content it conveys, though that content is minimal.

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?

There is no output schema, yet the description does not indicate what the tool returns. It also leaves the operation implicit and parameter semantics unexplained; the short domain label alone is insufficient for a complete understanding.

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%, yet the description does not explain any of the three parameters (CPF, completo, REGISTRONACIONAL). The agent must infer their meaning from names alone, so the description adds no value for 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 identifies a specific resource (professional registration at CONFEA/CREA) and adds domain context (engineering/agronomy), which distinguishes it from other compliance tools. However, it lacks an explicit action verb such as 'check' or 'query', so it is not fully clear what the tool does with the registration.

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 guidance is given about when to use this tool versus alternatives. The sibling list contains many other compliance_* tools, but the description provides no criteria, exclusions, or references to 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, covering safety. The description adds no behavioral context beyond the fact that it queries 'cadastro' data. It fails to explain what the 'completo' parameter does, the shape of responses, or any potential limitations (e.g., rate limits, data coverage). With a low bar set by annotations, it still falls short by omitting non-obvious 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 a single sentence with no filler or redundancy. It is front-loaded with the essential purpose and identifiers. Every word earns its place; there is no bloat.

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 three parameters, no output schema, and many closely related siblings, the description is severely incomplete. It does not explain the 'completo' parameter, how to select this tool over alternatives like compliance_cvm_sancionadores, or what the response contains. The description carries the full burden here and leaves too many gaps for safe autonomous 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?

Schema description coverage is 0%. The description hints at CPF and CNPJ as identifiers but does not explain their formats, mutual exclusivity, or the 'completo' boolean parameter. Since there are three parameters and none are described in the schema, the description should compensate but only covers two superficially. No details on required/optional behavior are given.

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 (Brazilian SEC) registration records by CPF/CNPJ. It uses a specific resource (CVM cadastro) and identifier types, distinguishing it from sibling tools like compliance_cvm_sancionadores (sanctioned entities). However, it is phrased as a noun phrase rather than an explicit action verb, so it could be clearer about what it does (e.g., 'Check registration status').

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 guidance is provided on when to use this tool versus the many compliance siblings. It does not mention that it is for registration checks (as opposed to sanctions or debits), nor does it offer alternatives or exclusions. The agent must infer context from the name alone, which is risky given the large tool family.

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, so the description carries little burden for safety disclosure. It adds that the tool operates by CPF/CNPJ, which is a parameter-level fact rather than behavioral context. No additional behavioral details (e.g., response format, pagination, rate limits) are provided, which is acceptable given the annotations but does not exceed 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, concise sentence that provides the core purpose without any fluff or repetition. It is appropriately front-loaded and every word adds value.

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 3 parameters, no output schema, and minimal description, this is inadequate. It does not explain the return value, the meaning of 'completo', or any constraints (e.g., which parameter to provide). The lack of parameter details severely limits an agent's ability 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?

The schema description coverage is 0%, so the description bears the full responsibility for explaining parameters. It only mentions 'por CPF/CNPJ', implying both are used, but does not clarify that they are optional, their format, or the meaning of the 'completo' boolean parameter. This leaves the agent guessing about required inputs and 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 the tool returns CVM administrative sanctioning processes, and the mention of 'por CPF/CNPJ' specifies the scope. This distinguishes it from sibling compliance_cvm (the broader one) and other compliance tools, making the purpose 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 implies usage for querying CVM sanctioning processes by CPF/CNPJ, but it does not explicitly contrast with alternatives like compliance_cvm or provide exclusions. While the purpose is clear, there is no guidance on when to choose this over the general CVM tool or other compliance 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 indicate readOnlyHint=true anne intellectual, idempotentHint=true, and destructiveHint=false, meaning the agent knows it's a safe read operation. The description adds no behavioral context beyond that, such as whether name search is exact or fuzzy, whether 'completo' affects results, or any limitations (e.g., no pagination). Since annotations carry the safety profile, the description fails to enrich behavioral 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 a single, short sentence ('Busca na lista FBI Most Wanted por nome.'). It is extremely concise and front-loaded, with no fluff. Every word earns its place, though it could be slightly more informative without becoming verbose.

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 (2 params, no output schema) and the annotations that cover safety, the description is insufficient. It doesn't explain the behavior of 'completo' or any search nuances, and with 0% schema coverage, the agent lacks critical parameter semantics. The description is too minimal to fully support correct invocation, especially given the many similar sibling tools.

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 explain parameter meanings, but it only mentions searching by name. It doesn't clarify what 'NOME' expects (exact, partial, case-insensitive?) or what 'completo' (boolean) controls. The description adds minimal value over the raw schema, leaving the agent guessing.

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: searching the FBI Most Wanted list by name. It uses a specific verb ('Busca' = searches) and a resource ('lista FBI Most Wanted'), which is clear and distinguishes it from sibling tools like compliance_interpol or compliance_ofac, though it doesn't explicitly name those 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 gives no guidance on when to use this tool versus the many sibling compliance tools. It doesn't mention any specific context or exclusions. The tool name and description imply it's for FBI-related checks, but there is no explicit instruction on when this tool is appropriate versus, for example, compliance_interpol or compliance_ofac.

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 cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'por nome' search scope, but it does not disclose details about return behavior or how the optional 'completo' flag affects results.

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 one short, front-loaded sentence with no filler or redundant structured information. Every word adds relevant context about what the tool searches and how.

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?

This is an adequate baseline for a simple read-only name search, and the annotations cover side-effect safety. It is not fully complete because 'completo' is ambiguous, no output schema explains the result shape, and both parameters are optional but the behavior with empty inputs is not addressed.

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 explains that NOME is the search name, but it leaves the 'completo' boolean parameter completely unexplained, creating ambiguity about what a full/complete search means.

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 states a clear action: searching the FINCEN list by name. It names the specific target resource and the query field, making it easy to distinguish from sibling tools such as compliance_ofac or compliance_onu.

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 FINCEN list name lookups, so an agent can infer when to use it. However, it does not explicitly mention when not to use it or point to alternatives among the many sibling compliance 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 and destructiveHint=false, so the safety profile is clear. The description adds only the CPF/CNPJ query scope and the 'certidão negativa' output type; it does not disclose behaviors such as what happens when debts exist or the meaning of the completo flag.

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, short, front-loaded phrase and every word adds meaning. There is no filler, repetition, or unnecessary explanation.

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 and read-only, but the lack of an output schema and 0% parameter documentation leaves the agent with gaps: the meaning of 'completo', the expected return format, and any prerequisites are not described. The description is enough to identify the tool but not enough to invoke it with confidence beyond the basic ID inputs.

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 but only clarifies 'por CPF/CNPJ' as the identifier scope. The boolean parameter 'completo' is completely unexplained, and there is no mention of mutual exclusivity or validation constraints between CPF and CNPJ.

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 phrase 'Certidão negativa de débitos do IBAMA por CPF/CNPJ' clearly identifies the IBAMA debt certificate and the CPF/CNPJ scope, distinguishing it from the many compliance_* sibling tools. It lacks an explicit verb such as 'retrieves' or 'consult', but the intent is still unambiguous for the domain.

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 explicit guidance is given about when to use this tool versus alternative compliance tools. The only clue is the IBAMA-specific scope, which requires the agent to infer selection based on the resource name.

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 readOnly, idempotent, and non-destructive behavior. The description adds limited context: the data source (CNIA) and the nature of the records (convictions and ineligibility). It does not cover response format, empty results, or any special lookup behavior, but within annotated safety bounds this is acceptable.

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, front-loaded sentence with no fluff. Every word contributes to defining the tool's lookup scope and data source. It is appropriately 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 lookup tool with strong annotations, the description conveys the core purpose and source. However, it is incomplete regarding the optional 'completo' parameter and output expectations, and the presence of many similar sibling tools means more explicit guidance would improve completeness.

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 does clarify that CPF and CNPJ are identifiers used for searching, which adds meaning over bare string fields. However, the 'completo' boolean parameter is completely unexplained, leaving a meaningful gap in semantic 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 resource (CNIA) and the purpose: convictions for administrative improbity and ineligibility by CPF/CNPJ. It implicitly communicates a search/lookup operation and distinguishes itself from compliance siblings by naming a specific data source and subject matter, though it lacks an explicit verb.

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 guidance is given on when to use this tool vs the many compliance_* alternatives. The description only says the lookup is by CPF/CNPJ, with no exclusions, prerequisites, or hints about choosing between related 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, idempotentHint, and non-destructive behavior, so the description isn't needed for that. It adds a bit of context ('por nome') but does not disclose details like case sensitivity, fuzzy matching, or whether 'completo' controls output verbosity. Adequate but minimal for a read-only search tool.

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, short sentence that is immediately scannable and to the point. No fluff 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?

With no output schema and sparse parameter descriptions, this read-only search tool would benefit from clarifying query behavior (e.g., partial vs exact match, date format) and the meaning of 'completo'. The description is too thin to fully support an agent invoking this 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?

Schema coverage is 0% and the description does not compensate. It only mentions 'nome' generically, but parameters include NOME, SOBRENOME, DATANASCIMENTO, and completo. No explanation of field combinations, formats, or semantics is provided, failing to clarify the schema's placeholder-like names.

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 ('Busca' = searches) and resource ('lista da INTERPOL') and specifies the search criterion ('por nome'). This clearly identifies the tool's function and distinguishes it from tools targeting other lists, though it doesn't explicitly reference sibling tools or exclusions as in the high example.

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 guidance is given on when to prefer this tool over the many similar compliance_* siblings. The description does not cover use cases, limitations, or alternative tools, leaving the agent without context for tool 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the CNPJ-based lookup context but does not disclose response shape, pagination, or any other behavioral details; it does not contradict 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 a single, front-loaded phrase with no filler; every word contributes to the core meaning. It is concise but slightly under-specified, so it does not reach the top score.

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?

With no output schema and no schema-level parameter descriptions, the description should explain return values and the effect of 'completo'. It does neither, leaving an agent to guess what a successful response looks like and how to request the full result.

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 bears the burden of explaining parameters. It only clarifies that CNPJ is the lookup key, leaving the 'completo' boolean entirely unexplained and not noting whether CNPJ is required or what the default behavior is.

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 names the resource ('Acordos de leniência') and the lookup key ('por CNPJ'), which clearly distinguishes this tool from sibling compliance_* tools. It lacks an explicit verb such as 'consulta' or 'retorna', so it stops just short of the highest clarity rating.

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 phrase 'por CNPJ' implies the tool should be used when querying leniency agreements by a Brazilian CNPJ. However, it gives no explicit guidance about when to prefer this tool over the many sibling compliance registries, nor any exclusion criteria.

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 read-only and idempotent behavior. The description adds that it returns open warrants and mentions the data source (CNJ), but does not detail output format, error behavior, or side effects. Given annotations present, this is adequate but not exceptional.

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, highly concise phrase with no redundancy or unnecessary details. It is well-structured and clear for 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 no output schema, the description does not specify response format or whether multiple records are returned. It also lacks explanations for several parameters and any constraints. The sparse information leaves significant gaps for a compliance 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 description only implies CPF and NOME as query parameters via 'por CPF/nome'. It does not explain ALCUNHA, NOMEMAE, NOMEPAI, or the 'completo' flag. With zero parameter descriptions in the schema, the description fails to compensate for the majority 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 clearly identifies the tool as retrieving open arrest warrants from CNJ, specifying CPF or name as query criteria. It distinguishes this from sibling compliance tools by focusing on arrest warrants, though it uses a noun phrase rather than an explicit verb like 'search' or 'query'.

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 guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or suggest alternative tools for different filtering needs, unlike the high-scoring example.

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 only the name-based search scope but provides no additional behavioral context such as matching behavior, case sensitivity, or result limits.

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 short sentence with no filler words. It front-loads the main action and resource, making it immediately scannable and free of 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?

The tool is a simple read-only lookup with helpful annotations, so a short description is mostly acceptable. The main gap is the unexplained 'completo' parameter, which prevents the description from being fully complete for an agent deciding whether and how to 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?

With 0% schema description coverage, the description must compensate for parameter documentation. It explains NOME via 'por nome' but provides zero information about the 'completo' boolean parameter, leaving its purpose and effect entirely unclear.

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 verb 'Busca' clearly identifies a search action, and the resource 'listas de sanções OFAC (EUA)' is specific and unambiguous. The scope 'por nome' distinguishes it from sibling tools covering other sanction lists such as ONU, UE, and UK.

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 searching US OFAC sanctions by name, which is useful context. However, it does not explicitly state when to use this tool over alternatives like compliance_onu or compliance_ue, nor does it provide exclusions or prerequisites.

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 provide readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety. However, it adds no additional behavioral context beyond the schema (e.g., no mention of match behavior, authentication, rate limits, or result format). The only added value is the parameter scope 'por nome', which is more about parameters than 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 a single concise sentence, with no filler or redundant content. It is appropriately front-loaded for a simple tool, but it is so minimal that it omits parameter details. It is not verbose, but its brevity borders on under-specification rather than good structure.

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 output schema and annotations only provide safety, the description should explain the return value and parameter behavior. It does neither—only states the purpose and search field. The 'completo' parameter is undocumented, and there is no mention of how results are returned, match accuracy, or any limitations. This is incomplete for an agent to use effectively.

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 description coverage is 0%, so the description must compensate. It clarifies that NOME is the name to search, but the boolean 'completo' is left entirely unexplained. Since there is no schema description and the tool description does not mention 'completo', the agent cannot infer what the flag controls. This is a significant gap.

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 states the exact action ('Busca' – search) and the specific resource ('lista consolidada de sanções da ONU' – consolidated UN sanctions list) with the search field 'por nome'. It clearly distinguishes from sibling tools like compliance_ue or compliance_uk by naming the specific sanctions list.

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: this tool is for searching UN sanctions. However, it does not explicitly mention alternatives or exclusions. The 'por nome' clarifies the intended use case, but there is no direct statement like 'use this when you need UN sanctions' or 'do not use for EU sanctions'.

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, which align with the description's 'Verifica' (checks) wording. The description adds no behavioral detail about 'completo', invalid CPF handling, or what the result contains, but it also does not contradict 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 a single, front-loaded sentence with no filler. Every word contributes to stating the tool's purpose, making it highly 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 tool with no output schema and no parameter documentation, the description is too sparse. It does not explain what 'completo' does, what the response looks like, or how this compares to compliance_pep_parentescos, leaving important context missing for correct invocation.

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 only explains that a CPF is checked. The 'completo' parameter is completely unexplained, leaving the agent with no semantic guidance beyond its bare name. This is a significant gap.

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 ('Verifica') and names the resource ('CPF' being a PEP), making the core purpose immediately clear. It does not explicitly distinguish from sibling compliance_pep_parentescos, but the phrasing strongly implies checking the person's own PEP status.

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 the tool: to verify whether a CPF is a PEP. However, it provides no explicit guidance on when not to use it or how it relates to the many sibling compliance tools, especially compliance_pep_parentescos.

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 readOnly, idempotent, non-destructive behavior. The description adds scope (extended with relatives) but does not disclose any additional side effects or data handling beyond that.

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 with no wasted words. It is easily parsed and directly states the core function.

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 is too minimal given the lack of parameter docs and absence of output schema. It does not explain what 'completo' does, how CPF is validated, or what kind of result 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?

Both parameters (CPF and completo) have no schema descriptions, and the description does not explain their meaning or expected format. The 'completo' flag is likely crucial but left entirely unexplained.

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: checking for extended PEP status, including relatives. It distinguishes from sibling 'compliance_pep' by explicitly adding '+ parentescos'.

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 any guidance on when to use this tool versus the many sibling compliance tools. No explicit 'use when' or 'for simple PEP, use X' instructions are given.

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 covered. The description adds 'antifraude' and holder-validation context, but does not disclose return behavior, data source, or any operational constraints beyond that.

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 filler. It is concise, but it is also under-specified for a tool with four parameters and no output 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?

There is no output schema, yet the description does not explain what the validation returns. It also fails to address parameter roles, response format, or integration context, making it incomplete for an agent to confidently 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%, so the description must compensate for missing parameter meaning. It offers only 'titular' and 'chave PIX' context, which partly explains DOCUMENTO and CHAVE, but leaves TIPO and completo entirely unexplained.

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 a specific action—'valida o titular de uma chave PIX'—and the antifraud context makes it distinct from the many other compliance_* sibling tools. It identifies both the resource (PIX key holder) and the operation (validation).

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 intended use is implied by the description: use when you need to validate a PIX key holder. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or complementary 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?

The annotations already declare readOnly, non-destructive, and idempotent behavior, and the description does not contradict these. It adds no extra behavioral context (like requiring authentication or returning a boolean), but given the annotations cover the main concerns, transparency is adequate.

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 with no redundant or unnecessary details. It is perfectly sized for the information provided.

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 does not specify what the tool returns (e.g., a boolean, list, details) nor explain the 'completo' parameter. Without an output schema, this omission leaves users guessing about the tool's full behavior and expected results.

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 provides only property names with no descriptions. The description mentions 'por CNPJ/CPF' which clarifies the purpose of the two identifier parameters, but it does not explain the 'completo' parameter or clarify whether CPF, CNPJ, or both are required. This leaves significant ambiguity in parameter 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 clearly states the tool's specific purpose: checking an employer against a forced labor list using CPF/CNPJ. It is unambiguous and distinguishes itself from sibling compliance tools that target other lists.

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 explicitly mention when to use this tool versus alternative compliance tools. However, the tool name and description make it clear that it is for forced labor checks, which is sufficient context for a user familiar with the sibling tools. But since explicit alternatives or when-to-use guidance is absent, it does not fully meet the 'explicit' criterion.

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, so no contradiction exists. The description adds the 'search by name' behavior but does not disclose matching semantics, output format, limits, or the meaning of the 'completo' option.

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 filler. Every word adds meaning, making it appropriately concise for the tool's simple search 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?

With good annotations and a simple search purpose, the description covers the core intent, but it omits important context such as the 'completo' parameter semantics and any result expectations. It is adequate for basic invocation by name but not fully 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?

Schema description coverage is 0%, so the description must compensate. 'por nome' maps to the NOME parameter, but the 'completo' boolean parameter is completely unexplained, leaving the agent to guess its purpose.

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 action ('Busca'), the resource ('lista de sanções financeiras da União Europeia'), and the search method ('por nome'). It also distinguishes itself from the many sibling compliance tools by explicitly naming the EU financial sanctions list.

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 scope is implied through 'União Europeia', which tells the agent this is for EU sanctions screening. However, there is no explicit guidance on when not to use it or which alternative compliance tool should be preferred for other jurisdictions.

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, destructiveHint=false, so the agent knows this is a safe read operation. The description adds the search field (name) and the specific list, but doesn't add details about search behavior (e.g., partial matching, case sensitivity, pagination, exact name requirements). With annotations covering safety, a 3 is appropriate as the description adds some context beyond 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 one concise sentence, front-loaded with the action and resource. No wasted words, efficient and clear.

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 2 parameters, no output schema, and annotations cover safety, the description is adequate but incomplete. It explains the search key but not the 'completo' parameter or potential return behavior (e.g., details shown). For a simple lookup tool, this is a minimal viable level, but it could mention whether results include full details or just confirmation.

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 'por nome' which maps to the NOME parameter, adding some meaning. However, it does not explain the 'completo' boolean parameter, and no default values or optional behavior are described. With two parameters and one explained, this is average 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 searches the UK sanctions list (HM Treasury) by name, which specifies the verb (buscar), resource (lista de sanções do Reino Unido/HM Treasury), and the search key (por nome). It distinguishes from siblings by naming the specific list (HM Treasury), though it doesn't explicitly differentiate from other compliance_* tools, but the named resource is sufficient.

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 context (when to use it: searching UK sanctions list) but provides no explicit alternatives or exclusions. Since there are many sibling compliance_* tools, the description implies usage but doesn't name alternatives like compliance_ofac or compliance_ue. Minimal viable 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 discloses specific behavioral details beyond the annotations: it explains the two possible outcomes (all connected vs. missing credentials), including exact response fields like authenticated, pending[], and connect_url. This provides rich context for interpreting the tool's 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 concise, using two sentences to convey the primary purpose and state-dependent behavior. It is front-loaded with the main function and adds necessary detail without wasting 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 a zero-parameter tool with no output schema, the description provides adequate detail about return values in two distinct scenarios. It is complete enough for an agent to understand what the tool does and 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 zero parameters, so the baseline is 4. The description correctly focuses on behavior and return value, as there are no parameters to explain. No additional parameter semantics 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 clearly states the tool returns connection status and URLs, with specific details about the response in different states. This distinguishes it from siblings like authenticate (which performs authentication) and toolkit_info (general info), as it focuses on connection status.

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 but does not explicitly mention when to use this tool versus alternatives. However, the context is clear from the detail about authentication state, making it a valid status-check 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?

Despite annotations (readOnlyHint false, openWorldHint true), the description adds significant behavioral context: invoke runs tools even if MCP is not installed, returns connect/checkout links, requires owner/admin for writes, and distinguishes installed_in_toolkit vs installed_in_workspace. It also explains the prompt library as a separate feature. 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 long (~250 words) but densely packed with necessary information. It front-loads the core flow, then covers key behaviors, and ends with the prompt library. While concise for the complexity, it could be tightened by trimming redundant phrasing, but every sentence adds value.

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 23 parameters, no output schema, and no required fields, the description provides a comprehensive guide covering discovery, execution, installation, billing, authorization, and the prompt library. It addresses edge cases like missing credentials and empty wallet. The level of detail is appropriate 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?

Schema coverage is 0%, so the description must compensate. It explains the meaning of key parameters like action (via enum and flow), mcp_id, tool_id, arguments, and prompt-related parameters (prompt_slug, prompt_vars, etc.). However, it does not detail all 23 parameters (e.g., limit, query, message, immediate) explicitly, leaving some gaps for less common ones. The core parameters are well-covered.

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 marketplace for discovering, running, and managing MCPs. It lists the key actions (search, describe, invoke, install, etc.) and explains the core flow, distinguishing it from sibling tools like compliance checks or reporting. The verb 'marketplace' is implicit, but the description gives specific capabilities and 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?

Provides explicit guidance on when to use each action: use invoke for one-off, install for permanent, search/describe to discover, list_tools for what's callable, and subscribe/cancel for billing. It also clarifies when to avoid certain actions (prefer invoke over install for single use) and covers prerequisites like credential/wallet requirements and workspace owner/admin for writes.

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 the tool as idempotent and non-destructive, and the description adds that the conversation array is needed for reproduction—useful context. It does not disclose what happens after reporting (e.g., whether a ticket is created, where the data goes), but this is somewhat mitigated by the annotation hints. No contradiction exists.

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 well-structured sentence that front-loads the purpose and immediately provides the key usage hint. Every phrase serves a purpose, with no filler or repetition of schema-defaults.

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—three flat string parameters, no output schema—so a long description isn't necessary. However, the unexposed 'context' parameter and the lack of any mention of the return value/outcome leave small but real gaps in the overall picture.

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 does explain 'message' as the bug/feedback text and 'conversation' as an array of recent messages for reproduction, but leaves the 'context' parameter unexplained entirely. Partial compensation for a low-coverage 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 uses a specific verb ('Report') combined with a clear resource ('bug, missing feature, or feedback'), immediately distinguishing this tool from the unrelated compliance and authentication siblings. There is no ambiguity about the function—it is a user feedback/bug reporting channel.

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 is implied: use this tool when you need to report a bug, missing feature, or provide feedback. However, there is no explicit 'when not to use' or comparison to alternatives, though the sibling set is largely unrelated so confusion is unlikely.

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 annotations already declare readOnly, non-destructive, and idempotent behavior. The description adds no additional behavioral context (e.g., error handling or rate limits), but it does not contradict the annotations. Since it is a simple read-only operation, the minimal addition is acceptable.

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, using only necessary words. It provides the essential information without any unnecessary fluff 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?

Given the simplicity of the tool, the description is sufficiently complete. It does not specify the output format or structure, but for a version-checking tool this is typically not critical; the user can infer the result. The lack of output schema also imposes no additional need for explanation.

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, and the description accurately reflects that. There is no need to explain parameters because none exist; the schema already covers this.

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: showing the current MCP platform and adapter versions. It is distinct from sibling tools like toolkit_info by focusing specifically on version information.

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 when version information is needed but does not explicitly state when to prefer this tool over alternatives like toolkit_info. No when-not-to-use guidance is provided, though the simple nature makes ambiguity low.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=false, providing a strong safety profile. The description adds value by specifying exactly what data is returned (installed MCPs, status, accounts, catalog tool counts) and implies it is a read-only snapshot. This goes beyond the annotations by clarifying the content of the result, which is helpful for an agent.

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 that is front-loaded with the core action ('Returns the current toolkit state') and then lists all included details. There is no fluff, and every part of the sentence contributes to understanding the tool's function.

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 read-only tool with comprehensive annotations and no output schema, the description fully covers the tool's purpose and result. It explains what the toolkit state includes, which is all an agent needs to decide whether to invoke it. The simplicity of the tool means no additional behavioral details are 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 trivially 100% covered. Baseline for 0 params is 4, and there is nothing for the description to clarify beyond confirming no arguments are needed. The description implicitly states that by not mentioning any inputs, which is fine.

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 starts with 'Returns the current toolkit state' which is a specific verb and resource. It then enumerates exactly what is included (installed MCPs, connection status, accounts, catalog tool counts), making it immediately clear what the tool does and distinguishing it from the sibling compliance-check 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?

While no explicit 'when to use' or 'when not to use' guidance is provided, the description clearly indicates the tool is for inspecting toolkit state (a meta-informational task). Given zero parameters and its evident purpose, a user can infer it should be used when needing a health/status overview, not for performing operations. No alternative tools are mentioned, but the context is sufficient.

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