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

mcp_server_health_check

Read-onlyIdempotent

Check an MCP server's tool definitions without contacting it — for a server not deployed yet, a stdio server, or a CI gate. Paste the answer to tools/list (raw JSON-RPC or its result), a bare array of tools, one tool definition, or a manifest carrying name/description; input_shape says which one was read. Validates every tool against the MCP spec (name 1-128 chars of A-Z a-z 0-9 _ - .; camelCase and a tool with no parameters are valid; inputSchema of type object; required fields listed in properties) and, with strict, documentation (description ≥ 20 chars, every parameter with a description and a type). verdict: FAIL when a tool breaks a rule or no tool is found, WARN when only a manifest's server name/description is missing, PASS otherwise. A tools/list carries no server name, so those two checks are not scored on it (the name comes from initialize). Gate on verdict or on checks[tool_quality].pass.

Input Schema

Name	Required	Description	Default
`strict`	No	Also require documentation: every description ≥ 20 characters, every parameter with a description and a type.
`manifest`	Yes	JSON text: the answer to tools/list (raw JSON-RPC or its result), an array of tools, one tool definition, or a manifest with name/description/tools.

Output Schema

Name	Required	Description	Default
`stats`	No
`total`	No
`checks`	No
`failed`	No
`passed`	No
`verdict`	No
`toolIssues`	No
`input_shape`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

addedInput schema / examples

Added value: +[
+  {
+    "manifest": "{\"tools\":[{\"name\":\"get_weather\",\"description\":\"Return the current weather for a city. Use it when the user asks about the weather now.\",\"inputSchema\":{\"type\":\"object\",\"required\":[\"city\"],\"properties\":{\"city\":{\"type\":\"string\",\"description\":\"City name, e.g. Paris\"}}}}]}"
+  }
+]

Changed3 schema fields changedOct 23, 2026

changedInput schema / properties / manifest / description

Previous value: -"MCP server manifest JSON (the response from GET /mcp or tools/list)"New value: +"JSON text: the answer to tools/list (raw JSON-RPC or its result), an array of tools, one tool definition, or a manifest with name/description/tools."

changedInput schema / properties / strict / description

Previous value: -"Enable strict mode: also check for optional best practices (examples, default values, descriptions > 20 chars)"New value: +"Also require documentation: every description ≥ 20 characters, every parameter with a description and a type."

addedOutput schema / properties / input_shape
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedJun 21, 2026

addedOutput schema / properties

Added value: +{
+  "checks": {
+    "type": "array"
+  },
+  "failed": {
+    "type": "number"
+  },
+  "passed": {
+    "type": "number"
+  },
+  "stats": {
+    "type": "object"
+  },
+  "toolIssues": {},
+  "total": {
+    "type": "number"
+  },
+  "verdict": {
+    "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 readOnly/idempotent annotations: it enumerates the exact validation rules applied (name charset and length, inputSchema type object, required listed in properties), what strict adds, and the three-way FAIL/WARN/PASS verdict semantics. It even discloses a subtle scoring caveat — that a tools/list carries no server name, so those two checks are skipped.

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 purpose, then inputs, then rules, then verdict semantics — every sentence carries information. It is a single dense block with no line breaks or list structure, which makes the rule enumeration harder to scan than it needs to be.

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 an output schema handling return values and annotations covering the safety profile, the description supplies exactly the remaining gaps: accepted input forms, validation rules, strict-mode behavior, and verdict thresholds. Nothing an agent needs 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `manifest` and `strict` are already documented in the schema, and the description largely restates them. It adds no syntax or format detail beyond what the schema provides, so this sits at the baseline.

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?

States a specific verb and resource ("Check an MCP server's tool definitions") plus the defining constraint "without contacting it," which cleanly separates it from live-evaluation siblings like mcp_server_evaluate and from the narrower mcp_schema_lint. The enumerated accepted input shapes make the scope unmistakable.

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?

Gives three concrete when-to-use scenarios (server not deployed yet, stdio server, CI gate) and tells the agent how to gate on the result (verdict or checks[tool_quality].pass). It lacks an explicit "not for X, use Y instead" exclusion against siblings, so it stops short of the top band.

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.