Oráculo B2R
Server Details
Brazilian tax intelligence for AI agents. Calculates Fator R (Simples Nacional), validates CNAE codes, proportionalizes first-year companies, projects future tax scenarios, and provides export compliance rules.
- 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.1/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: calculate_fator_r is specifically for computing the Fator R ratio, simulate_simples_nacional is a broader simulation, query_export_rules handles export taxation, and fetch_oracle_data retrieves general data. There is no ambiguity between them, even though two touch on Simples Nacional, their scopes are distinct.
All tool names follow a consistent verb_noun pattern in snake_case: calculate_fator_r, fetch_oracle_data, query_export_rules, simulate_simples_nacional. The convention is uniform and predictable.
With 4 tools, the set is well-scoped for the domain of Brazilian tax consultation and oracle data. Each tool serves a clear function without being too few or too many.
The tools cover the core functionalities: Fator R calculation, Simples Nacional simulation, export rules, and data retrieval. However, minor gaps exist, such as no tool for directly calculating other Simples Nacional annexes or updating tax parameters, but these are not critical for the stated purpose.
Available Tools
4 toolscalculate_fator_rCalcular Fator R (Simples Nacional)ARead-onlyIdempotentInspect
Calcula o Fator R do Simples Nacional (Art. 18, § 5º-J da LC 123/2006) com inteligência tributária avançada. Suporta validação automática de CNAE, proporcionalização de receitas/folha para empresas com menos de 12 meses de atividade, e projeções de cenários futuros de crescimento.
| Name | Required | Description | Default |
|---|---|---|---|
| cnae | No | Código CNAE principal da empresa (opcional, ex: "6201-5/01" para desenvolvimento de software) | |
| rbt12 | Yes | Receita Bruta Total acumulada nos últimos 12 meses em R$ (ex: 360000) | |
| folha12 | Yes | Folha de pagamento acumulada nos últimos 12 meses em R$ (inclui pró-labore dos sócios e salários + INSS) | |
| faturamento_mes | No | Faturamento em R$ do mês atual a ser tributado (opcional) | |
| meses_atividade | No | Quantidade de meses de atividade da empresa se tiver menos de 12 meses (opcional, ex: 6 para proporcionalizar RBT12/Folha12) | |
| projecao_crescimento_pct | No | Percentual estimado de crescimento do faturamento mensal nos próximos meses (opcional, ex: 20 para 20%) |
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It mentions automatic CNAE validation, proportionalization for <12 months, and scenario projections. However, it does not state whether it is read-only or has 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with front-loaded purpose. Additional sentences add value without fluff. Could be slightly more structured (e.g., bullet points) but is efficient.
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?
Covers input features but does not describe the output format or calculation methodology. The absence of an output schema increases the need for return value specification, which is missing.
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 100% with good descriptions. The tool description adds context for optional parameters (meses_atividade, projecao_crescimento_pct) by linking them to features (proportionalization, projections), going beyond the 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's purpose: 'Calcula o Fator R do Simples Nacional' with specific legal reference. It distinguishes from sibling tools (fetch_oracle_data, query_export_rules, simulate_simples_nacional) by focusing solely on Fator R calculation.
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 (when you need Fator R calculation) but no explicit guidance on when not to use it or comparison with sibling tools. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_oracle_dataConsultar Dados Estruturados do Oráculo B2RARead-onlyIdempotentInspect
Recupera dados estruturados do oráculo B2R. Retorna informações atualizadas sobre a categoria e chave especificadas. Use quando precisar de dados de mercado, pricing ou métricas atualizados.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Chave específica dentro da categoria (ex: "btc_usd", "saas_arpu") | |
| category | Yes | Categoria dos dados (ex: "market_data", "pricing", "metrics") |
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds 'informações atualizadas' implying freshness, but no further behavioral traits (e.g., auth, rate limits). Adequate 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?
Two sentences, front-loaded with purpose and usage guidance. 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 full schema coverage, annotations, and output schema, the description is complete for an agent to understand the tool's function and when to use it.
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 100%, so schema already documents both parameters. Description mentions 'categoria e chave' but adds no new meaning beyond the schema. Baseline 3.
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 verb 'Recupera' (retrieves) and the resource 'dados estruturados do oráculo B2R'. It distinguishes from sibling tools by focusing on data retrieval rather than calculations or simulations.
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 context with 'Use quando precisar de dados de mercado, pricing ou métricas atualizados'. Does not include exclusions or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_export_rulesRegras de Exportação de Serviços DigitaisARead-onlyIdempotentInspect
Consulta as regras brasileiras de exportação de serviços digitais. Retorna isenções fiscais (ISS, PIS, COFINS), instruções de emissão de NFS-e para exportação, regras cambiais do BCB (Resolução 561) e vedações ao uso de criptoativos no eFX. Use quando uma empresa brasileira precisa entender como tributar receitas de clientes/agentes no exterior.
| Name | Required | Description | Default |
|---|---|---|---|
| tipo | Yes | Tipo de consulta: "resumo" (visão geral rápida), "isencoes" (ISS/PIS/COFINS), "nfse" (como emitir NFS-e), "cambial" (BCB/eFX/cripto), "completo" (tudo) |
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes |
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 explains the tool returns exemptions, instructions, currency rules, and prohibitions. It implies a read-only query but does not explicitly state side effects, limitations, or prerequisites. However, for a query tool, this level of transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively convey purpose, contents, and usage context. No redundant information. The description is front-loaded with the core action and resource, followed by detailed capabilities and use case.
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 single parameter and no output schema, the description adequately explains what each query type returns and when to use the tool. It covers all necessary aspects for an agent to correctly select and invoke it.
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 100% with detailed enum descriptions. The tool description adds a slight contextual mapping (e.g., 'resumo' as quick overview) but does not significantly enhance understanding beyond the schema. Thus, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies it consults Brazilian export rules for digital services, listing specific areas like ISS/PIS/COFINS exemptions, NFS-e issuance, BCB regulations, and crypto asset restrictions. This clearly distinguishes it from sibling tools which have unrelated purposes.
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 states to use it when a Brazilian company needs to understand how to tax revenue from foreign clients/agents. While it doesn't explicitly mention when not to use or alternatives, the context is clear and the tool's specific purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_simples_nacionalSimulação do Simples Nacional (Anexo III vs V)ARead-onlyIdempotentInspect
Simulador completo do Simples Nacional para empresas de tecnologia. Compara Anexo III vs Anexo V, calcula alíquota efetiva, imposto mensal estimado, economia anual potencial e emite alertas de risco sobre o Fator R. Use para planejamento tributário de empresas no regime Simples Nacional.
| Name | Required | Description | Default |
|---|---|---|---|
| rbt12 | Yes | Receita Bruta Total acumulada nos últimos 12 meses em R$ (ex: 480000) | |
| folha12 | Yes | Folha de pagamento acumulada nos últimos 12 meses em R$ (inclui pró-labore + salários + INSS) | |
| faturamento_mes | Yes | Faturamento em R$ do mês atual a ser tributado |
Output Schema
| Name | Required | Description |
|---|---|---|
| content | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It lists outputs (comparison, calculation, alerts) but does not mention side effects, permissions, or error handling. It is moderately transparent for a simulation 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 concise with three sentences: purpose, capabilities, usage. It is front-loaded and every sentence adds value, with no unnecessary 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?
Although the description lists capabilities, it lacks details on output format since no output schema is provided. For a tool with three required parameters and no nested objects, the description is adequate but could specify return structure or error conditions.
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 100%, so each parameter is already described in the schema. The tool description adds no additional parameter details beyond what the schema provides, earning the baseline score.
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 is a complete Simples Nacional simulator for technology companies, comparing Annex III vs Annex V, calculating effective rate, monthly tax, annual savings, and issuing risk alerts on Fator R. This distinguishes it from sibling tools like calculate_fator_r, which is more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use for tax planning of companies under the Simples Nacional regime.' It does not explicitly state when not to use or mention alternatives, but the context is sufficient for an agent to select it appropriately.
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!