Skip to main content
Glama

Gerar etiqueta (Correios)

generate_label
Destructive

Create a Correios pré-postagem and generate its shipping label (etiqueta) as a PDF. Returns the tracking code and a clickable link to the label PDF — share that link with the merchant/customer in chat so they can open/print it (it works even if Correios is still rendering). Supply invoiceKey for NF-e or declaredItems for DC-e. Requires the store's own authenticated Correios contract. Never use this tool to retry an uncertain emission or recover a PDF; use diagnose_label_issue and recover_label_pdf when available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
senderYesRemetente (sender / store).
recipientYesDestinatário (recipient / customer).
dimensionsNoPackage dimensions in centimeters. Optional: when omitted, the store's own registered packaging box is used if it has exactly one; ask the merchant for dimensions when the store has none or more than one box registered (the call fails with reason dimensions_required_no_box / dimensions_required_multiple_boxes).
instanceIdNoMerchant/store id. Ignored on authenticated servers (the merchant comes from the API key); used only on local/unauthenticated servers.
invoiceKeyNoComplete NF-e access key (44 digits). Spaces, dots, hyphens and slashes are ignored. When supplied, emits with NF-e instead of DC-e; never invent or complete missing digits.
serviceCodeYesCorreios product code, e.g. '03220' (SEDEX) or '03298' (PAC).
weightGramsYesPackage weight in grams.
objectFormatNoObject format: '1' envelope, '2' package/box (default), '3' roll.
declaredItemsNoDeclaração de conteúdo — required when invoiceKey is omitted (at least one item). Ignored when a valid NF-e is supplied.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy the label wasn't (fully) produced.
statusNoCorreios pré-postagem status.
actionUrlNoWhen set (e.g. reason=subscription_required), send the merchant here to finish setup.
labelPdfUrlNoClickable link to download the label PDF — share this with the merchant/customer in chat. Works even before the PDF finishes rendering (it waits and streams it once ready).
supportCodeNoCódigo de atendimento para diagnose_label_issue.
trackingCodeNoCódigo de rastreamento, once the pré-postagem exists.
prepostagemIdNoCorreios pré-postagem id. Pass it to get_label_pdf to fetch the PDF later if it wasn't ready.
labelPdfBase64NoBase64-encoded label PDF, once ready.
recoveryActionNo
journalUnavailableNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructive=true, idempotent=false and openWorld=true; the description adds genuinely new context, namely that a store-authenticated Correios contract is required, that the returned PDF link works before rendering completes, and that re-emission must not be attempted on an uncertain result. It stops short of describing failure modes or downstream side effects of an emission.

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

Conciseness4/5

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

It is front-loaded with the action and the returned artifacts, then layered with parameter guidance, auth requirement, and exclusions. Four sentences carry real information each, though the closing exclusion sentence is dense and slightly long.

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?

For a 9-parameter nested mutation tool with an output schema, the description covers purpose, auth prerequisite, return handoff to the merchant, parameter selection, and the retry/recovery boundary. Nothing essential to correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the per-parameter baseline is 3; the description adds the cross-parameter rule that NF-e (invoiceKey) and DC-e (declaredItems) are the two mutually exclusive declaration paths. The dimensions fallback behavior is left to the schema, but the either/or synthesis is useful beyond the individual field texts.

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 states a specific verb+resource pair ('Create a Correios pré-postagem and generate its shipping label (etiqueta) as a PDF') and immediately names the artifacts produced. It is clearly distinguishable from siblings like get_label_pdf and recover_label_pdf, which handle retrieval rather than creation.

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?

It gives explicit when-not guidance ('Never use this tool to retry an uncertain emission or recover a PDF') and routes the agent to the correct alternatives (diagnose_label_issue, recover_label_pdf). It also supplies the condition for choosing between invoiceKey and declaredItems.

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.