Skip to main content
Glama

Fulfiller — print catalogue & quotes

Lire un panier

get_cart
Read-only

Renvoie le panier tel que FIGÉ à l’ajout : aucune re-cotation à la lecture. pricedAt par ligne et expiresAt donnent l’âge des prix — au-delà, re-cotez avec quote_product. Sert à RELIRE un panier existant (plus tard dans la conversation, ou quand l’utilisateur demande à le revoir) : inutile juste après create_cart ou update_cart, qui renvoient déjà le panier complet.

Input Schema

NameRequiredDescriptionDefault
cartIdYesIdentifiant du panier (UUID) rendu par create_cart. C’est une CAPACITÉ : qui le détient accède au panier — ne le publiez pas hors de la conversation qui l’a créé.
displayNoAfficher la carte du panier à l’utilisateur, dans les clients qui affichent les interfaces MCP Apps. `false` pour un appel intermédiaire qu’il n’a pas besoin de voir (vérifier avant de répondre) ; omis ou `true` dès qu’il doit voir le résultat. Sans effet sur le résultat lui-même.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / display
      Added value: +{
      +  "description": "Afficher la carte du panier à l’utilisateur, dans les clients qui affichent les interfaces MCP Apps. `false` pour un appel intermédiaire qu’il n’a pas besoin de voir (vérifier avant de répondre) ; omis ou `true` dès qu’il doit voir le résultat. Sans effet sur le résultat lui-même.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/destructiveHint=false, but the description adds non-obvious behavior: the cart is frozen at add time with no re-quotation, and pricedAt/expiresAt signal price age. It does not cover failure modes (invalid cartId, hard-expired cart), so it is strong but not exhaustive.

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?

Dense but front-loaded: behavior (frozen prices) first, then routing guidance. Every clause carries information, though the second sentence packs several distinct ideas together, which costs a little readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully characterizes the return content (per-line pricedAt, expiresAt) and the read semantics. It omits error/edge behavior for invalid or fully expired carts, so it is near-complete rather than complete.

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

Parameters3/5

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

Schema description coverage is 100%, so cartId (capability/UUID) and display (UI card toggle) are already fully documented in the schema. The description adds no further parameter-level meaning, matching the baseline for full schema coverage.

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?

Starts with a specific verb+resource ('Renvoie le panier') and immediately scopes it as a read of a previously frozen cart. It explicitly distinguishes itself from create_cart and update_cart, so the agent can separate it from siblings without opening schemas.

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 explicit when-to-use ('plus tard dans la conversation, ou quand l’utilisateur demande à le revoir'), explicit when-not ('inutile juste après create_cart ou update_cart'), and names the alternative for stale prices ('re-cotez avec quote_product'). Nothing is left to inference.

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.

Resources