Skip to main content
Glama
Sign In

Dredd MCP

by io.github.pduggusa
OverviewDiscussionsAdmin

Server Details

Pre-flight verdict on MCP servers: known-bad identity, CVEs, dependency tree, tool drift. Signed.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.8% over 75 days
Last Tested
Transport
Streamable HTTP · MCP 2024-11-05
URL
Repository
pduggusa/dredd-mcp
GitHub Stars
0
Server Listing
Dredd
ChatGPT
–
Claude
–

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection or overlap with a sibling tool. Its purpose (pre-flight security verdict for an MCP server invocation) is stated unambiguously and its return contract is spelled out.

Naming Consistency5/5

check_mcp_server follows a clean verb_noun snake_case pattern. With a single tool there is no convention mixing, and the name is self-describing.

Tool Count3/5

One tool is thin for a general-purpose server, though it is defensible for a narrowly scoped security-gate service. The surface offers no batch or follow-up operations, so the set feels minimal even for its purpose.

Completeness4/5

The core operation (verdict + severity + evidence + dependency-graph summary + signed response) is fully covered for a pre-flight check. Minor gaps exist around remediation guidance or batch checks, but agents can work around them.

Available Tools

1 tool
check_mcp_serverCheck an MCP serverA
Read-only
Inspect

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.

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.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedcheck_mcp_server1 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. 1 tool update
    • Changedcheck_mcp_server3 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. 1 tool update
    • Changedcheck_mcp_server2 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. 1 tool update
    • First observedcheck_mcp_server

Related MCP Connectors

Related MCP Servers

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