Agent-ready print shop in Sao Paulo: catalog, official BRL quotes per m2, shipping, PIX orders.
Scored across 6 tools
Each tool maps to a distinct step in the print-ordering workflow: catalog, quote, art requirements, lead time/shipping, order creation, and order status. There is minor overlap between cotar and consultar_prazo around shipping/freight information, but descriptions make the primary purposes separable.
Most names follow a Portuguese verb_noun pattern (consultar_prazo, consultar_requisitos_arte, criar_pedido, listar_catalogo) in consistent snake_case. Minor deviations are cotar (bare verb) and status_pedido (noun phrase), but the set remains predictable.
Six tools are well-scoped for a print-shop ordering assistant, covering discovery, quoting, requirements, fulfillment, order creation, and status without bloat. Each tool has a clear role in the purchase lifecycle.
The core customer journey is covered: browse catalog, quote, check art requirements, check lead time/shipping, create order, and track status. Gaps include no tool for changing/canceling orders or submitting artwork, but the descriptions explicitly route those cases to human support.
Prazo de produção do produto e opções de entrega/retirada em São Paulo. Informe o CEP de destino para o frete real. Passe as mesmas opcoes do pedido: um canvas esticado em chassi viaja em caixa rígida e custa muito mais frete que a impressão enrolada no tubo.
| Name | Required | Description | Default |
|---|---|---|---|
| cep | No | CEP de destino — com ele retorno as opções REAIS de frete (transportadora, preço, prazo) | |
| opcoes | No | Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo). | |
| produto | Yes | slug do produto | |
| altura_cm | No | altura em cm (melhora o cálculo do frete) | |
| largura_cm | No | largura em cm (melhora o cálculo do frete) | |
| quantidade | No | quantidade (padrão 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent read, so the description's job is to add context — and it does: CEP unlocks 'opções REAIS' of freight (implying estimates without it), and it discloses the default behavior when options are omitted (canvas ships as a rolled print, cheaper freight). That is genuine behavioral disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, and each subsequent sentence carries actionable content (CEP requirement, option fidelity, freight cost difference). The last sentence is slightly verbose but earns its place by explaining the default that drives freight cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 params, 1 required, no output schema, and annotations covering the safety profile, the description supplies the key operational facts an agent needs: CEP for real freight, option names sourced from cotar(), and the consequence of omitting options. Return-detail gaps are acceptable since the schema documents CEP's returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3, but the description adds real meaning: options must match cotar() names exactly, cannot be replaced by observacoes, and materially change both price and freight; it also explains the canvas/chassis example and the store default. This reinforces rather than merely repeats the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb/resource pair: production deadline plus delivery/pickup options for São Paulo, and mentions freight calculation from the destination CEP. It is distinguishable from cotar and criar_pedido by scope, though it never names those siblings and blurs the line with cotar's pricing role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives calling guidance ('Informe o CEP', 'Passe as mesmas opcoes do pedido'), but that is parameter instruction rather than when-to-use-this-vs-alternatives. No explicit exclusion or routing rule against cotar is provided, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna os requisitos técnicos do arquivo de impressão (formatos, resolução, cores, sangria) e como enviá-lo. Não recebe nem analisa o arquivo: só informa as regras. Use antes de criar_pedido para orientar o cliente.
| Name | Required | Description | Default |
|---|---|---|---|
| produto | No | slug do produto (opcional, para dicas específicas) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it explicitly states the tool does not receive or analyze the uploaded file, preventing an agent from assuming it validates artwork.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first enumerates the return content, the second states the non-capability and the usage trigger. Nothing is redundant and the informative part is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned categories (formatos, resolução, cores, sangria) and the delivery instructions, plus a usage trigger. An agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single optional 'produto' slug is already documented as yielding product-specific tips. The description adds no syntax, format, or default guidance beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Retorna os requisitos técnicos do arquivo de impressão') and enumerates the returned content (formatos, resolução, cores, sangria). The explicit negation 'Não recebe nem analisa o arquivo: só informa as regras' cleanly separates it from any file-processing sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use antes de criar_pedido para orientar o cliente' gives a concrete trigger and names the sibling it precedes, which is strong routing guidance. It lacks an explicit when-not (e.g., what to do after the order exists), so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cota o preço oficial de um produto. Para produtos por m² informe largura_cm e altura_cm EM CENTÍMETROS (nunca assuma a unidade — confirme com o cliente antes). Para tiragem informe quantidade. Retorna preço unitário, total, as opções/acabamentos disponíveis com o preço de cada uma e o link do produto. Para cotar COM acabamento (ex.: canvas esticado em chassi de madeira), repita a chamada passando opcoes. Não cria pedido.
| Name | Required | Description | Default |
|---|---|---|---|
| opcoes | No | Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo). | |
| produto | Yes | slug do produto (campo 'slug' do catalogo) | |
| altura_cm | No | altura em CENTÍMETROS (obrigatório p/ produtos por m²) | |
| largura_cm | No | largura em CENTÍMETROS (obrigatório p/ produtos por m²) | |
| quantidade | No | quantidade de unidades (padrão 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds value beyond them: it lists what is returned (unit price, total, options with per-option prices, product link) and warns that options change both price and freight, plus the store default when opcoes is omitted. It does not cover failure modes (invalid slug, missing dimensions), which is the remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then progressively discloses per-case parameter rules and the options workflow; every sentence carries an operational instruction. Slight redundancy with the schema's own unit and opcoes warnings keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by describing the return payload. With 5 parameters, one required, and nested-free schema, the main ambiguities an agent would hit (centimeter units, options affecting price and freight, non-order side effects) are all addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds cross-call semantics the schema only hints at: opcoes values must be names returned by a prior cotar() call and require repeating the call rather than noting the choice elsewhere. Units are restated in centimeters with a hard warning not to assume them, reinforcing rather than duplicating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Cota o preço oficial de um produto') and closes with an explicit negative scope boundary ('Não cria pedido'), which separates it cleanly from the criar_pedido sibling. An agent can identify the tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use rules per product type: width/height for m² products, quantity for tiragem, and a second call with opcoes when a finishing is desired. It also warns against assuming units and requires confirming with the client, and the 'Não cria pedido' clause implicitly routes order creation to the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria um pedido REAL na BitVisual e retorna o link da página do pedido em bitvisual.com.br, onde o cliente conclui o pagamento por PIX. Só funciona para produtos cotáveis (use cotar() antes). Pedidos até R$ 1.000 entram direto; acima disso viram orçamento com atendimento humano. Retirada GRÁTIS na loja (Vila Mariana/SP) ou ENTREGA em todo o Brasil: informe o endereço completo com CEP e o frete real entra no total. Passe em opcoes os acabamentos escolhidos (eles mudam preço e frete). ANTES de chamar, confirme com o cliente: produto, medidas em cm, quantidade, acabamento, total, nome, e-mail e WhatsApp. A produção só começa após o pagamento e o envio da arte. EFEITO COLATERAL: cria um pedido real e gera a cobrança PIX no provedor de pagamento (Mercado Pago); com CEP, cota o frete em transportadora. Não cancela nem altera pedidos — para mudar ou desistir, o cliente fala com o atendimento humano. Limite de 5 pedidos por hora por cliente.
| Name | Required | Description | Default |
|---|---|---|---|
| cep | No | CEP de ENTREGA — informe junto com endereço/numero para receber em casa; sem CEP = retirada grátis na loja | |
| nome | Yes | nome completo do cliente | |
| Yes | e-mail do cliente (recebe o pedido e acompanha o status) | ||
| agente | No | Identifique-se: nome do assistente/plataforma que está criando o pedido (ex.: ChatGPT, Claude, Gemini, Copilot). Serve para a BitVisual saber por qual canal de IA o pedido entrou. Não é dado do cliente. | |
| bairro | No | bairro de entrega | |
| cidade | No | cidade de entrega | |
| estado | No | UF de entrega, 2 letras (ex.: SP) | |
| numero | No | número do endereço de entrega | |
| opcoes | No | Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo). | |
| produto | Yes | slug do produto | |
| arte_url | No | link https do arquivo de arte, se o cliente já tiver (opcional — também pode enviar depois) | |
| endereco | No | rua/avenida de entrega (obrigatório se informou CEP) | |
| Yes | WhatsApp/telefone do cliente com DDD | ||
| altura_cm | No | altura em CENTÍMETROS (produtos por m²) | |
| largura_cm | No | largura em CENTÍMETROS (produtos por m²) | |
| quantidade | Yes | quantidade (padrão 1) | |
| complemento | No | complemento (opcional) | |
| observacoes | No | detalhes do pedido: acabamento escolhido, cores, instruções (opcional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give the generic write/open-world/non-idempotent/non-destructive profile; the description goes far beyond with the concrete side effects (real order + PIX charge at Mercado Pago, carrier shipping quote when CEP is provided), the fact it cannot cancel or alter orders, the production trigger (payment + art), and a rate limit of 5 orders/hour per client.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the return value, then layered constraints, with a clearly labeled 'EFEITO COLATERAL' block. It is dense and long, but nearly every sentence carries an actionable constraint; only the client-confirmation checklist slightly overlaps the 'opcoes' guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter, non-idempotent write tool with no output schema, the description covers the return value, side effects, prerequisites, pricing thresholds, fulfillment modes and rate limiting. An agent has what it needs to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top: CEP triggers real shipping and free pickup in Vila Mariana/SP without it, and 'opcoes' changes price and freight rather than being a free-text note. Measurements in cm are implied but not restated per field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Cria um pedido REAL na BitVisual') plus what it returns (link to the order page where the client pays via PIX). It also distinguishes itself from the sibling cotar() by declaring it only works for quotable products and requires cotar() first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites ('use cotar() antes'), an explicit pre-call checklist (confirm produto, medidas, quantidade, acabamento, total, nome, e-mail, WhatsApp), the R$ 1.000 threshold that routes to human service, and a stated alternative for changes/cancellations ('o cliente fala com o atendimento humano').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os produtos e serviços da BitVisual com modelo de preço (por m², preço fixo, por tiragem ou sob consulta), preço base, limites de medida e prazo de produção. Filtre por categoria se quiser. Só leitura: não cria nem altera nada. Produtos marcados 'sob consulta' não têm preço online — molduras, por exemplo, são sempre sob consulta.
| Name | Required | Description | Default |
|---|---|---|---|
| categoria | No | Opcional. Uma de: Canvas, Wind Banner, Comunicação Visual, Folders e Panfletos, Tags, Adesivos, Cartão de Visita, Lona, Banners, Projetos especiais |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the 'Só leitura: não cria nem altera nada' sentence is largely redundant. However, the description adds genuinely new behavioral context: items flagged 'sob consulta' carry no online price, and frames are always quote-only — a fact that changes how an agent should treat those results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned, then the optional filter, then the safety note and the 'sob consulta' caveat. The read-only sentence duplicates annotations and could be dropped, but nothing else is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single optional parameter and rich annotations mean little else is needed; the description still covers what fields come back and the important exception for quote-only products. Without an output schema the exact return shape remains unspecified, which is the only real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the categoria parameter already lists all valid values in its own description. The tool description only restates that filtering is optional, adding no syntax or semantics beyond the schema — the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list BitVisual products/services) and enumerates exactly which attributes are returned: pricing model, base price, size limits and production lead time. This is clearly distinguishable from siblings like cotar (quote) or criar_pedido (create order), which operate on the same domain but do different things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Says 'Filtre por categoria se quiser', which clarifies that filtering is optional but does not say when to reach for this tool versus cotar or consultar_prazo. Usage is implied by the resource rather than stated, and no alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta o status de um pedido existente (produção, arte, rastreio e total). Só leitura. Exige o número do pedido E o e-mail usado na compra — sem os dois não devolve nada, para não expor dados de terceiros.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | e-mail usado no pedido | ||
| numero | Yes | número do pedido (OS) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, so 'Só leitura' is redundant. What adds real value is the disclosure that the lookup is gated on a two-identifier identity match and silently returns nothing otherwise — a privacy-driven failure mode the agent cannot infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: purpose and returned fields first, then the access constraint and its rationale. Front-loaded and appropriately scoped for a two-parameter read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does name the return facets, and prerequisites plus the empty-result case are covered. A slightly richer return description (format/shape of each facet or the not-found message) would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, and the description earns a bump by explaining that the two parameters act together as an ownership check rather than as independent filters ('sem os dois não devolve nada, para não expor dados de terceiros'). It adds no format/syntax nuance (e.g. whether 'numero' is numeric OS or zero-padded).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Consulta o status de um pedido existente') and even enumerates the returned facets (produção, arte, rastreio, total), which distinguishes it from creation/quotation siblings. It stops short of naming which sibling to prefer when only one facet (e.g. prazo or requisitos de arte) is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear calling condition and a hard prerequisite: both 'numero' and 'email' must match the purchase, otherwise nothing is returned. It does not explicitly route to alternatives like consultar_prazo or consultar_requisitos_arte, so the when-not-this-tool guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
consultar_requisitos_artecriar_pedido2 fields changedInput schema / properties / cpf_cnpjRemoved value: -{
- "description": "CPF (11 dígitos) ou CNPJ (14) do cliente — OBRIGATÓRIO: usado na cobrança PIX e na nota fiscal",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "produto",
- "quantidade",
- "nome",
- "email",
- "whatsapp",
- "cpf_cnpj"
-]New value: +[
+ "produto",
+ "quantidade",
+ "nome",
+ "email",
+ "whatsapp"
+]validar_artecatalogoconsultar_prazolistar_catalogoprazocriar_pedido1 field changedInput schema / properties / agenteAdded value: +{
+ "description": "Identifique-se: nome do assistente/plataforma que está criando o pedido (ex.: ChatGPT, Claude, Gemini, Copilot). Serve para a BitVisual saber por qual canal de IA o pedido entrou. Não é dado do cliente.",
+ "type": "string"
+}cotar1 field changedInput schema / properties / opcoesAdded value: +{
+ "description": "Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}criar_pedido1 field changedInput schema / properties / opcoesAdded value: +{
+ "description": "Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}prazo1 field changedInput schema / properties / opcoesAdded value: +{
+ "description": "Opções/acabamentos escolhidos pelo cliente, pelos nomes que o cotar() devolve (ex.: [chassis_esticado] para o canvas esticado em chassi de madeira). MUITO IMPORTANTE: a opção muda o PREÇO e o FRETE — não basta escrever em observacoes. Sem informar, vale o padrão da loja (para o canvas: apenas a impressão refilada, que vai enrolada no tubo).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}catalogocotarcriar_pedidoprazostatus_pedidovalidar_artePrint shop in Spain: products, exact prices, quote requests and order status for AI assistants
Brazilian company data & sanctions screening for AI agents. Certified. Pay-per-call x402.
Brazil CNPJ, CEP, Selic/IPCA/PTAX, holidays, banks/ISPB for agents. Pay per call in USDC (x402).
Brazil's Correios for AI agents: shipping quotes (frete), tracking (rastreio) and labels (etiqueta).
Add one secure layer between your agents and this server.