Skip to main content
Glama
Sign In

Dredd MCP

by io.github.pduggusa
OverviewDiscussionsAdmin

Check an MCP server

check_mcp_server
Read-only

Pre-flight security verdict for an MCP server invocation. Judges BOTH server-level reputation AND the server's dependency graph (npm/pypi) against the DugganUSA threat-intel corpus (1.13M+ IOCs, Shai-Hulud + typosquat + LOLBin families). Returns BLOCK / ADVISORY / REVIEW / ALLOW with severity, evidence, dep-graph summary, and HMAC-signed response. REVIEW means we hold NO RECORD of this server -- not that it is safe. A brand-new attacker-published server also looks like this, so REVIEW calls for a look, not a pass. ALLOW is only returned when we actually resolved the server and scanned its dependency graph; known_to_us and dep_graph.scanned confirm it. Suited to a pre-flight check before a tool on another MCP server is used, especially one from outside the official MCP Registry.

Input Schema

NameRequiredDescriptionDefault
toolNoOptional name of the specific tool being invoked
serverYesREQUIRED. The server to judge: its exact MCP Registry name (io.github.owner/server-name, optionally @version). A bare name (server-name) is judged as typed, never mapped to a registry server, and the matching full names come back in input.did_you_mean. Also resolved, only when the identity is provable: a registry URL (https://registry.modelcontextprotocol.io/v0/servers/<name>) and a GitHub repo ("owner/repo" or https://github.com/owner/repo) published by that owner as exactly one registry server. Package names (npm/PyPI), images and Smithery ids are recorded but judged as given (usually REVIEW): their name does not prove which code runs. Refused: commands, shell metacharacters, non-ASCII, local paths, endpoint URLs. No substring or fuzzy matching: anything we cannot resolve to exactly one server returns REVIEW, never a guess.
versionNoOptional version of the MCP server (semver). A version inside `server` (name@1.2.3) is used when this is empty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / server / description
      Previous value: -"REQUIRED. The server to judge: its exact MCP Registry name (io.github.owner/server-name, optionally @version) or that name's exact final segment (server-name). Also resolved, only when the identity is provable: a registry URL (https://registry.modelcontextprotocol.io/v0/servers/<name>) and a GitHub repo (\"owner/repo\" or https://github.com/owner/repo) published by that owner as exactly one registry server. Package names (npm/PyPI), images and Smithery ids are recorded but judged as given (usually REVIEW): their name does not prove which code runs. Refused: commands, shell metacharacters, non-ASCII, local paths, endpoint URLs. No substring or fuzzy matching: anything we cannot resolve to exactly one server returns REVIEW, never a guess."New value: +"REQUIRED. The server to judge: its exact MCP Registry name (io.github.owner/server-name, optionally @version). A bare name (server-name) is judged as typed, never mapped to a registry server, and the matching full names come back in input.did_you_mean. Also resolved, only when the identity is provable: a registry URL (https://registry.modelcontextprotocol.io/v0/servers/<name>) and a GitHub repo (\"owner/repo\" or https://github.com/owner/repo) published by that owner as exactly one registry server. Package names (npm/PyPI), images and Smithery ids are recorded but judged as given (usually REVIEW): their name does not prove which code runs. Refused: commands, shell metacharacters, non-ASCII, local paths, endpoint URLs. No substring or fuzzy matching: anything we cannot resolve to exactly one server returns REVIEW, never a guess."
  2. Changed3 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -falseNew value: +true
    • changedInput schema / properties / server / description
      Previous value: -"REQUIRED. Exact MCP Registry name (e.g. io.github.owner/server-name), or its exact final segment (server-name). No substring or fuzzy matching: a name we cannot resolve to exactly one server returns REVIEW, never a guess."New value: +"REQUIRED. The server to judge: its exact MCP Registry name (io.github.owner/server-name, optionally @version) or that name's exact final segment (server-name). Also resolved, only when the identity is provable: a registry URL (https://registry.modelcontextprotocol.io/v0/servers/<name>) and a GitHub repo (\"owner/repo\" or https://github.com/owner/repo) published by that owner as exactly one registry server. Package names (npm/PyPI), images and Smithery ids are recorded but judged as given (usually REVIEW): their name does not prove which code runs. Refused: commands, shell metacharacters, non-ASCII, local paths, endpoint URLs. No substring or fuzzy matching: anything we cannot resolve to exactly one server returns REVIEW, never a guess."
    • changedInput schema / properties / version / description
      Previous value: -"Optional version of the MCP server (semver)"New value: +"Optional version of the MCP server (semver). A version inside `server` (name@1.2.3) is used when this is empty."
  3. Changed2 schema fields changed
    • changedInput schema / properties / server / description
      Previous value: -"MCP server name (e.g. io.github.foo/bar) or substring"New value: +"REQUIRED. Exact MCP Registry name (e.g. io.github.owner/server-name), or its exact final segment (server-name). No substring or fuzzy matching: a name we cannot resolve to exactly one server returns REVIEW, never a guess."
    • addedInput schema / properties / server / minLength
      Added value: +1
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With annotations already covering read-only and open-world behavior, the description adds substantial context: it enumerates the four verdicts and explains the critical REVIEW ambiguity (no record is not a pass) and the ALLOW precondition (resolved server plus scanned dependency graph). It also mentions severity, evidence, dependency-graph summary, and HMAC-signed response.

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 the core purpose and verdict semantics. It is somewhat long, but the additional sentences about REVIEW and ALLOW are essential to prevent dangerous misinterpretation, so nearly all content earns its place.

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?

There is no output schema, so the description carries the return-value burden and does so effectively by explaining every verdict, the evidence fields, the dependency-graph summary, and the signed response. An agent has enough information to call and interpret the tool correctly.

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 the schema already documents the server, tool, and version parameters in detail. The description does not add parameter syntax or format details beyond what the schema provides, which is the expected baseline when the schema is complete.

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: a pre-flight security verdict for an MCP server invocation. It precisely defines what is judged (server-level reputation plus dependency graph) and what is returned, so an agent knows exactly what the tool does.

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?

Explicitly recommends use as a pre-flight check before invoking a tool on another MCP server, especially one outside the official registry. It gives clear context but does not name exclusions or alternatives, and there are no sibling tools to differentiate against.

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

All Dredd MCP toolsInspect
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.

Resources