MCP Compliance

Name: MCP Compliance
Author: YawLabs

제작자: YawLabs버전 0.21.1i★ –i내 컴퓨터에서 실행

레지스트리 이름io.github.YawLabs/mcp-compliance

설치

개요

제작자가 쓴 설명(영어 원문)

CLI tool and MCP server that tests MCP servers for spec compliance

PopNx MCP의 세 기둥

이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.

사용자 의견i아직 리뷰가 없어요리뷰는 다음 단계에서 계정 기능과 함께 열려요
우리의 기본 점검i1개 중 1개 통과공개된 정보로 점검했으며, 코드는 아직 스캔하지 않았어요
사용 정도i초기↓ 736/주 · ★ –

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

연결 방식: 내 컴퓨터에서 실행
전송 방식: stdio
카테고리: 법률 및 정부 데이터

설치

쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.

설치하기 전에

기본 점검: 1개 중 1개 통과
내 컴퓨터에서 내 사용자 계정의 권한(파일, 네트워크, 앱)으로 실행돼요.
레지스트리에 입력해야 할 키가 나와 있지 않아요.

필요한 것

npmNode.js 설치(npx 명령어용)

어떤 앱을 쓰세요?

ClaudeClaude CodeCursorVS CodeChatGPT

위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.

Claude Desktop → Settings → Developer → Edit Config를 열고 claude_desktop_config.json에 이 내용을 붙여 넣으세요

{
  "mcpServers": {
    "compliance": {
      "command": "npx",
      "args": [
        "-y",
        "@yawlabs/mcp-compliance"
      ]
    }
  }
}

터미널에서 이 명령어를 실행하세요

claude mcp add compliance -- npx -y @yawlabs/mcp-compliance

Cursor에서 열기

또는 설정을 직접 복사하기

프로젝트의 .cursor/mcp.json 또는 ~/.cursor/mcp.json에 붙여 넣으세요

