BrazilMCP
Server Details
Brazilian company data (CNPJ): registry lookup, sanctions screening and KYB dossier, paid via x402
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 3 of 3 tools scored.
Each tool targets a distinct aspect of Brazilian company due diligence: basic lookup, aggregated dossier, and sanctions screening. There is no functional overlap, and the descriptions clearly differentiate them.
All tool names follow a consistent 'company_<noun>' pattern, with the noun indicating the specific operation (dossier, lookup, sanctions). This makes the set predictable and easy to navigate.
With three tools, the server covers the core due diligence workflow (lookup, dossier, sanctions) without redundancy. The count is well-scoped for the domain.
The tool set provides a complete lifecycle for Brazilian company due diligence: basic registry data, aggregated dossier from multiple sources, and sanctions screening. No obvious gaps given the stated purpose.
Available Tools
3 toolscompany_dossierAInspect
Build an aggregated due-diligence dossier on a Brazilian company by CNPJ (the 14-digit Brazilian company tax ID, punctuation optional).
One call aggregates multiple official government sources into a single structured report: full registry record from Receita Federal (status, legal name, activities, address, partners/QSA); lawsuits metadata from DJEN/CNJ judicial communications (matched by party name — coverage and methodology declared in the payload); public procurement contracts from PNCP (Brazil's national procurement portal); sanctions screening across 5 federal lists (CEIS, CNEP, CEPIM, leniency agreements and the MTE forced-labor register); and derived risk flags (inactive company, active sanction, recently opened, high lawsuit count). Sections are independent and degrade gracefully: if a source is down its section is marked unavailable, never a total error.
Replaces an analyst-hour of manual checks across Brazilian government portals. Useful for KYB (know your business), vendor and supplier due diligence, counterparty risk, credit analysis, AML/compliance screening, and M&A research on companies in Brazil.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A CNPJ (14-digit Brazilian company tax ID, punctuation optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses that it aggregates public data, that sections degrade gracefully, and that it is a read-only operation. It mentions coverage and methodology in the payload, ensuring 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 thorough but efficient, front-loading the core purpose and use cases. It could be slightly more concise, but the level of detail justifies 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 low complexity (1 parameter, no output schema), the description is complete: it explains all sections, error handling, and intended use cases, making it self-contained for selection and 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?
The schema covers 100% of parameters, and the description adds meaning by specifying the CNPJ format and that punctuation is optional, aiding correct input.
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 it builds an aggregated due-diligence dossier using multiple official government sources, listing specific data types and use cases. It distinguishes itself from siblings 'company_lookup' and 'company_sanctions' by being a comprehensive report.
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 lists use cases like KYB, vendor due diligence, and AML screening, and implies it replaces manual checks. It does not explicitly state when not to use it or when to prefer siblings, but the sibling names suggest they are for specific queries, giving context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_lookupAInspect
Look up a Brazilian company in the official government registry by CNPJ or company name.
Returns the full registration record from the Receita Federal (Brazil's federal tax authority) CNPJ database: registration status (active, suspended, closed), legal name (razão social), trade name (nome fantasia), head office or branch, opening date, legal nature, company size, share capital, main and secondary economic activities (CNAE codes with descriptions), full address with IBGE city code, tax regime (Simples Nacional / MEI), and the partners and shareholders board (QSA) as registered.
Input: a CNPJ — the 14-digit Brazilian company tax ID, punctuation optional — or a company name, resolved via full-text search over legal and trade names. A CNPJ that does not exist returns result_status "not_found". Useful for KYB (know your business), due diligence, supplier and vendor verification, credit analysis, B2B prospecting, and compliance checks on companies in Brazil. Registry data is refreshed monthly from official open data; the response carries its source reference date.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A CNPJ (14-digit Brazilian company tax ID, punctuation optional) or a company name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses search behavior (CNPJ vs name), return fields, 'not_found' status for invalid CNPJ, data refresh frequency, and source date. Lacks disclosure on rate limits or auth, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with purpose first, then return fields, then input details, then use cases. Slightly verbose but all sentences add value; no 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?
No output schema, so description must explain return values. It lists all major fields (legal name, status, activities, address, partners) and notes refresh schedule. Complete for a lookup tool with one 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?
Schema describes query parameter simply; description adds that company names trigger full-text search and invalid CNPJs return 'not_found'. This extra context enriches parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up Brazilian companies by CNPJ or name, specifying the resource (Receita Federal registry) and action. It lists many return fields, distinguishing it from sibling tools like company_sanctions.
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 mentions use cases like KYB and due diligence but does not explicitly say when to use this tool over siblings or when not to use it. Usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
company_sanctionsAInspect
Screen a Brazilian company for sanctions and debarment by CNPJ (the 14-digit Brazilian company tax ID, punctuation optional).
One call checks 5 federal sanction lists: CEIS (companies debarred from public contracting), CNEP (penalties under the anti-corruption law), CEPIM (non-profits barred from federal agreements), Acordos de Leniência (leniency agreements with enforcement status) and the MTE forced-labor employers register ("Lista Suja" do trabalho escravo). Returns each matching entry with list, sanction type, sanctioning body and validity dates, plus an is_currently_sanctioned verdict, the lists checked and any list that was unavailable — sources and reference dates declared.
The Brazilian complement that global OFAC/EU/UK/UN and PEP screens miss. Useful for KYB (know your business), AML/compliance screening, supplier and vendor onboarding, procurement eligibility checks and counterparty risk on companies in Brazil.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A CNPJ (14-digit Brazilian company tax ID, punctuation optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states the operation is read-only screening and details the 5 federal sanction lists checked, the return values (matching entries with list, sanction type, body, dates, is_currently_sanctioned verdict), and notes unavailable lists and reference dates. No side effects or auth needs are mentioned, but the description is sufficiently transparent for a screening 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?
The description is structured into three clear sentences: purpose, details of what is checked and returned, and use cases. It is front-loaded with the core action. While slightly wordy, every sentence adds value without 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?
Given no output schema, the description adequately explains return values (matching entries, verdict, lists checked, unavailable lists, sources, reference dates). It covers the tool's scope (5 Brazilian sanction lists) and practical use. It does not explicitly cover error cases or behavior for invalid CNPJ, but overall completeness is high for a screening 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 input schema has 100% coverage with a single parameter described as 'A CNPJ (14-digit Brazilian company tax ID, punctuation optional)'. The description adds value by explaining the parameter's purpose ('Screen a Brazilian company for sanctions and debarment by CNPJ') and the format (14-digit, punctuation optional), going beyond the schema's minimal description.
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 'Screen' and clearly identifies the resource 'Brazilian company for sanctions and debarment by CNPJ'. It distinguishes itself from sibling tools 'company_dossier' and 'company_lookup' by positioning itself as the 'Brazilian complement that global OFAC/EU/UK/UN and PEP screens miss', making its unique purpose explicit.
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 explicitly lists use cases: 'KYB (know your business), AML/compliance screening, supplier and vendor onboarding, procurement eligibility checks and counterparty risk on companies in Brazil'. However, it does not explicitly state when not to use it or mention alternatives like sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!