Skip to main content
Glama

fiscal

by br.com.brasilnfe

Emitir NF-e ou NFC-e

nfe_emitir

Emite uma NF-e (modelo 55) ou NFC-e (modelo 65) na SEFAZ. Use modeloDocumento=55 para NF-e (B2B com destinatário CPF/CNPJ) ou modeloDocumento=65 para NFC-e (consumidor final). Retorna chave de acesso (44 dígitos), número, protocolo, status e XML/DANFE em base64. Operação síncrona (pode levar 5-30s). Use tipoAmbiente=2 (homologação) para testes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
LoteNoLote da Nota Fiscal
SerieNoSérie da nota Fiscal
CodigoNoB03 - Código numérico que compõe a Chave de Acesso. Número aleatório gerado pelo emitente para cada NF-e.
NumeroNoNúmero da nota fiscal
ClienteNoDestinatário da nota. OBRIGATÓRIO para NF-e (modelo 55). Para NFC-e (modelo 65) só é obrigatório quando IndicadorPresenca = 4 (entrega a domicílio). Quando informado para NF-e mod 55, exige: CpfCnpj, NmCliente, IndicadorIe (1/2/9), Endereco com Logradouro e UF (e CEP/Município/Bairro quando não exportação).
EntregaNo
ExportaNo
CobrancaNo
ProdutosYesItens da nota fiscal. Mínimo 1 item.
RetencoesNoRetenções federais totais da nota (IRRF, PIS/COFINS/CSLL retidos, Previdência). Gera a tag retTrib no XML.
TipoDanfeNoFormato de impressão do DANFE (tag tpImp da NF-e). Não informado = padrão atual (1-Retrato para NF-e, 4 para NFC-e). Valores: 0 - Sem geração de DANFE; 1 - DANFE normal, Retrato (padrão NF-e); 2 - DANFE normal, Paisagem; 3 - DANFE Simplificado; 4 - DANFE NFC-e (padrão NFC-e; somente modelo 65); 5 - DANFE NFC-e em mensagem eletrônica (somente modelo 65); 6 - DANFE Simplificado Tipo 2 (NT 2026.002/2026.003, Ajuste SINIEF 13/26; somente modelo 55) - NF-e de varejo em operação típica de NFC-e, impressa em bobina com QR Code. Exige operação interna (CFOP 5xxx), consumidor final, finalidade 1-Normal, saída, sem notas referenciadas e IndicadorPresenca 1, 4 ou 5.
FinalidadeYesFinalidade da emissão da NF. Valores: 1 - Normal (caso mais comum); 2 - Complementar (referenciando NF anterior em NFReferencia); 3 - Ajuste; 4 - Devolução; 5 - Nota de crédito; 6 - Nota de débito
ObservacaoNo
PagamentosNoFormas de pagamento. OBRIGATÓRIO quando Finalidade = 1 (Normal). Para finalidades 2/3/4/5/6 pode ficar vazio. Para NFC-e (mod 65) deve haver pelo menos um pagamento com FormaPagamento diferente de "90" (sem pagamento).
TpNFDebitoNoTipo de Nota de Débito. Obrigatório quando Finalidade = 6. Código SEFAZ: Valores: 1 - Transferência de créditos para Cooperativas; 2 - Anulação de Crédito por Saídas Imunes/Isentas; 3 - Débitos de notas fiscais não processadas na apuração; 4 - Multa e juros; 5 - Transferência de crédito de sucessão; 6 - Pagamento antecipado; 7 - Perda em estoque
TransporteNo
DataEmissaoNoData e Hora da saída ou de entrada da produto/serviço (Envia a data atual caso não informada)
EnviarEmailNo
TpNFCreditoNoTipo de Nota de Crédito. Obrigatório quando Finalidade = 5. Código SEFAZ: Valores: 1 - Multa e juros; 2 - Apropriação de crédito presumido de IBS sobre saldo devedor na ZFM; 3 - Retorno por recusa total na entrega ou por não localização do destinatário; 4 - Redução de valores; 5 - Transferência de crédito na sucessão; 6 - Retorno por recusa parcial na entrega
CalcularIBPTNoIndica operação com Consumidor final (NFCe de ser 1 Validar!)
NFReferenciaNoNotas fiscal de Referência
TipoAmbienteYesIdentificação do ambiente da SEFAZ. Valores: 1 - Produção (emissão REAL, com valor fiscal, irreversível); 2 - Homologação (teste, sem valor fiscal - use durante desenvolvimento e testes)
IntermediadorNoDados do intermediador/marketplace (site ou plataforma de terceiros).
JustificativaNoUtilizar quando o tipo de emissão for diferente normal
ConsumidorFinalNoIndica operação com Consumidor final (NFCe de ser 1 Validar!)
ModeloDocumentoYesCódigo do modelo do Documento Fiscal. Valores: 55 - NF-e (B2B / com destinatário CPF/CNPJ identificado); 65 - NFC-e (consumidor final / varejo)
ObservacaoFiscoNo
DataEntradaSaidaNoData e Hora da saída ou de entrada da produto/serviço
NaturezaOperacaoYesDescrição da natureza da operação (máx 60 caracteres). Exemplos: "Venda de mercadoria", "Remessa para industrialização", "Devolução de venda".
IndicadorPresencaYesIndicador de presença do comprador no estabelecimento comercial no momento da operação. Padrão sugerido para NF-e B2B = 9 (operação não presencial, outros). Para NFC-e varejo = 1 (presencial). Valores: 0 - Não se aplica; 1 - Operação presencial;; 2 - Operação não presencial, pela Internet;; 3 - Operação não presencial, Teleatendimento;; 4 - NFC-e em operação com entrega a domicílio;; 5 - Presencial fora do estabelecimento;; 9 - Operação não presencial, outros.
IdentificadorInternoNo
NFPagamentoAntecipadoNoGrupo de notas de antecipação de pagamento (gPagAntecipado - Reforma Tributária).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ErrorNoMensagem de erro da operação. Vazia ("") quando foi bem-sucedida.
AvisosNoAvisos não bloqueantes. Pode vir preenchida mesmo em emissão bem-sucedida.
ReturnNFNo
Base64XmlNo
Base64FileNo

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations carry only openWorldHint, so the description carries the behavioral disclosure burden. It discloses the synchronous nature and latency ('Operação síncrona (pode levar 5-30s)'), the SEFAZ submission, and the returned payload (chave de acesso, número, protocolo, status, XML/DANFE em base64). It also adds safe-usage context with 'tipoAmbiente=2 (homologação) para testes'. It does not elaborate on SEFAZ rejection or failure behavior, but that 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?

