mcp-compliance
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mcp_compliance_testA | Run the MCP compliance test suite against a server URL — the spec suite for the server's MCP revision, 2025-11-25 or 2026-07-28, auto-detected unless specVersion pins one. Returns grade (A-F), score, and detailed results covering transport, lifecycle, tools, resources, prompts, errors, schema validation, and security. |
| mcp_compliance_explainA | Explain what a specific compliance test ID checks and why it matters. Ids are per spec suite: pass specVersion to read one catalog, or omit it to search both (a shared id whose criteria differ is explained once per suite). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct roles: one is a read-only documentation lookup for a test ID, the other executes the compliance suite against a server URL. An agent can trivially tell which to call based on whether it needs an explanation or an actual test run.
Both tools follow the same predictable prefix_verb pattern (mcp_compliance_explain, mcp_compliance_test), with single, unambiguous verbs. No mixing of conventions or stylistic outliers.
Two tools is on the thin side, but the server's purpose (run the compliance suite and explain its checks) is narrow enough that this feels deliberately scoped rather than underbuilt. No redundant or filler tools are present.
The core lifecycle (run tests, explain a result) is covered, but there is no way to enumerate available test IDs or list the supported spec suites, so an agent must already know an ID or discover it from a test run's output. A discovery/list operation is a notable gap for a testing tool.