Systemores AI Agent & MCP Security Auditor

Audit MCP Tool Definitions Integrity

systemores_audit_tool_integrity

Read-onlyIdempotent

Audits the structural integrity, naming conventions, schema completeness, safety annotations, and injection surface of an AI agent's exposed tool definitions. Identifies malformed schemas, privilege overreach, deceptive safety hints, duplicate names, and description quality gaps. Operates entirely offline — no external API calls required.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "toolDefinitionsJson": "<toolDefinitionsJson>"
    },
    "name": "systemores_audit_tool_integrity"
  }
}

Input Schema

Name	Required	Description	Default
`strictMode`	No	When true, applies stricter scoring thresholds — missing optional fields such as parameter descriptions, inputSchema, and MCP tool annotations are penalized. Defaults to false.
`toolDefinitionsJson`	Yes	A JSON-serialized array of tool definition objects to audit. Each object should contain at minimum 'name' and 'description' fields. Accepts standard MCP ListToolsResult format.

Output Schema

Name	Required	Description	Default
`summary`	Yes
`findings`	Yes
`overallScore`	Yes
`toolsAudited`	Yes
`integrityRating`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's "Operates entirely offline — no external API calls required" largely restates openWorldHint=false, though it reinforces confidence. Beyond that it adds the detection categories (malformed schemas, privilege overreach, deceptive safety hints, duplicate names), but says nothing about cost, scale limits, or how findings are reported.

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?

Three sentences, front-loaded with what is audited, then what it finds, then an operational note. Nothing is padded or vague. The final sentence is mildly redundant against openWorldHint=false, costing it the top score.

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?

With an output schema present, the description need not explain return values, and the rich annotations remove the burden of safety disclosure. The remaining gaps are sibling differentiation (systemores_tool_integrity) and input-preparation guidance for toolDefinitionsJson, which are modest for a two-parameter read-only tool.

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 parameters carry their own descriptions, including the default and effect of strictMode. The description adds no meaning beyond the schema — it never mentions strictMode, the expected JSON shape, or minimum required fields. Baseline 3 is appropriate when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ("Audits") and names the resource precisely: an AI agent's exposed tool definitions. It enumerates the audited dimensions (structural integrity, naming conventions, schema completeness, safety annotations, injection surface) and the findings it produces. It does not, however, distinguish itself from the closely named sibling systemores_tool_integrity, leaving an ambiguity an agent must resolve by name alone.

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: an agent can infer this tool applies when reviewing a set of MCP tool definitions for quality or safety problems. There is no explicit when-not to use it, no prerequisite for obtaining the ListToolsResult JSON, and no routing guidance versus systemores_tool_integrity or the other audit siblings.

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

All Systemores AI Agent & MCP Security Auditor 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.