Four sentences, front-loaded with the core action and model selection, then return values, then operational latency, then test guidance. No filler; each sentence earns its place.

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?

For a highly complex 32-parameter tool, the description deliberately leaves details to the rich schema and output schema, while adding non-obvious operational facts: 5-30s synchronous latency, base64 XML/DANFE return, and homologation recommendation. It could have mentioned complementary or preview siblings or stressed that production emissions are fiscal acts, but the schema already flags irreversibility under TipoAmbiente.

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 around 75%, so the schema already documents most parameters in detail. The description adds light semantic value by mapping modeloDocumento to business contexts (B2B vs consumidor final) and recommending tipoAmbiente=2 for tests, but much of this repeats enum metadata already present in 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 opens with a specific verb+resource: 'Emite uma NF-e (modelo 55) ou NFC-e (modelo 65) na SEFAZ.' It clearly distinguishes the two document models and the target environment (SEFAZ), which also separates it from sibling emission tools like cte_emitir, mdfe_emitir, and nfse_emitir.

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 explicit selection guidance within the tool: 'use modeloDocumento=55 para NF-e (B2B com destinatário CPF/CNPJ) ou modeloDocumento=65 para NFC-e (consumidor final)' and 'Use tipoAmbiente=2 (homologação) para testes.' However, it never says when to prefer this tool over siblings like nfe_emitir_complementar or nfe_previsualizar, so it falls short of a 5.

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

All fiscal toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with thorough descriptions that clarify overlaps (e.g., cliente_consultar vs cadastro_consultar). Even similar operations like arquivo_baixar variants have explicit scope differences.

Naming Consistency4/5

Most tools follow a noun_verb pattern (e.g., cliente_consultar, evento_cancelar, produto_criar), but a few deviate (e.g., 'health', 'cte_desacordo'). Overall consistent enough for easy recognition.

Tool Count4/5

34 tools is high but justified given the complexity of fiscal document management across multiple document types (NF-e, NFS-e, CT-e, MDF-e, etc.) and required CRUD, events, and auxiliary operations.

Completeness4/5

The tool set covers create/read/update/delete for clients, products, and tax rules, plus emission, cancellation, correction, and status checks for various documents. Minor gaps like dedicated NFS-e cancellation are handled by generic event tools.

Resources