Skip to main content
Glama

audit_mcp

Read-only

Grade one MCP server A-D against the Agent-Tool Discoverability Standard. SaSame, operated by SASAME S.R.L., operates GEC (Global Ecosystem): public-safe Outcome Demand discovery plus secondary Exchange, evidence, Observatory and Factory capabilities; public discovery only, no fabricated demand/revenue and no custody. Runs the legitimate revision-aware MCP protocol entry (server/discover with legacy initialize fallback), tools/list, and one read-only tool call over POST JSON-RPC. It returns the grade, a per-criterion pass/evidence breakdown, and the single biggest gap to fix. This returns the grade and analysis ONLY — if you want a signed, portable certificate of the same audit, use verify_mcp_ready instead. DIRECTORY PRE-FLIGHT: these criteria cover the MECHANICAL reject reasons of the Claude Connectors Directory and ChatGPT Apps Directory (annotations, typed schemas, description clarity, liveness, graceful errors, anti-ghost) — run it before you submit. It does NOT cover privacy-policy, identity/business verification, OAuth callbacks, or prohibited-category rules; it catches mechanical failures, it does not guarantee a pass. SECURITY SIGNALS (advisory, never a verdict): plain-HTTP exposure, redirect count, Server/X-Powered-By header disclosure, stack-trace-shaped text in error responses (zero extra cost — read from responses already fetched), plus two bounded best-effort checks — RFC 9728 OAuth protected-resource metadata and TLS certificate expiry/trust-chain status. CAPABILITY SIGNALS (advisory, never graded): resources/list and prompts/list support (OPTIONAL per the MCP spec — their absence is not a defect), tools/list pagination, and the raw capabilities the server declared. Protocol inspection only — no auth-bypass, no payment. Free. Best run against YOUR OWN server. (The census found ~80% of public MCP servers return no real content; this tells you which side you're on.)

Input Schema

NameRequiredDescriptionDefault
urlYesThe MCP server endpoint URL (https) to audit — ideally your own

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them — the exact protocol steps performed (server/discover with legacy initialize fallback, tools/list, one read-only tool call over POST JSON-RPC), what is returned, the advisory-not-verdict nature of security signals, and explicit constraints (no auth-bypass, no payment, free). This is rich disclosure the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Core purpose and the verify_mcp_ready routing are front-loaded, which is good, but the definition is bloated and contains an unrelated embedded paragraph about 'SaSame... GEC (Global Ecosystem)... Outcome Demand discovery' that has nothing to do with auditing an MCP server and risks confusing the agent.

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?

No output schema exists, so the description correctly explains the return shape (grade, per-criterion pass/evidence breakdown, single biggest gap). Combined with the explicit scope boundaries, an agent has everything needed to call it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, so the schema already documents that 'url' is the HTTPS endpoint. The description still adds intent ('ideally your own', 'Best run against YOUR OWN server'), reinforcing correct usage beyond the raw type.

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?

Opens with a specific verb+resource+output: 'Grade one MCP server A-D against the Agent-Tool Discoverability Standard.' It distinguishes itself from the sibling verify_mcp_ready by explicitly stating this returns 'the grade and analysis ONLY' versus a signed certificate. An agent can tell the two apart without opening schemas.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (DIRECTORY PRE-FLIGHT, run before submitting to Claude Connectors or ChatGPT Apps Directory) and when-not (does NOT cover privacy-policy, identity/business verification, OAuth callbacks, prohibited-category rules). It also names the alternative tool for the adjacent need.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.