Changuito — AI eCommerce Store Builder

Vista previa de la tienda

preview_store

Read-onlyIdempotent

Valida los datos de una tienda y devuelve el resumen y la dirección final. No crea nada.

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": {
      "country": "<country>",
      "name": "<name>",
      "category": "<category>",
      "city": "<city>",
      "phone": "<phone>"
    },
    "name": "preview_store"
  }
}

Input Schema

Name	Required	Description
`city`	Yes
`name`	Yes	Nombre de la tienda, tal como lo dijo la persona.
`phone`	Yes	WhatsApp del comercio con código de área.
`address`	No
`country`	Yes	País de la tienda. Define la moneda, el idioma, la marca y los medios de cobro.
`category`	Yes	Rubro del negocio (por ejemplo indumentaria, gastronomía, cursos).
`description`	No	Descripción corta del negocio.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful fact that a normalized 'final address' is produced and reinforces no side effects, but says nothing about what validation failures look like, whether errors are per-field, or whether the result is a token consumable by create_store.

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?

Two short sentences with zero filler, and the core capability plus the no-side-effect guarantee are both front-loaded.

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?

With seven parameters, five required, and no output schema, the agent needs to know what the returned 'resumen' contains and which fields are validated/normalized; the description only gestures at this. Adequate for orientation but not complete for a validation tool whose output is unstructured.

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 71% – name, phone, country, category and description are self-documented, while city and address are not, and the description never mentions parameters at all. The mention of 'dirección final' hints that the address field is normalized, but no syntax, format or requirement detail is added beyond the schema.

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?

The description names a specific verb and resource ('Valida los datos de una tienda') and states the return ('el resumen y la dirección final'), then explicitly rules out the create path with 'No crea nada', which distinguishes it from the sibling create_store. It stops short of naming when preview is required versus get_requirements or check_slug, so it is clear but not fully differentiated across all siblings.

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?

The negation 'No crea nada' implies this is a pre-flight/dry-run step, but the description never states the trigger condition (e.g. 'call before create_store') or when-not to use it. Usage is inferable rather than stated.

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

All Changuito — AI eCommerce Store Builder 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?