Skip to main content
Glama

Stackin

issue_invoice

Destructive

Issue a Brazilian fiscal document: NFS-e or NF-e.

This produces a legal fiscal document. Confirm the data with the user before calling when you inferred any field.

Every item needs a price: unit_price is what one unit costs and amount is the line's gross total. Send unit_price with quantity when the user quotes a price per unit, amount when they quote the line. Sending both asserts they agree and is refused if they do not.

document_type nfse is a service invoice: each item needs a description and a price, the recipient address is optional, and service_code (LC 116/2003 item.subitem) falls back to the company's fiscal profile when omitted.

document_type nfe is for goods, and the SEFAZ rejects a partial one: every item needs ncm and cfop, and recipient_address is required with street, number, neighborhood, city, state, zip_code and city_code all filled. Call validate_invoice_payload first when any of that was inferred rather than given.

Pass idempotency_key when a retry is possible: repeating the same key with the same payload replays the first answer instead of issuing a second document. Without one, a retry after a lost response issues again — another credit, another number burned, and undoing it means cancelling, which has a deadline. Nothing generates the key for you; use one per business event, not per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
numberNo
seriesNo
tax_idYes
client_nameYes
document_typeYes
idempotency_keyNo
recipient_addressNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoLocal id. Use it for reissue and for submissions, and when a document was rejected and has no key.
statusNoissued, rejected or cancelled.
protocolNoThe authorization protocol, when granted.
access_keyNoThe authorizer's key. Absent while the document is not authorized.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

The description goes beyond annotations by explaining side effects: it 'produces a legal fiscal document' and details the consequences of missing an idempotency key—another document, burned number, and cancellation deadline. This is far more transparent than the annotations alone.

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?

The description is long but densely packed with essential information, structured into logical segments (document types, validation, idempotency). Every sentence adds operational value, with no fluff or redundancy, making it efficient despite its length.

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 the complexity of Brazilian fiscal documents, the description covers all critical aspects: document type differences, validation workflow, idempotency semantics, field requirements, and even cancellation deadlines. Combined with the output schema, an agent has sufficient context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Many parameters are explained in detail, such as unit_price vs amount, service_code fallback, and recipient_address requirements for NFE. Since the schema itself has minimal descriptions (0% coverage), this description fully compensates by clarifying the meaning and relationships of key fields.

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 clearly states the tool's action: 'Issue a Brazilian fiscal document: NFS-e or NFE' and emphasizes it produces a legal document. It distinguishes between NFS-e (services) and NFE (goods), making the purpose unambiguous even without comparing to siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Extensive guidance is provided: when to confirm inferred data, when to call validate_invoice_payload, how to handle idempotency_key for retries, and specific field requirements for each document type. It also warns against partial NFE submissions, leaving little ambiguity about the correct invocation.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.