QuassLabs API

mcp_tool_lint

Read-onlyIdempotent

Static review of MCP tool definitions, as returned by a server's tools/list, for how well a model can choose and call them. Flags missing, too-short or vague descriptions; parameters with no description or type; free-form objects and arrays without items; required fields that are not declared; duplicate, case-colliding or near-identical tools; missing or contradictory annotations (readOnlyHint, destructiveHint and friends); tool-poisoning phrasing that tells the model to override its instructions or hide actions from the user; and hidden zero-width, bidi or tag characters. Also estimates the token cost of the whole tool list. Nothing is fetched and no tool is called; the score is a heuristic for usability, not a security guarantee. Deterministic, no LLM.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mcp_tool_lint"
  }
}

Input Schema

Name	Required	Description	Default
`tools`	No	The tool definitions to check: each an object with name, description, inputSchema and optional title, outputSchema and annotations. Max 200 tools, 512 KB request body.
`tools_list`	No	Alternative to tools: a raw tools/list result ({"tools": [...]}) pasted as-is.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 8, 2026

addedInput schema / properties / tools / items / properties

Added value: +{
+  "annotations": {
+    "description": "Optional behaviour hints.",
+    "properties": {
+      "destructiveHint": {
+        "description": "May destroy or overwrite data.",
+        "type": "boolean"
+      },
+      "idempotentHint": {
+        "description": "Repeat calls have no extra effect.",
+        "type": "boolean"
+      },
+      "openWorldHint": {
+        "description": "Talks to external systems.",
+        "type": "boolean"
+      },
+      "readOnlyHint": {
+        "description": "Changes nothing.",
+        "type": "boolean"
+      },
+      "title": {
+        "description": "Display title.",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "description": {
+    "description": "What the tool does.",
+    "type": "string"
+  },
+  "inputSchema": {
+    "additionalProperties": {
+      "description": "Any JSON Schema keyword."
+    },
+    "description": "A JSON Schema; for inputSchema, type \"object\" with properties.",
+    "type": "object"
+  },
+  "name": {
+    "description": "Tool name.",
+    "type": "string"
+  },
+  "outputSchema": {
+    "additionalProperties": {
+      "description": "Any JSON Schema keyword."
+    },
+    "description": "Optional JSON Schema of the result.",
+    "type": "object"
+  },
+  "title": {
+    "description": "Optional display title.",
+    "type": "string"
+  }
+}

addedInput schema / properties / tools_list / properties / tools / items / additionalProperties
```
Added value: +{
+  "description": "See tools[]."
+}
```
changedInput schema / properties / tools_list / properties / tools / items / description
```
Previous value: -"One MCP tool definition."New value: +"Same fields as tools[]."
```

AddedNov 8, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false, idempotent, non-destructive), and the description goes well beyond them by disclosing operational traits: no network fetch, no tool invocation, deterministic output with no LLM, and an explicit disclaimer that the score is a usability heuristic rather than a security guarantee. Those caveats materially shape how an agent should interpret and caveat the result.

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 is front-loaded in the first clause, then a semicolon-delimited enumeration of checks, then the scope limits. The catalogue of checks is long but each item is concrete and earns its place; only slightly dense for a single paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter static analyzer with no output schema, the description covers inputs indirectly and does signal that a score and a token-cost estimate come back, which is enough to set expectations about results. It could say a bit more about the shape of the reported findings, but nothing essential for calling 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%, including the nested tool-definition fields and the tools[] vs tools_list alternative, so the schema carries the parameter burden. The description adds no field-level detail beyond the schema (it never mentions the tools_list convenience form or the 200-tool / 512 KB limits), so the baseline 3 applies.

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 ("static review of MCP tool definitions, as returned by a server's tools/list") and enumerates exactly which defects are detected. That is clearly distinct from siblings such as tool_advisor or pr_description_lint, so an agent can pick this one 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: "Nothing is fetched and no tool is called" tells the agent this works on pasted definitions, not live servers, which is a useful boundary. But there is no explicit when-to-use or when-not-to-use guidance relative to the other lint/advisor siblings (for example, tool_advisor is never mentioned as an alternative).

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

All QuassLabs API tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.