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

analyze_diff_bugs

Read-onlyIdempotent

Pattern-based diff linter: flags a fixed set of risky shapes in changed code — query-string interpolation (SQL/Cypher/Mongo injection shape), shell interpolation, eval/new Function, empty catch blocks, regex built from a variable, fewer catch blocks than before, and named authorization guards that disappeared. Every finding cites the line that produced it. It does NOT do data-flow analysis: it cannot follow a value to a sink, across functions or files, and an empty result is not a safety verdict (the response lists what it did not analyse). Advisory triage — use a static analyser for a real security gate.

Input Schema

Name	Required	Description
`context`	No	Optional PR title or feature context for better analysis
`version1`	No	Original code (before changes). If omitted, only the new version is analysed.
`version2`	Yes	New/modified code (after changes)

Output Schema

Name	Required	Description	Default
`bugs`	No
`disclaimer`	No
`notAnalysed`	No
`overallRisk`	No
`rulesApplied`	No
`scannedLines`	No
`totalSuggestions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / examples

Added value: +[
+  {
+    "version1": "if (amount > 0) charge(amount);",
+    "version2": "if (amount >= 0) charge(amount);"
+  }
+]

Changed7 schema fields changedJul 29, 2026
- addedOutput schema / properties / disclaimer
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / notAnalysed
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
- addedOutput schema / properties / overallRisk
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / rulesApplied
```
Added value: +{
+  "type": "number"
+}
```
- addedOutput schema / properties / scannedLines
```
Added value: +{
+  "type": "number"
+}
```
- removedOutput schema / properties / summary
```
Removed value: -{
-  "type": "string"
-}
```
- addedOutput schema / properties / totalSuggestions
```
Added value: +{
+  "type": "number"
+}
```

Changed1 schema field changedJun 21, 2026

addedOutput schema / properties

Added value: +{
+  "bugs": {
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "summary": {
+    "type": "string"
+  }
+}

Changed1 schema field changedJun 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedMay 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the analysis boundary (no data-flow, cannot follow a value across functions or files), how findings are reported (each cites the producing line), and that the response lists what was NOT analysed. The warning that an empty result is not proof of safety is exactly the kind of limitation an agent would otherwise get wrong, and nothing here conflicts with readOnlyHint/idempotentHint.

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?

Front-loaded with the category label followed by the concrete check list, then limitations, then the advisory caveat — a logical order. The middle sentence is long and list-heavy, but every clause is substantive; only minor tightening would help.

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?

Annotations cover read-only/idempotent safety, the schema fully documents all three parameters, and an output schema exists so return shape needn't be explained. What remains — scope of the checks, analytical limits, and the non-verdict of an empty result — is all present, leaving no meaningful gap for an agent deciding whether and how to call it.

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%, so the schema already defines version1, version2 and context, including the note that omitting version1 analyses only the new version. The description adds the concept of a diff between changed code but nothing further about parameter formats or interactions, which is the expected baseline when the schema does the work.

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?

Opens with a specific role ("Pattern-based diff linter") and then enumerates the exact risky shapes it detects in changed code, so an agent knows precisely what class of tool this is. The closing line ("Advisory triage") distinguishes it from a full security scanner, separating it from the static-analysis and security siblings in spirit even if not by name.

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?

Explicitly frames the intended use (advisory triage) and names the alternative class of tool: "use a static analyser for a real security gate." It also warns that an empty result is not a safety verdict, which is actionable usage guidance. It stops short of naming any of the many security-adjacent siblings (shield_analyze, secret_scan, detect_secrets), so an agent still has to infer which one to reach for instead.

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.