compliance_leniencia
Acordos de leniência por CNPJ.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| CNPJ | No | ||
| completo | No |
Acordos de leniência por CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CNPJ | No | ||
| completo | No |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.