Directorio Systema

Pedir comida/productos (efectivo) / Order food (cash)

pedir_comida

ES: Crea un pedido REAL de comida/productos que se paga EN EFECTIVO al recoger (pickup) o al recibir (delivery). Mandá los nombres de los ítems tal como salen en ver_negocio; el servidor resuelve los productos reales y nunca inventa precios. Delivery exige direccion y que el negocio lo tenga habilitado. / EN: Places a REAL food/product order paid IN CASH on pickup or on delivery. Send item names as shown by ver_negocio; the server resolves the real products and never invents prices. Delivery requires an address and the business having delivery enabled.

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": {
      "slug": "<slug>",
      "items": "<items>",
      "entrega": "<entrega>",
      "nombre": "<nombre>",
      "telefono": "<telefono>"
    },
    "name": "pedir_comida"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	Slug del negocio (de buscar_negocios) / Business slug (from buscar_negocios)
`items`	Yes
`notas`	No	Notas de entrega (solo aplican a delivery)
`nombre`	Yes	Nombre del cliente / Customer name
`entrega`	Yes	pickup = recoger en el local (paga en efectivo al recoger); delivery = a domicilio (paga en efectivo al recibir)
`telefono`	Yes	Teléfono del cliente / Customer phone
`direccion`	No	Dirección completa de entrega (obligatoria si entrega=delivery)

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of disclosing behavior. It transparently states the order is real, payment is cash upon pickup/delivery, and that the server resolves actual products and never invents prices. It also mentions delivery conditions. However, it omits potential side effects like cancellation or order confirmation details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is bilingual but still brief and to the point. It packs essential information into two short paragraphs without redundancy. Every sentence adds value, covering the action, payment method, key input requirements, and delivery constraints.

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?

Given there is no output schema, the description does not explain what the tool returns (e.g., confirmation, order ID) or how errors are handled (e.g., item unavailable). While it sets expectations for the input and payment, it lacks information about the response or failure modes, leaving some incompleteness for a full user interaction.

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?

The schema provides descriptions for most parameters (86% coverage), and the tool description adds practical guidance on what values to pass (e.g., item names from ver_negocio, cash payment, delivery address requirement). The 'cantidad' parameter lacks a description in the schema, but the description doesn't clarify it either, so a minor gap exists.

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?

The description clearly states the tool's function: placing a real food/product order paid in cash, with explicit pickup or delivery options. It distinguishes itself from sibling tools like reservations or appointments by focusing on food ordering.

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?

The description implicitly indicates when to use this tool (for food orders) and provides specific instructions such as sending item names exactly as shown in ver_negocio and the requirement for an address for delivery. However, it does not explicitly state when not to use it or contrast with alternatives.

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

All Directorio Systema tools Inspect

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

Need Help?