Skip to main content
Glama
Sign In
patchbay

patchbay

by GodSmasher
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Audit an MCP server for OAuth 2.1 and security gaps

audit_mcp_server

Scans remote or local MCP servers for OAuth 2.1, audience validation, redirect, metadata, secret, and prompt-injection gaps, returning a letter grade, numeric score, and findings.

Instructions

Scan a remote MCP server URL (or a local MCP connector directory) for OAuth 2.1, RFC 8707 audience validation, RFC 8252 loopback redirects, OAuth metadata, scope posture, secret surface, tool manifest drift, and tool-description prompt injection patterns. Returns a letter grade, numeric score and the full findings list. Runs zero-auth probing by default (metadata-level checks only). Pass "authToken" to probe behind authentication. Pass "probeAudienceToken" to enable AUDIENCE-001 (cross-audience token check, RFC 8707). Pass "probeMissingAudToken" to enable AUDIENCE-002 (missing-aud-claim check, catches the if (aud && aud !== me) reject early-exit bug). Pass "probeDcrLoopback: true" to enable AUTH-006 (writes a throw-away client registration to the authorization server). The scanner never calls any of the server's tools.

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": {
      "target": "<target>"
    },
    "name": "audit_mcp_server"
  }
}

Input Schema

NameRequiredDescriptionDefault
targetYesMCP server URL (https://...) or absolute path to a local connector directory.
authTokenNoBearer token to send on every probe request. Use for servers that require authentication beyond initialize.
timeoutMsNoPer-request timeout in milliseconds. Default 8000.
probeDcrLoopbackNoOpt into AUTH-006 active Dynamic Client Registration loopback probe (RFC 8252 Section 7.3). Writes a throw-away client to the authorization server; off by default.
probeAudienceTokenNoBearer token minted for a DIFFERENT resource on the same authorization server. Enables AUDIENCE-001 (RFC 8707 cross-audience check).
probeMissingAudTokenNoBearer token whose JWT payload has NO aud claim at all. Enables AUDIENCE-002 (catches `if (aud && aud !== me) reject` early-exit bug per RFC 9068 Section 4).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description does the heavy lifting well: it states the default is zero-auth metadata-level probing, discloses that probeDcrLoopback writes a throw-away client registration to the authorization server, and reassures that no server tools are ever invoked. It also discloses the return shape (letter grade, numeric score, findings list). Gaps remain around failure modes, network/permission requirements, and whether probes are rate-limited.

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?

The core purpose and return values are front-loaded, and the 'Pass X to enable Y' pattern is consistent and scannable. The tail sentences duplicate schema parameter descriptions almost verbatim, which is wasted space, but the enumeration of check families earns its length.

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?

No output schema exists, and the description compensates by naming the return artifacts (letter grade, numeric score, full findings list). For a six-parameter, network-touching scanner with a state-writing opt-in, the definition covers scope, defaults, side effects and outputs adequately. It is thin only on error behavior and the cost/time implications of the active probes.

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 explains target, authToken, timeoutMs and all three probe flags. The prose largely restates the flag-to-check mapping that the schema already encodes, adding only the parenthetical explanation of the early-exit bug for AUDIENCE-002. That is genuine but modest added meaning, so the baseline 3 holds.

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 ('Scan a remote MCP server URL (or a local MCP connector directory)') and then enumerates the exact check families it runs (OAuth 2.1, RFC 8707, RFC 8252, metadata, scope posture, secret surface, manifest drift, prompt injection). That is far more specific than a generic 'audit' label. It never names a sibling (scan_repo, verify_code, research_api), so an agent must infer the boundary itself.

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?

Usage context is explicit for the risky path: zero-auth metadata-only probing is the default, and each opt-in flag is tied to the specific check it unlocks (authToken for authenticated probing, probeAudienceToken for AUDIENCE-001, probeMissingAudToken for AUDIENCE-002, probeDcrLoopback for AUTH-006). What is missing is routing guidance against alternatives — nothing says when to reach for this versus scan_repo or verify_code.

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