brasil-mcp-essentials

Official

by brasil-mcp

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
All 22 tools target distinct concepts: each validation covers a specific Brazilian document (CPF, CNPJ, PIS, RENAVAM, CNH, título de eleitor, credit card); parsing and generation tools for boleto/PIX are unique; date utilities handle holidays and business days; lookup tools address different data sources (CEP, banks, DDD, IBGE, currency, address). No two tools overlap in purpose.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but language is mixed: 'validate_cpf', 'parse_boleto', 'generate_pix_brcode' use English verbs, while 'is_feriado_nacional', 'proximo_dia_util', 'listar_feriados' use Portuguese. 'lookup' verbs are English. This inconsistency in language could confuse an agent expecting a single language convention.
Tool Count4/5
22 tools is on the higher end but appropriate for a 'brasil-essentials' server that covers validation, parsing, generation, date utilities, and multiple lookups. Each tool serves a clear need; no tool feels superfluous. However, the count could slightly overwhelm an agent if the domain is narrower.
Completeness5/5
The tool set is remarkably comprehensive for Brazilian administrative and financial tasks: includes validation for all major national documents, boleto and PIX payment processing, holiday/business day calculations, and lookups for CEP, banks, DDD, IBGE codes, currency rates, and address by logradouro. No obvious gaps for common needs.
Average 3.6/5 across 22 of 22 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must carry the burden. It only says 'validates' without disclosing whether it returns a boolean, throws errors, or handles invalid inputs. The output schema is present but not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. While there is no wasted text, it lacks necessary details, bordering on under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, simple validation), the description is minimally adequate but fails to explain the return format or side effects. The presence of an output schema does not reduce the need for clarity on behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds the constraint of '11 digits' for the value parameter, partially compensating for the lack of schema documentation. However, it doesn't specify the expected format or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates RENAVAM, a specific Brazilian vehicle registration number, and mentions it has 11 digits. This differentiates it from sibling validation tools targeting other documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or context for usage. The description only states what it does, not when or how to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only lists qr_format options but does not disclose whether the tool has side effects, requires authentication, or is safe (e.g., read-only). This is a significant gap for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct (one sentence), but it is front-loaded with the purpose and a parameter hint. However, it sacrifices completeness for brevity, missing key details. It is not overly verbose but could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and the presence of 7 parameters with no schema coverage, the description is insufficient. It does not explain the tool's behavior, prerequisites, or return value context, even though an output schema exists. The tool is a generation tool among validation siblings, but that context is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It only explains the 'qr_format' parameter. The other six parameters (chave, nome_beneficiario, cidade, txid, valor, descricao) are not described, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a static PIX BR Code, using the verb 'gera' and specifying the resource. It distinguishes from sibling tools like 'parse_pix_brcode' which handles parsing, not generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to parse a BR code instead. No context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely states it validates the input, but does not disclose if it is a read-only operation, what constitutes a valid input (e.g., formatting allowances), or potential side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without extraneous words. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is mostly adequate but lacks details about input formatting expectations and output interpretation. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by specifying the input must be 12 digits, but it does not clarify if formatted strings (e.g., with dots) are accepted or provide additional format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates a specific document (Título de Eleitor) and notes the 12-digit format. It distinguishes from sibling validators by naming a unique Brazilian document type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like validate_cpf or validate_cnpj. The description lacks context for selection among similar validators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the Luhn algorithm and brand detection, providing some behavioral context. However, without annotations, it lacks details on error behavior, constraints, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that delivers the core purpose efficiently with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool and existence of an output schema, the description is minimally adequate but lacks input format details and usage context, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter coverage is 0%, and the description adds no guidance on the 'value' parameter format, valid inputs, or examples. The agent has no information beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates credit cards using the Luhn algorithm and detects specific brands. It effectively differentiates from sibling tools like validate_cpf and validate_cnpj.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided for when to use this tool vs alternatives. The description doesn't mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as output format, error handling, or any side effects. It simply says 'validates,' which lacks detail for a mutation-free validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (6 words) and front-loaded with the action and resource. Every word is essential; there is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with one parameter and an output schema, the description is adequate but minimal. It does not mention what the validation result looks like, but the output schema presumably covers that. Could benefit from a brief note on return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the parameter beyond the schema by specifying that the input should be an 11-digit string (PIS/PASEP/NIT). This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it validates PIS/PASEP/NIT (11 digits), which clearly identifies the resource and action. It distinguishes from sibling tools like validate_cpf and validate_cnpj by specifying a different identifier type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description only states what it does, leaving the agent to infer usage context without explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only states 'validates' without describing outcomes (e.g., returns boolean, throws error) or side effects, leaving the agent with incomplete behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant information, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format is implicitly covered. However, the description omits any mention of input validation, expected response shape, or error conditions, which is needed for a tool with no annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds the constraint '11 dígitos' (11 digits), giving some format guidance. However, it does not explain the parameter's role beyond the schema's minimal 'string' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Valida') and resource ('CNH brasileira (11 dígitos)'), clearly distinguishing it from sibling tools that validate other document types (CPF, CNPJ, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives like validate_cpf or validate_cnpj. The description is purely functional with no contextual recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions inclusive/exclusive end defaults, but fails to clarify if holidays are considered, the effect of 'uf', or edge cases like start > end. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no unnecessary words. However, its brevity sacrifices critical details, making it less useful despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no schema descriptions, and no annotations, the description is severely incomplete. It omits date format, holiday handling, error scenarios, and return value context. The presence of an output schema does not excuse missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It only implicitly references date parameters and inclusive_end default, but does not explain 'uf' or date format. Meaning added is minimal beyond what parameter titles provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts business days between two dates, specifying the inclusion of start and exclusion of end by default. It uses a specific verb ('conta') and resource ('dias úteis'), and distinct from sibling tools which are validation or lookup utilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for counting business days but does not explicitly state when to use this tool over alternatives (e.g., 'proximo_dia_util', 'listar_feriados'). No when-not-to-use or contextual prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions that UF is optional for state holidays but does not cover whether the tool is read-only, rate limits, error handling, or output format. The lack of detail left the agent with significant unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short phrases that directly state the purpose and a key constraint. Every word earns its place, and it is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters) and the presence of an output schema, the description is minimally adequate. However, it omits clarification on what 'UF' stands for (state abbreviation) and does not explain the return structure beyond what the output schema might provide. For full completeness, it should explicitly mention that 'uf' is a two-letter state code.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds meaning by specifying that 'year' is the target year and 'uf' is optional for including state holidays. However, it does not explain the expected format for 'year' (e.g., a 4-digit integer) or what 'uf' values are valid. This is an improvement over the bare schema but still incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Brazilian holidays for a year, with optional state holidays via UF. This is a specific verb (listar) and resource (feriados brasileiros) and distinguishes it from sibling tools like 'is_feriado_nacional' or 'contar_dias_uteis'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While the sibling list and tool name imply it is for listing holidays, no guidance is given on when not to use it or which sibling to prefer in specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions caching and accent-insensitivity. Lacks disclosure of what happens if no match or multiple matches, any rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with three key points. No filler, front-loaded with primary action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: purpose, accent-insensitivity, optional parameter, caching. Output schema exists so return format is not needed. Minor gap: does not mention possible multiple results for ambiguous names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. Adds meaning: nome is municipality name (accent-insensitive), uf is optional state. However, does not specify format for uf (e.g., 'SP' vs 'São Paulo') or that it returns a list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool consults IBGE codes of Brazilian municipalities by name, with accent-insensitive matching. Distinct from sibling tools that focus on validation and parsing of documents and other lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic usage context (accent-insensitive, optional state, caching) but does not specify when to use vs alternatives, which are all different, but also lacks prerequisites or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lacks details on error handling, input validation, or behavior for invalid codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading the core purpose and automatic detection, with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and existing output schema, the description is fairly complete. It clarifies the scope and automatic type detection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'value' with 0% schema coverage. The description mentions valid code lengths (44,47,48) but not the exact required format (e.g., digits only, with/without spaces).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it parses boleto bancário and arrecadação codes with automatic type detection, distinguishing it from sibling tools like parse_pix_brcode and various validators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use when you have a boleto or arrecadação code. No explicit when-not-to-use or alternatives, but sibling tools cover other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that weekends and holidays are skipped, but does not clarify behavior for input dates that are already business days (likely returns the same day, hinted by 'include_today' parameter) or specify the holiday calendar used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the main action and behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 3 parameters, the description covers the core purpose but leaves out parameter details and edge cases. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description fails to explain the 'uf' and 'include_today' parameters. The 'date' parameter is mentioned implicitly ('após uma data'), but no additional semantics are provided for the other two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retorna' (returns) and the resource 'próximo dia útil' (next business day), specifying that weekends and holidays are skipped. This distinguishes it from sibling tools like 'listar_feriados' or 'is_feriado_nacional'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing the next business day after a given date, but does not explicitly mention when not to use it or list alternatives. It relies on the agent's understanding of context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the auto-detection behavior but does not describe what happens on invalid input, return format, or error handling. Acceptable for a simple validation tool but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that conveys essential information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema exists), the description covers the basic function and auto-detection. However, it lacks details on output schema content, error cases, or edge cases, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. While it mentions 'legacy and alphanumeric' and 'auto-detect', it does not explain the expected format, provide examples, or describe any validation rules for the single 'value' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates Brazilian CNPJ, specifies both legacy (14-digit) and new alphanumeric formats, and mentions auto-detection. It effectively distinguishes from sibling tools that validate other document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for CNPJ validation through the tool name and content, but lacks explicit guidance on when to use this tool versus alternatives, or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output fields but does not disclose whether the operation is read-only, has side effects, or requires authentication. For a parse operation, behavior is mostly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences front-loading the main purpose. It avoids unnecessary words, though a slightly more structured format (e.g., listing input and output) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one parameter and an output schema, the description is fairly complete: it states the input (EMV string) and the output fields. However, it lacks examples or validation details that would fully prepare the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'value' has no description in the schema (0% coverage). The description adds that it is a 'string EMV', clarifying the input type, but lacks details on format, length, or examples. This provides basic meaning but insufficient for full understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses a Pix BR code (EMV string) and lists the returned fields: key, beneficiary, amount, txid, description. It distinguishes it from the sibling tool 'generate_pix_brcode' which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parsing Pix codes but does not explicitly state when to use it versus alternatives like 'generate_pix_brcode'. No when-not or selection guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on QR representation, output format, or restrictions (e.g., Brazilian phone number format). The message is mentioned as URL-encoded but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy, front-loaded with purpose. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so description needn't detail returns; high-level overview of generated link and QR is provided. Could be more explicit about output fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: telefone is Brazilian phone, mensagem is optional and URL-encoded, qr_format options. Falls short on specifying telefone format (e.g., country code).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a WhatsApp deeplink and optionally a QR code for Brazilian phone numbers, distinguishing it from sibling validation/lookup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, though siblings are distinct (validations, lookups). Usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions local caching for 30 days, which is a useful behavioral detail. However, it does not disclose error handling, rate limits, or what happens if the CEP is invalid or offline. For a simple lookup, the caching detail is a positive addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the main purpose. Every word adds value: service provider, online dependency, return fields, and caching. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered. The description lists most relevant fields. However, it lacks input format details and error handling. For a simple tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'cep' with 0% description coverage. The description adds that it is a Brazilian CEP but does not explain expected format (e.g., with or without hyphen, digits only). No examples or validation rules are provided, leaving the agent to guess the required format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults Brazilian CEP via ViaCEP online, lists specific return fields (logradouro, bairro, cidade, UF, IBGE code, DDD), and mentions local caching. It effectively distinguishes itself from sibling tools like lookup_endereco_cep by specifying the exact service and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Siblings like lookup_endereco_cep or lookup_ibge_municipio exist but are not differentiated. The description implies usage for CEP lookups but does not help the agent choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Accurately portrays the tool as a read-only check with no destructive behavior. No mention of rate limits or auth, but for a simple boolean check this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, front-loaded with core purpose. Efficient and no unnecessary words. Could be slightly more structured but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to mention the 'municipio' parameter. For a tool with 3 parameters, not documenting one is a notable gap. Behavior is otherwise clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description explains 'date' (format) and 'uf' (state abbreviation) but completely omits 'municipio'. This leaves one parameter undocumented, reducing usefulness for AI agent invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool verifies if a given date (YYYY-MM-DD) is a Brazilian holiday, with optional UF for state holidays. Distinct from siblings like listar_feriados (lists holidays) and proximo_dia_util (next business day).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies when to use: check a single date for holiday status. Mentions optional UF for state-specific holidays, guiding parameter usage. Lacks explicit exclusions or alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'online' and 'Cacheado 7 dias', adding caching and network dependency details. However, it does not disclose error behavior, authentication needs, or idempotency, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences, each adding essential information: purpose, coverage, and caching. No wasted words; the key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the input semantics, source, and caching policy. It does not describe output, but the output schema handles that. It is mostly complete, though missing error context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'codigo' parameter, but the description adds 'código FEBRABAN (3 dígitos)' and 'Cobre 200+ bancos', clarifying the format and scope. This compensates well for the schema deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Consulta banco brasileiro por código FEBRABAN (3 dígitos)', clearly defining the action (consult), resource (Brazilian bank), and unique identifier (Febraban code). This distinguishes it from sibling tools like CEP lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. While the name and context imply it is for bank code lookups, explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the validation algorithm (Módulo 11) and rejection of repeated sequences, which are critical behaviors. However, it does not indicate whether input accepts formatted strings (e.g., with dots/dashes) or only digits, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences covering the core purpose, algorithm, and a key rule. No fluff, every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema existing), the description is fairly complete. It covers what the tool does and how it validates. Could mention edge cases or formatting, but overall sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'value' has 0% schema description coverage. The description adds that the input should be an 11-digit CPF, but doesn't clarify expected format (e.g., with/without punctuation) or provide details beyond the algorithm context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates Brazilian CPF, specifies length (11 digits), algorithm (Módulo 11), and rejection of repeated sequences. This is distinct from sibling tools like validate_cnpj or validate_pis, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for CPF validation but provides no explicit guidance on when to use this tool versus alternatives (e.g., validate_cnpj for companies). No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it is online and cached, but lacks details on rate limits, authentication, handling of invalid DDDs, or whether it requires internet connectivity. The caching info is useful but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First states purpose, second adds caching detail. No extraneous words. Efficiently communicates core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the main purpose and a performance characteristic (caching). Lacks mention of error conditions or return format, but output schema fills some gaps. Adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameter descriptions (0% coverage). The description adds that DDD must be a 2-digit code, which gives meaning beyond the schema's string type. This helps the agent format the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Consulta UF e lista de municípios por código DDD' — verb (Consulta) and resource (UF and municipalities by DDD). Distinguishes from sibling tools like lookup_cep and lookup_ibge_municipio which serve different lookup purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies online usage via BrasilAPI and mentions 90-day caching, which helps in deciding when to call. However, does not explicitly state when not to use or compare with alternatives. Given the tool's specificity, it's still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses use of external service (ViaCEP), partial matching on logradouro, and 30-day caching. Does not cover rate limits or error handling, but adequate for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no redundant words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Tool is simple; description covers all necessary aspects: inputs, external dependency, caching, partial matching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions). Description mentions parameters but does not specify format (e.g., uf abbreviation or full name, cidade format). Partial match hint is helpful but insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches for CEPs by address using ViaCEP, specifies inputs (UF, cidade, logradouro), and mentions caching and partial matching. Differentiates from sibling lookup_cep which does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Context is clear: use when you need to find CEPs from an address. Does not explicitly state when not to use or mention alternatives, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses caching behavior (1h for recent, 1 year for historical) and default date, but does not mention rate limits, authentication, or error handling. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, each adding value: query action, currency list, optional date, caching policy. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers essential aspects: what it does, supported parameters with defaults, and caching behavior. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains 'moeda' by listing supported currencies and clarifies 'data_cotacao' as optional with default today. This adds significant meaning beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries PTAX BRL exchange rates via the Central Bank, lists supported currencies, and specifies optional date parameter. This distinguishes it from sibling tools that focus on document validation or other lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (currency quote lookup) but lacks explicit when-not-to-use or alternative guidance. However, sibling tools are sufficiently different to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns formatted values and types, implying read-only behavior. It could be more explicit about error handling or idempotency, but the given information is largely sufficient for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences that front-load the purpose and then detail the behavior. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single input parameter and an output schema (not shown), the description covers input expectations, output fields, and accepted formats fully. It is complete for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a 'value' string parameter with 0% description coverage. The description compensates by explaining that the value should be a Brazilian phone number, accepted formats, and the output fields, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates and formats Brazilian phone numbers, specifying mobile (11 digits) and landline (10 digits) cases, and details accepted formats (with/without +55, any mask). This distinguishes it clearly from sibling tools like validate_cpf or validate_cnpj, which handle different identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Though the sibling tools are for different validation tasks, implying use for phone numbers, the description does not explicitly state when to use this tool or provide exclusions or alternatives. It lacks guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![essentials MCP server](https://glama.ai/mcp/servers/brasil-mcp/essentials/badges/card.svg)](https://glama.ai/mcp/servers/brasil-mcp/essentials)

Score Badge

Copy to your README.md:

[![essentials MCP server](https://glama.ai/mcp/servers/brasil-mcp/essentials/badges/score.svg)](https://glama.ai/mcp/servers/brasil-mcp/essentials)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brasil-mcp/essentials'

If you have feedback or need assistance with the MCP directory API, please join our Discord server