Skip to main content
Glama
Sign In
Systemores Cloud MCP Server

Systemores Cloud MCP Server

by bobcar0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Audit MCP Tool Definitions Integrity

systemores_audit_tool_integrity
Read-onlyIdempotent

Audit AI agent tool definitions for malformed schemas, naming conflicts, safety annotation overreach, and injection risks—fully offline, with optional strict scoring.

Instructions

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

NameRequiredDescriptionDefault
strictModeNoWhen true, applies stricter scoring thresholds — missing optional fields such as parameter descriptions, inputSchema, and MCP tool annotations are penalized. Defaults to false.
toolDefinitionsJsonYesA JSON-serialized array of tool definition objects to audit. Each object should contain at minimum 'name' and 'description' fields. Accepts standard MCP ListToolsResult format.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.3

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false; the description's 'operates entirely offline' is consistent with that and usefully reinforces it. It adds a substantive behavioral claim that the audit specifically detects 'deceptive safety hints' and 'privilege overreach,' which tells the agent this is an adversarial inspection rather than a format lint. It stops short of describing the audit output or the effect of strictMode on results, a real gap given there is no output schema.

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 purpose and followed by what it detects and how it runs. No filler, and the offline note earns its place by clarifying the execution model. The middle sentence is a dense list, but each item is informative rather than padding.

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, read-only, offline tool with fully documented schema and no output schema, the description covers what it inspects and that it needs no external access. The main remaining gap is the shape of the audit report the agent receives back and how strictMode changes it, plus differentiation from the similarly named sibling.

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 are documented in the schema itself, including strictMode's threshold behavior and the accepted JSON format for toolDefinitionsJson. The description adds no syntax, format, or size-limit detail beyond that, so the baseline of 3 applies.

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 opens with a specific verb and resource ('Audits ... exposed tool definitions') and enumerates the audit dimensions: structural integrity, naming conventions, schema completeness, safety annotations, and injection surface. That is far more than a restatement of the name. However, it never distinguishes itself from the near-identically named sibling 'systemores_tool_integrity', leaving the agent to infer which one to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no named alternative — despite a sibling whose name suggests overlapping scope. The only contextual statement, 'Operates entirely offline — no external API calls required,' describes execution mode rather than when to select this tool over another.

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

Deploy Server

Other Tools