Skip to main content
Glama

fiscal

by br.com.brasilnfe

Pré-visualizar DANFE

nfe_previsualizar
Read-onlyIdempotent

Gera o DANFE em PDF como pré-visualização, sem enviar para a SEFAZ. Útil para conferência visual antes de emitir.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cteNoCT-e (modelo 57/67). Usado quando TipoEnvio = 1. Gera o DACTE/XML de pré-visualização.
dceNoDC-e (modelo 99). Usado quando TipoEnvio = 1. Gera o DACE/XML de pré-visualização.
mdfeNoMDF-e (modelo 58). Usado quando TipoEnvio = 1. Gera o DAMDFE/XML de pré-visualização.
nfseNoNFS-e. Usado quando TipoEnvio = 1. Gera o DANFSe/XML de pré-visualização (sem validade jurídica).
Base64XmlNo
TipoEnvioNoTipo do envio no qual será convertido para o tipo do arquivo informado (Padrão - 0) Valores: 0 - Base64 contendo as informações do XML; 1 - Objeto contendo as informações das notas fiscais
notaFiscalNoNF-e / NFC-e (modelo 55/65). Usado quando TipoEnvio = 1. Gera o DANFE/XML de pré-visualização.
TipoArquivoNoTipo do arquivo que deseja pré-visualizar (Padrão - 0) Valores: 0 - XML; 1 - PDF
mostrarTarjaPreVisualizacaoNoMostrar tarja "SEM VALOR FISCAL - PRÉ-VISUALIZAÇÃO" (Padrão - Verdadeiro) Somente para o tipo de arquivo PDF e se um dos serviços de emissão estiver ativo para a empresa

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.
StatusNo
Base64FileNo

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds one meaningful behavioral fact beyond annotations: no submission to SEFAZ, which confirms no fiscal side effect. It doesn't disclose whether validation rules still apply or that an XML preview option exists (TipoArquivo=0).

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 zero filler. The core function ('sem enviar para a SEFAZ') is front-loaded and the usage hint follows immediately. Every word earns its place.

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 tool accepting 9 parameters spanning five distinct tax document types, a two-sentence description is thin: it omits that CT-e, DC-e, MDF-e and NFS-e previews are also supported and that XML preview is available. The output schema and the per-object parameter descriptions ('Gera o DACTE/XML de pré-visualização') partially compensate, keeping this at 3 rather than lower.

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 89%, well above the 80% threshold, so the baseline 3 applies and the description need not restate parameter formats. The description adds no parameter-level meaning beyond hinting at PDF output, which the schema's TipoArquivo enum already documents.

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 states a specific verb (Gera), resource (DANFE em PDF), and the distinguishing trait 'sem enviar para a SEFAZ', which separates it from the emit siblings like nfe_emitir. However, it under-scopes the tool: the schema supports preview of five document types (NF-e/DANFE, CT-e/DACTE, DC-e/DACE, MDF-e/DAMDFE, NFS-e/DANFSe) and XML output too, yet the description mentions only DANFE em PDF.

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?

'Útil para conferência visual antes de emitir' gives a clear usage context — use it before actual emission for visual inspection. It implicitly contrasts with the emit tools via 'sem enviar para a SEFAZ', but never explicitly names an alternative tool (e.g., nfe_emitir) or states when not to use it.

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