Skip to main content
Glama
Vestuário MCP
by nilsond

adicionar_ao_carrinho

Adds a product in a chosen size to a customer cart and reserves stock units, reducing availability until order completion or item removal. Re-adding same product and size increases quantity.

Instructions

Adiciona um item ao carrinho do cliente e RESERVA as unidades no estoque.

A reserva diminui a disponibilidade para outros clientes até o pedido ser finalizado ou o item ser removido. Adicionar de novo o mesmo produto e tamanho soma as quantidades.

Args: session_id: identificador do carrinho do cliente. produto_id: ID do produto. quantidade: unidades a adicionar (> 0). tamanho: P, M, G ou GG.

Returns: Mensagem de confirmação e o carrinho atualizado com o total.

Erros: Produto não encontrado; tamanho inválido ou indisponível para o produto; quantidade <= 0; estoque insuficiente (a mensagem informa quantas unidades estão disponíveis).

Input Schema

NameRequiredDescriptionDefault
tamanhoYesTamanho da peça: P, M, G ou GG.
produto_idYesID numérico do produto, obtido em listar_produtos.
quantidadeYesQuantidade de unidades, inteiro maior que zero.
session_idYesIdentificador do carrinho do cliente, ex.: 'demo'. Use o mesmo valor em toda a compra.

Output Schema

NameRequiredDescriptionDefault
carrinhoYes
mensagemYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (non-readOnly, non-idempotent), it discloses the real consequence: reserved units reduce availability for other customers until checkout or removal. The re-add accumulation rule crisply explains why the call is not idempotent, and the error list names the insufficient-stock failure with the number of available units returned.

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?

The first sentence front-loads the action and its side effect; the Args/Returns/Erros blocks are scannable and each line carries information. Slightly long for a four-parameter tool, and the Returns block is partly redundant with the output schema.

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?

Covers what the call does, its side effect on shared stock, the accumulation rule, and every documented failure mode with what the error message contains. With an output schema present, the brief Returns line is sufficient rather than a gap.

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 earns one more by tying parameters to behavior — quantidade must be > 0, tamanho restricted to P/M/G/GG, and the same produto_id+tamanho pair merges into an existing line rather than creating a new one, which changes how an agent should call it repeatedly.

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 ('Adiciona um item ao carrinho') plus the side effect ('RESERVA as unidades no estoque'), and the sibling set makes the add-vs-remove distinction obvious. An agent can tell immediately this is the cart-write path, not a read like ver_carrinho or verificar_estoque.

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

Usage Guidelines4/5

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

Explains the operational consequence of reserving stock and that the same product+size accumulates quantity, and implies reversal via 'até o pedido ser finalizado ou o item ser removido'. It does not explicitly point at verificar_estoque as a pre-check or name remover_do_carrinho as the undo path, so a small inference remains.

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