{
  "mcpServers": {
    "compliance": {
      "command": "npx",
      "args": [
        "-y",
        "@yawlabs/mcp-compliance"
      ]
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

VS Code에서 열기

또는 설정을 직접 복사하기

프로젝트의 .vscode/mcp.json에 붙여 넣으세요

{
  "servers": {
    "compliance": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@yawlabs/mcp-compliance"
      ]
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.

할 수 있는 일

내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.

기본 점검i

누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 10일 점검

✓ 통과
제작자와 저장소 일치
레지스트리 이름이 GitHub 계정 YawLabs 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요
… 아직 점검 안 함
계속 관리되고 있음
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
… 아직 점검 안 함
라이선스 있음
아직 GitHub에서 이 저장소를 읽어 오지 않았어요
– 해당 없음
엔드포인트 응답
내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요
– 해당 없음
OAuth로 로그인
내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요
… 아직 점검 안 함
도구 설명에 숨겨진 지시 없음
내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요

법률 및 정부 데이터 카테고리의 다른 서버와 비교i

이 카테고리의 다른 서버 1772개 중 0%보다 스타가 많아요
이 카테고리의 다른 서버 1772개 중 71%보다 최근에 레지스트리에 공개됐어요
기본 점검 결과가 이 카테고리의 다른 서버 1772개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

자주 묻는 질문

MCP Compliance, 안전한가요?

해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.

어떤 키나 코드가 필요한가요?

레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.

내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?

내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).

아직 관리되고 있나요?

GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.21.1)은 10일 전 레지스트리에 올라왔어요.

어떤 앱에서 쓸 수 있나요?

Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 Node.js도 있어야 해요.

대신 쓸 수 있는 건 뭐가 있나요?

같은 카테고리에는: LexVira, IUSTORIA – průvodci a právní kalkulačky, Korea Stay

대안

같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.

카드 보는 법:↓ 주간 다운로드i★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i

LexVira

Legal research: search case law and legislation, then retrieve sources with citations.

제작자: lexvira.com초기오늘 업데이트

클라우드에서 실행✓ lexvira.com

설치

IUSTORIA – průvodci a právní kalkulačky

Czech legal calculators, document templates, legal glossary and lawyer-reviewed guides.

제작자: iustoria.cz초기오늘 업데이트

클라우드에서 실행✓ iustoria.cz

설치

Korea Stay

Korean lodging: 84,490 stays from 4 government permit ledgers + KTO TourAPI, honest gaps

제작자: sallim.app초기오늘 업데이트

클라우드에서 실행✓ sallim.app

설치

제작자의 README

README 열기

제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.

@yawlabs/mcp-compliance

One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.

Test any MCP server for spec compliance. Two test suites — 88 tests for MCP 2025-11-25 and 103 tests for MCP 2026-07-28 — covering transport, lifecycle, tools, resources, prompts, error handling, schema validation, and security. The tool probes the server and grades the newest spec revision it speaks, or you pin one with --spec-version. Works against HTTP endpoints (https://my-server.com/mcp) and stdio servers (npx @modelcontextprotocol/server-filesystem /tmp) alike. CLI, MCP server, and programmatic API.

Built and maintained by Yaw Labs.

Why this tool?

MCP servers are multiplying fast — but most ship without compliance testing. Broken transport handling, missing error codes, malformed schemas, and silent capability violations are common. Hand-rolling test scripts is tedious and incomplete.

This tool solves that:

Two spec revisions, one tool — 88 tests for MCP 2025-11-25 (the initialize + session era) and 103 tests for MCP 2026-07-28 (stateless, per-request _meta, server/discover, caching hints, MRTR). Both cover the same 8 categories: transport, lifecycle, tools, resources, prompts, error handling, schema validation, and security. HTTP-specific tests (CORS, TLS, header validation, rate limiting) are gated out on stdio: the 2025-11-25 suite runs 85 tests on HTTP and 55 on stdio, the 2026-07-28 suite 99 and 75.
Auto-detected revision — one server/discover probe tells the tool which era the server speaks; dual-era servers are graded against 2026-07-28 with a warning. Pin either revision with --spec-version. See Spec version.
Capability-driven — tests adapt to what the server declares. If it says it supports tools, tool tests become required. No false failures for features the server doesn't claim.
Graded scoring — A-F letter grade with a weighted score (required tests 70%, optional 30%). One number to communicate compliance.
CI-ready — --strict mode exits with code 1 on required test failures. Drop it into any pipeline.
Spec-referenced — every test links to the exact section of the MCP specification it validates. No ambiguity about what's being tested or why.
Three interfaces — CLI for humans, MCP server for AI assistants, programmatic API for integration.
Published methodology — the testing methodology and rule catalog are open (CC BY 4.0) so anyone can build compatible tooling or fork the rules.

Quick start

Remote HTTP server:

npx @yawlabs/mcp-compliance@latest test https://my-server.com/mcp

Local stdio server (the vast majority of MCP servers on npm):

# Pass the command directly, Inspector-style

npx @yawlabs/mcp-compliance@latest test npx @modelcontextprotocol/server-filesystem /tmp

Or a local build

npx @yawlabs/mcp-compliance@latest test node ./dist/server.js

With env vars

npx @yawlabs/mcp-compliance@latest test -E GITHUB_TOKEN=$GITHUB_TOKEN -- npx @modelcontextprotocol/server-github

Install globally:

npm install -g @yawlabs/mcp-compliance

mcp-compliance test https://my-server.com/mcp

That's it. You'll get a colored terminal report with a letter grade (A-F), per-test pass/fail, and a compliance score.

CLI usage

HTTP targets

# Terminal output with colors and grade

mcp-compliance test https://my-server.com/mcp

JSON / SARIF for scripting + GitHub Code Scanning

mcp-compliance test https://my-server.com/mcp --format json mcp-compliance test https://my-server.com/mcp --format sarif > compliance.sarif

Strict mode for CI — exits 1 on required-test failure

mcp-compliance test https://my-server.com/mcp --strict

Auth (shorthand or full header)

mcp-compliance test https://my-server.com/mcp --auth "Bearer tok123" mcp-compliance test https://my-server.com/mcp -H "X-Api-Key: abc"

Focus the run

mcp-compliance test https://my-server.com/mcp --only transport,lifecycle mcp-compliance test https://my-server.com/mcp --skip prompts,resources mcp-compliance test https://my-server.com/mcp --verbose

stdio targets

Pass the command and its args as positional arguments (MCP Inspector-style). Use -- to disambiguate when the target needs flags that collide with ours.

# npm-distributed stdio servers

mcp-compliance test npx -y @modelcontextprotocol/server-filesystem /tmp mcp-compliance test uvx mcp-server-git

Local build

mcp-compliance test node ./dist/server.js

With env vars (repeatable -E, or --env-file)

mcp-compliance test -E API_KEY=secret -E REGION=us-east-1 -- npx my-server mcp-compliance test --env-file .env -- node ./server.js

Set working directory

mcp-compliance test --cwd ./services/mcp -- node ./dist/server.js

Target uses a flag that collides with ours — use `--` to separate

mcp-compliance test --verbose -- node ./server.js --verbose

On Windows, npx and other .cmd shims are handled automatically by spawning through the shell.

Spec version

The tool ships one test catalog per MCP specification revision it supports — 2025-11-25 (88 tests: initialize handshake, sessions, ping) and 2026-07-28 (103 tests: stateless, per-request _meta, server/discover, caching hints, MRTR). A run grades exactly one revision, chosen by --spec-version:

# auto (default): probe the server, grade the newest revision it speaks

mcp-compliance test https://my-server.com/mcp

pin a revision — no probe, the named catalog runs regardless of what the server answers

mcp-compliance test https://my-server.com/mcp --spec-version 2026-07-28 mcp-compliance test https://my-server.com/mcp --spec-version 2025-11-25

--list never connects: under auto (the default) it prints every catalog in its own

section; --spec-version previews just that one

mcp-compliance test --list --spec-version 2026-07-28 --transport stdio

How auto decides, following the spec's own rules for dual-era clients: the tool sends one conformant 2026-07-28 server/discover (on HTTP it doubles as the preflight connectivity check, so detection costs no extra round-trip; on stdio it is the first exchange). A DiscoverResult, or a JSON-RPC error with a modern code (-32020, -32021, -32022), selects 2026-07-28. Anything else — -32601, -32000, a 400 "not initialized", a 404, an HTML page, or no reply within the timeout — selects 2025-11-25; a 401/403 with no modern error body also lands on 2025-11-25, the note says the era could not be determined, and the report's first warning (in every output format) says the grade below is not meaningful. With no Authorization header configured, a 401, or a 403 carrying a WWW-Authenticate: Bearer challenge, reads as authentication required (note authentication required -- pass --auth; the warning says to re-run with --auth). With one configured, a 401, or a 403 whose Bearer challenge carries an error parameter, reads as the credential rejected (note credential rejected -- check --auth; the warning names the reason from that error, e.g. invalid_token is an invalid or expired token and insufficient_scope a missing scope or permission). Any other 403 (the SDK's Host validation behind a tunnel hostname, Origin validation, a gateway) is worded neutrally with or without a header: the note says forbidden -- Host/Origin validation, a gateway, or missing credentials (or ... or token permissions with a header), and the warning quotes the body's JSON-RPC error message when there is one, points at Host/Origin validation and any gateway first, and without a header suggests --auth only if the server does require a credential. The fallback is deliberately not keyed to a single error code; a legacy server that ignores unknown methods is still classified correctly, just after the timeout. The report header names the reason (auto-detected from server/discover: supportedVersions [2026-07-28], ... JSON-RPC error -32601, legacy, ... no response, legacy) and the JSON warnings carry the same note (Spec version auto-detected as (server/discover -> ). Pin with --spec-version to override.). An unreachable server is graded as 2025-11-25 so every test that needs the server fails (the 2026-07-28 post-hoc scans fail too when nothing was received, rather than passing over an empty recording).

Two budgets bound the probe. On stdio it is bounded by --startup-timeout, and in terminal mode a dim status line appears on stderr after ~2 s naming the wait and the --spec-version 2025-11-25 skip, so a legacy server that stays silent on unknown methods does not look like a hang. If the child exits on the probe (a legacy server whose dispatcher throws on unknown pre-initialize methods), the report warns with the exit code and stderr tail, spawns a fresh instance and grades it as 2025-11-25. If the fresh instance exits at startup as well, before answering initialize, the warning says the server exits at startup regardless of the probe and points at the command, its arguments and its environment instead of suggesting a pin. benchmark re-spawns a probe-killed child the same way, bounds its probe by its own --startup-timeout, prints the same status line, and carries the warning in its output. On HTTP the probe is the preflight and is bounded by --preflight-timeout; a preflight that times out is re-probed once within --startup-timeout before the run defaults to 2025-11-25, so a slow cold start is graded in its real era instead of as unreachable.

A server that answers both eras (the default for servers built on the official SDK 2.0) is graded as 2026-07-28, and the report carries a warning naming the other era and how to pin it — keyed on supportedVersions listing 2025-11-25 *or* on the informational lifecycle-dual-era probe being served an InitializeResult (SDK 2.0 servers advertise only modern versions yet still serve initialize; on stdio that probe goes to a fresh process, since a dual-era server pins its era per process). To grade its legacy side too, run again with --spec-version 2025-11-25. A server that serves initialize while *rejecting* the conformant server/discover is not dual-era but legacy-only: lifecycle-dual-era says legacy-only: ... and the warning tells you to re-run with --spec-version 2025-11-25 (or auto). The report's specVersion is always the resolved revision, never auto.

A pinned run runs the named catalog whatever the server answers, with two honest side notes. On HTTP the preflight is still a modern server/discover, so a pinned run whose server plainly answered in the *other* era gets a warning (Server answered the 2026-07-28 server/discover probe with a DiscoverResult ...; this run is pinned to 2025-11-25. Re-run with --spec-version 2026-07-28 (or auto) to grade it). The warning needs an era signal -- a DiscoverResult, a JSON-RPC body or an HTTP 4xx; a 5xx or an HTML page says nothing about the era and d

앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요

MCP Compliance

개요

PopNx MCP의 세 기둥

할 수 있는 일

설치

설치하기 전에

할 수 있는 일

기본 점검i

제작자와 저장소 일치

계속 관리되고 있음

라이선스 있음

엔드포인트 응답

OAuth로 로그인

도구 설명에 숨겨진 지시 없음

법률 및 정부 데이터 카테고리의 다른 서버와 비교i

자주 묻는 질문

대안

LexVira

IUSTORIA – průvodci a právní kalkulačky

Korea Stay

제작자의 README

@yawlabs/mcp-compliance

Why this tool?

Quick start

Or a local build

With env vars

CLI usage

HTTP targets

JSON / SARIF for scripting + GitHub Code Scanning

Strict mode for CI — exits 1 on required-test failure

Auth (shorthand or full header)

Focus the run

stdio targets

Local build

With env vars (repeatable -E, or --env-file)

Set working directory

Target uses a flag that collides with ours — use -- to separate

Spec version

pin a revision — no probe, the named catalog runs regardless of what the server answers

--list never connects: under auto (the default) it prints every catalog in its own

section; --spec-version previews just that one

Target uses a flag that collides with ours — use `--` to separate