M
MCP Directory CURATED DIRECTORY
911 MCP servers indexed
中文
← Back to directory
COMPARE UP TO 4 SERVERS

Compare MCP servers

Compare scores, permissions, risks, and fit in one decision-focused table.

DimensionMCPJam InspectorOpen-source testing and evaluations platform for MCP server developersMartinLoop MCP ServerAn independent control layer that gives AI coding agents budgets, brakes, and receipts
FMRS58 / 100 · C79 / 100 · B
Reliability8 / 2012 / 20
Security and permissions13 / 2018 / 20
Maintenance11 / 2016 / 20
Documentation13 / 2018 / 20
Setup experience13 / 2015 / 20
Best for
  • Developers building or maintaining MCP servers who need to verify consistent behavior across many clients
  • Teams wanting to add MCP conformance and regression testing to their CI/CD pipeline
  • Developers debugging OAuth/DCR/CIMD authorization flows
  • Developers previewing and iterating on Apps SDK / MCP app widget UIs locally
  • Engineering teams scaling AI coding agents while controlling spend
  • Platform teams that need auditable, rollback-aware agent execution records
  • Organizations using multiple agents (Claude, Codex, Gemini) under one governed flow
Not for
  • End users who just want to plug an MCP server into an assistant client (this is a developer debugging tool, not an end-user MCP server)
  • Users needing hosted-only features like skill sync or tasks in a fully offline environment, since the hosted app is HTTPS-only and some features are local-only
  • Users looking for an MCP server implementation that exposes tools to an AI assistant
  • Developers who just want a simple code-completion helper without run governance
  • Teams unwilling to accept local JSONL run records with HMAC signing
  • Environments without a supported adapter (Claude/Codex/Gemini CLIs, direct provider, or verifier-only)
Required permissions
  • Network access to connect to target MCP servers (local STDIO process or remote HTTP/S endpoint)
  • The local/desktop build launches and communicates with local STDIO subprocesses, i.e. it can execute local commands
  • The OAuth debugger accesses and handles authorization credentials and token exchanges
  • A self-built Docker image binds to a local port (127.0.0.1 by default) requiring local port access
  • Read/write access to the configured repo root (writable scope restrictable via --allow-path/--deny-path)
  • Ability to invoke the chosen agent CLI (Claude/Codex/Gemini, etc.) and its underlying model account
  • Local disk writes for run records, receipts, and share outputs (share/run-receipt., etc.)
  • Execution of user-configured verifier commands (e.g. npm test)
Risks and side effects
  • As a debugging tool it logs and displays full JSON-RPC messages and OAuth exchange details, so logs may contain sensitive tokens or credentials
  • Docker deployments that use `-p 6274:6274` instead of `-p 127.0.0.1:6274:6274` could expose the debugging port publicly
  • The hosted web app cannot be used for STDIO-only servers since it only supports HTTPS endpoints
  • The repository's license field is listed as NOASSERTION even though the README states Apache 2.0 — verify actual license terms before relying on this project
  • Verifier commands are executed; poorly chosen verifier commands carry security risk despite preflight policy checks
  • Cost and token figures may be estimates (labeled with provenance) and should not be treated as settled accounting
  • Receipt integrity must be verified before use as trustworthy evidence; missing rollback evidence is flagged as EVIDENCE_BOUNDARY
  • Policy defaults come from martin.config.yaml and can be overridden by CLI flags; misconfiguration can loosen safety boundaries
Supported clientsClaude Code, Codex, Gemini CLI, Cursor, VS Code, GitHub Copilot, Continue
Tools00