Skip to main content
Glama

Aplanar JSON

json-flatten-paths
Read-onlyIdempotent

Aplana objetos y arreglos anidados en un nivel con claves con puntos (a.b.0.c). Cuándo: hay que transformar, comparar o revisar con exactitud datos estructurados (JSON, CSV, YAML, XML, arreglos). No para: devolver un objeto con solo las rutas indicadas (json-pick). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Flattens nested objects/arrays into one level with dotted keys (a.b.0.c) or bracket array indices (a.b[0].c). Empty objects/arrays are kept as leaves. When: structured data (JSON, CSV, YAML, XML, arrays) has to be transformed, compared or checked exactly. Not for: returning a new object containing only the given dotted paths (json-pick). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB.

Input Schema

NameRequiredDescriptionDefault
valueYesObject or array (any JSON value; required).
separatorNoKey separator (string; optional; default "."; at least 1 chars; up to 4 chars)..
array_styleNoArray index style (optional; one of: dots, brackets; default "dots").dots

Output Schema

NameRequiredDescriptionDefault
valueNoany JSON value

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / value / examples
      Added value: +[
      +  {
      +    "a": {
      +      "b": [
      +        1,
      +        {
      +          "c": 2
      +        }
      +      ]
      +    },
      +    "d": {}
      +  }
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly/idempotent/non-destructive/closed-world), it adds determinism, that empty objects/arrays are kept as leaves, that there is no network or stored state, and hard limits (64 KB input, 1 s per call, 1 MB result). These are concrete traits an agent cannot get from the structured fields.

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?

Each sentence earns its place — purpose, when, when-not, side effects, determinism, limits — and the core purpose is front-loaded. The full Spanish/English duplication roughly doubles length, which is a moderate cost against otherwise tight structure.

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?

With annotations covering safety, a fully documented 3-parameter schema, and an output schema, the description covers all remaining gaps: scope, alternatives, limits and edge behavior (empty containers as leaves). Nothing needed to call it correctly is missing.

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 description coverage is 100%, so the baseline is 3; the description adds meaning by showing both output forms (a.b.0.c vs a.b[0].c), which clarifies what the array_style parameter actually changes. It does not elaborate on separator behavior, keeping it one notch above baseline rather than a full 5.

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 names a specific verb and resource — flattening nested objects/arrays into one level with dotted keys (a.b.0.c) or bracket indices — and immediately contrasts it with the sibling json-pick. An agent can tell what the tool produces without opening the schema.

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?

It gives an explicit 'When' (structured data has to be transformed, compared or checked exactly) and an explicit 'Not for' that routes to json-pick. The alternative is named with the condition that selects it, leaving nothing 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