Skip to main content
Glama
Sign In

bitvisual-mcp

by br.com.bitvisual
OverviewDiscussionsAdmin

Criar pedido (pagamento PIX)

criar_pedido

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.

Input Schema

NameRequiredDescriptionDefault
cepNoCEP de ENTREGA — informe junto com endereço/numero para receber em casa; sem CEP = retirada grátis na loja
nomeYesnome completo do cliente
emailYese-mail do cliente (recebe o pedido e acompanha o status)
agenteNoIdentifique-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.
bairroNobairro de entrega
cidadeNocidade de entrega
estadoNoUF de entrega, 2 letras (ex.: SP)
numeroNonúmero do endereço de entrega
opcoesNoOpçõ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).
produtoYesslug do produto
arte_urlNolink https do arquivo de arte, se o cliente já tiver (opcional — também pode enviar depois)
enderecoNorua/avenida de entrega (obrigatório se informou CEP)
whatsappYesWhatsApp/telefone do cliente com DDD
altura_cmNoaltura em CENTÍMETROS (produtos por m²)
largura_cmNolargura em CENTÍMETROS (produtos por m²)
quantidadeYesquantidade (padrão 1)
complementoNocomplemento (opcional)
observacoesNodetalhes do pedido: acabamento escolhido, cores, instruções (opcional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / cpf_cnpj
      Removed value: -{
-  "description": "CPF (11 dígitos) ou CNPJ (14) do cliente — OBRIGATÓRIO: usado na cobrança PIX e na nota fiscal",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "produto",
-  "quantidade",
-  "nome",
-  "email",
-  "whatsapp",
-  "cpf_cnpj"
-]New value: +[
+  "produto",
+  "quantidade",
+  "nome",
+  "email",
+  "whatsapp"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / agente
      Added 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"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / opcoes
      Added 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"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All bitvisual-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources