mcp-nfe-br

Overview Schema Source Related Servers Discussions Admin

Br Submit Cte

br__submit_cte

Submit a signed CT-e to SEFAZ for authorization and receive the protocol (nProt). Handles GZip/Base64 encoding; requires endpoint override.

Instructions

Submete um CT-e assinado à autorização SEFAZ (CTeRecepcaoSincV4, síncrono).

O payload é automaticamente compactado em GZip e codificado em Base64 antes do envio, conforme exigido pelo MOC CT-e §3.4.1 [Verified locally].

Submissão para SEFAZ é uma operação irreversível em produção e exige confirmação em duas etapas (ConfirmationGate). Define BR_CTE_READ_ONLY=1 para desabilitar esta ferramenta. Nenhuma URL de endpoint CT-e está embutida/verificada nesta versão — endpoint_override é obrigatório.

Retorna protCTe (incluindo nProt, o protocolo de autorização) em caso de sucesso, ou error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`c_uf`	Yes	Código IBGE da UF do autorizador (cUF), 2 dígitos
`tp_amb`	No	Identificação do Ambiente (tpAmb): '1' = produção, '2' = homologação	2
`cert_path`	Yes	Caminho local para o certificado ICP-Brasil A1 (.p12/.pfx)
`xml_base64`	No	XML CT-e assinado, codificado em base64.
`xml_content`	No	XML CT-e assinado (saída de br__sign_cte). Informe xml_content ou xml_base64.
`cert_password`	No	Senha do certificado A1, se houver
`endpoint_override`	Yes	URL completa do webservice CTeRecepcaoSincV4 — obrigatório, ver docstring do módulo.
`confirmation_token`	No	Token de confirmação obtido de uma chamada anterior pendente.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.2Jul 4, 2026

TDQS

A4.5/5.0

Behavior5/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 discloses GZip/Base64 handling, irreversibility in production, two-step confirmation via ConfirmationGate, the BR_CTE_READ_ONLY escape hatch, and the lack of an embedded endpoint URL. This is exactly the behavioral information an agent needs beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences front-load the main purpose and then add only high-value warnings and return information. Every sentence earns its place; no filler or 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 no annotations and 8 parameters, the description covers the critical context: synchronous operation, required endpoint override, irreversible/destructive nature, confirmation mechanism, and expected success/error outcome. The output schema handles return structure detail, so this description is complete for safe invocation.

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 100%, so the baseline is 3. The description adds some operational context, such as endpoint_override being mandatory and the payload being compressed before sending, but it does not substantially elaborate further on individual parameter meanings 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?

States a specific verb and resource: 'Submete um CT-e assinado à autorização SEFAZ' and names the exact synchronous operation (CTeRecepcaoSincV4). This clearly distinguishes it from sibling tools like generate, validate, consult, cancel, and correct CT-e.

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?

Clear context: the tool is for submitting an already-signed CT-e to SEFAZ, and it explicitly says endpoint_override is required because no URL is embedded. It does not explicitly name alternatives or exclusions, but the structured workflow (sign then submit) is strongly implied.

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