IA-QA — 152 QA & Dev Tools for AI Agents

diff_mappings

Read-onlyIdempotent

Diff a baseline page mapping against a current one and return a CI-style verdict: PASS / FIX / BLOCK, plus per-element drift (ok, renamed, healable, ambiguous, lost, added, rebound). Pure and deterministic — provide two mappings as JSON with "elements" arrays of {role, name, selector, context?}. Use the companion @ia-qa/self-healing package (npm install -g @ia-qa/self-healing) to capture mappings from your app via its local MCP server ia-qa-heal-mcp, or paste the snippet from ia-qa.com/devtools/selector-drift into your browser console.

Input Schema

Name	Required	Description	Default
`after`	Yes	Current page mapping: same shape as before, captured after the UI change.
`before`	Yes	Baseline page mapping: { page, url, capturedAt, elements: [{role, name, selector, context?}] }. Captured before a UI change.

Output Schema

Name	Required	Description	Default
`rows`	No
`added`	No
`counts`	No
`verdict`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / examples

Added value: +[
+  {
+    "after": {
+      "elements": [
+        {
+          "name": "Log in",
+          "role": "button",
+          "selector": "#submit"
+        }
+      ],
+      "page": "login"
+    },
+    "before": {
+      "elements": [
+        {
+          "name": "Sign in",
+          "role": "button",
+          "selector": "#submit"
+        }
+      ],
+      "page": "login"
+    }
+  }
+]

AddedJul 16, 2026

TDQS

A4.2/5.0

Behavior4/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 safety is covered structurally. The description adds genuinely new behavioral context: 'Pure and deterministic' and the enumerated outcome categories (ok, renamed, healable, ambiguous, lost, added, rebound) that signal what the agent should expect back. It doesn't cover edge cases like malformed mapping input, so not a 5.

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 purpose and verdict vocabulary are front-loaded and the input-format sentence earns its place. The trailing install command and devtools URL are useful for capture but lean promotional and add length an agent doesn't strictly need to invoke the tool, keeping it from a 5.

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?

An output schema exists, so return values needn't be spelled out, and the schema fully documents both inputs. The description still adds the decisive missing pieces — determinism, verdict semantics, and how to source mappings — making it complete for an agent to call this correctly.

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% and both 'before' and 'after' are already documented in the schema, including the elements shape. The description restates the same element shape ({role, name, selector, context?}) rather than adding new meaning, so it earns the high-coverage baseline of 3 rather than more.

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 resource ('Diff a baseline page mapping against a current one') and names the output contract ('CI-style verdict: PASS / FIX / BLOCK, plus per-element drift'). The domain specificity (page mappings, selector drift categories) distinguishes it from generic siblings like diff_text and json_diff without needing to name them.

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?

It tells the agent the inputs needed (two mappings as JSON with 'elements' arrays) and how to obtain them (companion @ia-qa/self-healing package or the browser-console snippet), which is clear usage context. What's missing is an explicit exclusion or alternative — e.g. when to prefer diff_text or analyze_diff_bugs over this tool — leaving some routing inference to the agent.

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

All IA-QA — 152 QA & Dev Tools for AI Agents 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.