Burs-IA Utils

Diferencia JSON como parche

json-diff-patch

Read-onlyIdempotent

Calcula un JSON Patch (RFC 6902) que transforma el documento a en b. Cuándo: hay que transformar, comparar o revisar con exactitud datos estructurados (JSON, CSV, YAML, XML, arreglos). No para: aplicar un JSON Patch (json-patch-apply). 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: Computes an RFC 6902 JSON Patch that transforms document a into document b (object keys diffed recursively, arrays element-wise with tail adds/removes). When: structured data (JSON, CSV, YAML, XML, arrays) has to be transformed, compared or checked exactly. Not for: applying an RFC 6902 JSON Patch (json-patch-apply). 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

Name	Required	Description	Default
`a`	Yes	Source document (any JSON value; required).
`b`	Yes	Target document (any JSON value; required).

Output Schema

Name	Required	Description	Default
`equal`	No
`patch`	No	any JSON value

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / a / examples

Added value: +[
+  {
+    "x": 1,
+    "y": [
+      1,
+      2,
+      3
+    ],
+    "z": 0
+  }
+]

addedInput schema / properties / b / examples

Added value: +[
+  {
+    "w": true,
+    "x": 2,
+    "y": [
+      1,
+      2
+    ]
+  }
+]

First observedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true and destructiveHint=false, but the description adds useful behavioral context beyond them: no network access, no stored state, deterministic output, a 64 KB input limit, 1 s per call and a 1 MB result limit. These limits and guarantees are exactly the kind of operational details an agent needs before invoking the tool.

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?

The content is front-loaded and clearly organized into purpose, when/not-for, side effects, determinism and limits. The main conciseness issue is that the full description is duplicated in Spanish and English, which increases length even though the structure remains clean.

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?

Given a simple two-parameter tool with rich annotations, an output schema and complete schema descriptions, the definition covers purpose, exclusions, side effects, determinism and operational limits. No important calling context appears to be missing.

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%: a is documented as the source document and b as the target document, both required and accepting any JSON value. The description adds useful comparison semantics such as recursive object key diffing and element-wise array handling with tail adds/removes, but it does not add parameter-level meaning beyond what the schema already provides.

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 states a specific verb and output format: computes an RFC 6902 JSON Patch that transforms document a into document b. It explicitly distinguishes itself from the closest sibling by saying it is not for applying a JSON Patch, directing that case to json-patch-apply.

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' section for transforming, comparing or exactly checking structured data, and an explicit 'Not for' exclusion with the alternative tool json-patch-apply. This leaves no meaningful guessing about when to select this tool versus its sibling.

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

All Burs-IA Utils tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?