Skip to main content
Glama

consultar_pedido

Retrieves an order by number (e.g., P-0001) with status, items, total, and change history; customers can only view their own orders.

Instructions

Devuelve un pedido por su número (formato P-0001): estado actual, ítems, total e historial de cambios. Un cliente solo puede consultar sus propios pedidos; si el número es de otro, responde que no existe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "numero": "<numero>"
    },
    "name": "consultar_pedido"
  }
}

Input Schema

NameRequiredDescriptionDefault
numeroYesNúmero de pedido, por ejemplo "P-0002".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description must carry the behavioral burden and does substantially: it discloses the authorization scoping and, notably, that unauthorized numbers are reported as non-existent rather than as a permission error — critical for interpreting results. It omits error behavior for genuinely unknown numbers, rate limits, and whether history is complete or truncated.

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?

Two tight sentences with the resource and return contents front-loaded, then the access constraint. No filler, though the parenthetical format hint duplicates the schema and could be dropped.

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

Completeness3/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 does enumerate the returned fields and the masking behavior, which covers most of what an agent needs. It still leaves open what happens for a number that never existed versus one owned by another customer, and whether the change history is bounded.

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 coverage is 100% and the single parameter already documents the 'P-0002' example. The description's 'formato P-0001' restates that without adding validation rules or edge cases, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource (devuelve un pedido) plus the lookup key and the returned fields (estado, ítems, total, historial). It is implicitly distinct from listar_pedidos by being a single-record fetch by number, but it never names or contrasts with a sibling tool.

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

Usage Guidelines3/5

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

Gives a real usage rule — a customer may only consult their own orders — which tells the agent who can call it and with which numbers. It does not address when to prefer this over listar_pedidos or resumen, so guidance on alternatives is only implied by the by-number scope.

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