Skip to main content
Glama
Sign In

bitvisual-mcp

by br.com.bitvisual
OverviewDiscussionsAdmin

Cotação de preço real

cotar
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
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 (campo 'slug' do catalogo)
altura_cmNoaltura em CENTÍMETROS (obrigatório p/ produtos por m²)
largura_cmNolargura em CENTÍMETROS (obrigatório p/ produtos por m²)
quantidadeNoquantidade de unidades (padrão 1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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