Skip to main content
Glama
Sign In
MCP Rating Gateway

MCP Rating Gateway

by mcprating
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mcp_audit

View a safety audit trail of sandboxed MCP server activity, including tool calls, blocked tools, network egress, and capability grants; use security-only filtering to isolate blocks and errors.

Instructions

View the safety audit trail — a forensics log of what sandboxed MCP servers did and what the sandbox blocked (tool calls, blocked tools, blocked/allowed network egress, connects with granted capabilities). Use securityOnly: true to see only blocks and errors.

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_audit"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoFilter to a single server slug
eventNoFilter to a single event type
limitNoMax events to return (default 50, newest first)
securityOnlyNoShow only security-relevant events (blocks + errored calls)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • changedInput schema / properties / event / enum
      Previous value: -[
-  "connect",
-  "tool_call",
-  "tool_blocked",
-  "egress_blocked",
-  "egress_allowed",
-  "personal_data_requested",
-  "disconnect"
-]New value: +[
+  "connect",
+  "tool_call",
+  "tool_blocked",
+  "egress_blocked",
+  "egress_allowed",
+  "personal_data_requested",
+  "approval",
+  "disconnect"
+]
  2. Changed1 schema field changedv0.4.1
    • changedInput schema / properties / event / enum
      Previous value: -[
-  "connect",
-  "tool_call",
-  "tool_blocked",
-  "egress_blocked",
-  "egress_allowed",
-  "disconnect"
-]New value: +[
+  "connect",
+  "tool_call",
+  "tool_blocked",
+  "egress_blocked",
+  "egress_allowed",
+  "personal_data_requested",
+  "disconnect"
+]
  3. First observedv0.2.3

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations supplied, the description does real work: 'View' establishes a read-only operation, and the parenthetical discloses the exact categories of behavior recorded, including both what servers did and what the sandbox blocked. It omits retention window, whether results span all servers by default, and access prerequisites, which keeps it from a 5.

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?

Two sentences, leading with what the tool is and following with the one actionable flag. The parenthetical enumeration is dense but each item carries informational weight; nothing is redundant with the schema.

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?

A read-only query tool with four all-optional params and no output schema — the description covers the conceptual return contents (event categories) and the default sort via the schema. What is missing is the default scope (all servers vs. one slug) and any sense of volume or retention, small gaps for a forensics listing 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 coverage is 100%, so slug, event, limit and their constraints are already documented. The description restates the securityOnly semantics ('only blocks and errors'), which matches rather than extends the schema, and says nothing about combining filters or cursor behavior. Baseline 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?

States a specific verb and resource ('View the safety audit trail') and immediately defines it as a forensics log of sandboxed server activity, enumerating the concrete event kinds (tool calls, blocked tools, egress, connects with capabilities). That distinguishes it in substance from mcp_usage or mcp_list_active, though no sibling is named explicitly.

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?

Offers one concrete usage cue — `securityOnly: true` for blocks and errors — which is genuinely helpful routing advice. It gives no when-not guidance and does not contrast itself with mcp_usage or mcp_list_active, so the agent must infer which observability tool to reach for.

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