Polygraph
OfficialThe Polygraph server lets you grade, verify, and assess the safety and behavioral integrity of MCP servers and Claude Code/Agent Skills.
run_litmus— Actively grade an MCP server (npm ref, HTTPS endpoint, or local file) A–F by running behavioral probes in a sandboxed environment:C-01: Tool-output injection (static, dynamic, second-order)
C-02: Permission/egress overreach
C-03: Sensitive-data handling (planted canaries)
C-04: Adversarial-input handling (malformed/oversized and jailbreak inputs)
Takes ~20–60s; also returns dependency advisories for npm targets.
run_skill_litmus— Statically grade a Claude Code/Agent Skill (A/B/D/F) without executing its code, scanning for:S-01: Prompt injection / context poisoning
S-03: Data-exfiltration instructions
S-04: Dangerous commands in bundled scripts
Also returns an advisory quality signal (well-formed / issues / malformed).
verify_attestation— Instantly retrieve a published behavioral grade (A–F) for an MCP server, including its attestation UID, evidence CID, and graded tool-surface fingerprint, without executing the server.verify_skill_attestation— Retrieve a published static safety grade for an Agent Skill, including its content hash, without execution.check_server— Quickly read a server's published grade as a pre-flight check before recommending or installing it.list_servers— List all servers with a published grade, sorted A-first.request_grade— Queue an ungraded server for free public grading by polygraph.so.CI/CD Integration — Use the provided GitHub Action or CLI command to gate builds, failing them if a server or skill grades D/F or below a specified minimum grade.
Uses Docker to run the target MCP server's code in a sandboxed environment with restricted egress for safe grading.
Provides a GitHub Action for gating CI/CD pipelines based on MCP server grades, and allows grading servers from GitHub repository references.
Allows grading MCP servers published on npm by referencing their npm package identifier.
Can be used as a pre-commit hook to automatically grade MCP servers before committing changes.
Allows grading MCP servers published on PyPI by referencing their PyPI package identifier.
litmus
The open behavioral litmus harness for MCP servers — grade A–F, reproducible.
Grade a server in one command
# -p is required: the package ships three bins, so npx must be told which to run
npx -y -p @polygraphso/litmus polygraphso-litmus litmus npm/@modelcontextprotocol/server-filesystemPoint it at an npm ref, a pypi ref, a github/owner/repo ref (cloned, built, and run sandboxed —
Docker required; the grade pins the commit SHA), an https:// MCP endpoint, or a local entry
file. The harness connects
the way an agent would, fingerprints the exact tool surface, runs the four probe categories, and
prints the grade with the findings behind it — plus a deterministic evidence bundle on disk.
It runs the target's code (egress is Docker-sandboxed; without Docker, C-02 is skipped and the
grade caps at B), takes ~20–60s, and exits non-zero on D/F so it scripts anywhere. To dispute any
published grade, re-run this same command against the same server — open and deterministic means a
re-run reproduces the grade, or refutes it.
Looking up a grade someone already published takes under a second and runs nothing: the
polygraph.so index, or check_server from the MCP tools below.

Related MCP server: mcp-shield
Use it from your agent — MCP server + plugin
For grade lookups, point any MCP client at polygraph's hosted endpoint, no install:
claude mcp add --transport http polygraph https://polygraph.so/api/mcpor the raw config:
{ "mcpServers": { "polygraph": { "url": "https://polygraph.so/api/mcp" } } }This serves the lookup tools only (check_server, list_servers, request_grade); grading a
server yourself (run_litmus, run_skill_litmus) executes its code, so it needs the local
stdio install below.
The package also ships a stdio MCP server (polygraphso-litmus-mcp) with the full toolset, for
any MCP-capable client:
check_server— read a server's published grade in under a second (no execution); the pre-flight check before recommending or installing a server.list_servers— servers with a published grade, A first; paged (default 25 per call, withgrade/limit/offsetfilters and a full-corpus summary).request_grade— record a grade request with polygraph.so ($1 one-time fee; graded within 48h of payment — the response carries the payment link).run_litmus— grade a server now: the full harness, grade + evidence returned to the agent.run_skill_litmus— grade a Claude Code / Agent Skill (static scan, A/B/D/F).verify_attestation— read the onchain proof behind a published grade (EAS on Base).
In Claude Code, the plugin wires the server plus two commands in one step:
/plugin marketplace add polygraphso/litmus
/plugin install polygraph@polygraphsothen /polygraph:grade <server> and /polygraph:check <server>. Cursor and manual JSON setups
are on polygraph.so; full tool docs in
packages/litmus/README.md.
Gate your CI on MCP grades — GitHub Action
Fail a build when an MCP server or an Agent Skill it ships grades D/F under the open
behavioral litmus. For servers it is hybrid — a fast lookup of the published grade, then the harness
when ungraded; for skills it is a fast static scan. Un-gradeable targets warn unless strict.
It's on the GitHub Marketplace as
polygraphso/litmus@v1. For a security gate, pin to a commit SHA rather than the mutable @v1 tag:
# .github/workflows/mcp-gate.yml
name: mcp-gate
on: [pull_request] # NOT pull_request_target — that exposes secrets to fork PRs
permissions:
contents: read
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: polygraphso/litmus@<commit-sha> # pin to a SHA; resolve from the v1 release
with:
# Name the targets explicitly (recommended). Grading runs a server's code,
# so on a public repo prefer an allowlist over discovering PR-controlled config:
servers: |
npm/@modelcontextprotocol/server-filesystem
skills: |
./my-skill
# discover: "true" # opt in to auto-discovery (.mcp.json/.vscode/.cursor) — trusted repos only
# min-grade: B # stricter than the default D/F gate
# strict: "true" # also fail on targets that cannot be gradedInputs: servers · skills · discover (default false) · min-grade · strict · working-directory · version · bearer. Outputs: result · failed · report.
Security. Grading a server runs its code (egress is Docker-sandboxed, but it still executes).
Trigger on pull_request, never pull_request_target. Keep discover off on public repos and name
targets explicitly — auto-discovered config is pull-request-controllable. bearer is sent as an
Authorization header to the target, so pass it only for an explicitly trusted, pinned remote — never
with discovery or on untrusted PRs, and keep it scoped and short-lived.
Not on GitHub? The gate is a plain command — npx @polygraphso/litmus@0.20.0 ci (pin the version) —
so it runs in any CI or as a pre-commit hook. A grade is a measurement, not a guarantee: re-run the
open harness to reproduce any result.
What litmus is
This is the source for @polygraphso/litmus,
the open behavioral litmus harness for MCP servers from polygraph.so.
The harness connects to an MCP server the way an agent would, fingerprints its exact tool surface, and runs four probe categories — C-01 tool-output injection (static, dynamic, and second-order — one tool's output weaponized as another's input), C-02 permission/egress (in a hardened default-deny Docker sandbox, matched host and port), C-03 sensitive-data handling (planted canaries), C-04 adversarial-input handling (malformed/oversized and jailbreak inputs) — then grades the server A–F. A passing grade is a measurement, not a guarantee; the methodology and its disclosed limits are at polygraph.so (the open source here is the ground truth).
Alongside the grade, an npm target's dependency tree is checked against the
osv.dev vulnerability database and any vulnerable dependencies are reported as
dependency advisories. This is a separate, point-in-time signal — it is advisory only: it
never affects the A–F grade and is not part of the reproducible evidence (vulnerability data changes
over time, so folding it into the grade would break re-run reproducibility). It applies to npm
targets only; other target kinds report it as skipped. Resolution runs
npm install --package-lock-only --ignore-scripts, which resolves the tree without downloading
tarballs or running any package code. Opt out with --no-deps-audit (or LITMUS_DEPS_AUDIT=0).
The same package also grades Claude Code / Agent Skills (a SKILL.md + bundle) under a
separate static litmus (litmus-skill-v3): a deterministic byte-scan — S-01 prompt
injection, S-03 data-exfiltration instructions, S-04 dangerous commands in the SKILL.md
body or bundled scripts (incl. base64-obfuscated curl | bash) — graded A/B/D/F and anchored
by a whole-directory content hash, plus a separate
advisory quality signal. It is static (no execution): an A is static-clean, not behavioral
proof. See packages/litmus/README.md.
The hosted, operator-run grading service is not in this repo — it lives in a separate private repo and consumes this package from npm like any other client.
Layout
This is a pnpm monorepo. Only @polygraphso/litmus is published; the
@polygraph/* packages are private building blocks that tsup bundles into it.
packages/
litmus/ # @polygraphso/litmus — the only published package (lib + 3 bins: CLI, skill CLI, MCP)
core/ # contract types, canonical JSON, identity helpers
probes/ # the harness: connect, fingerprint, grade, probe runners, sandbox
onchain/ # EAS attestation read + encode/decode (Base) — read-only, no minting
agent/ # agent-gate decision logic + live-fingerprint recheck
mcp/ # MCP server wrapper
cli/ # CLI commands + target/auth resolution
demo-*-mcp/ # demo MCP servers used as test fixturesSee packages/litmus/README.md for the npm-facing usage docs,
and polygraph.so for the methodology and proof format.
Develop
pnpm install
pnpm -r typecheck
pnpm -r test
pnpm --filter @polygraphso/litmus build # → packages/litmus/distRelease
@polygraphso/litmus is versioned in packages/litmus/package.json. Tag to publish:
git tag litmus-v<x.y.z> && git push origin litmus-v<x.y.z>The Publish @polygraphso/litmus workflow builds, typechecks, tests, and publishes with
npm provenance. See CONTRIBUTING.md for the full process and the
local-development workflow for downstream consumers.
License
Apache-2.0 — © polygraph.so.
Available Tools
2 toolsrun_skill_litmusRun a safety litmus on a Claude Code skillARead-onlyInspect
Grade a Claude Code / Agent Skill A/B/D/F against the open static safety litmus (litmus-skill-v1). A skill is a SKILL.md (instructions + frontmatter) plus an optional bundle. The litmus scans the bytes for S-01 prompt-injection / context-poisoning in the body, S-03 data-exfiltration instructions, and S-04 dangerous commands in bundled executable scripts. It content-hashes the whole directory (the anti-tamper anchor).
The SAFETY letter is a STATIC read: it does NOT execute the skill or its scripts and is fast — therefore NOT behavioral proof. An A means the static checks found no injection, exfil instruction, or dangerous bundled command, not that the skill is safe to run unsupervised. A command a skill constructs or fetches at runtime is not visible to static scanning (a disclosed limit).
It also returns a SEPARATE, advisory quality signal (well-formed / issues /
malformed) — never an A–F letter, never minted, never affecting the safety letter.
Its deterministic checks always run; its optional LLM-judged axes (honesty,
coherence) run only when a judge is available — the host agent's own model via MCP
sampling (no key), or a user-provided OpenAI-compatible key — and are skipped
otherwise.
skill_ref (v1): a LOCAL path to a skill directory containing SKILL.md, e.g. ./skills/my-skill. Remote refs (github//#path, marketplace//) are not yet supported.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_ref | Yes | Local path to a skill directory (must contain SKILL.md). Remote refs are not yet supported in this version. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds extensive behavioral context: it is a static read that does not execute scripts, is fast, and discloses limitations (runtime commands invisible). It also explains the separate 'quality' signal and optional LLM-judged axes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and subsequent details. While every sentence adds value, it is somewhat verbose (multiple paragraphs). A slightly more concise presentation would improve score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose, checks, limitations, and parameter format. It mentions the safety letter and quality signal but does not explicitly describe the return structure. Overall, it provides sufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and explains skill_ref as a local path. The tool description adds further value by specifying the v1 format and explicitly stating that remote refs are not yet supported, clarifying usage constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool grades a skill against the open static safety litmus, specifying the checks (S-01, S-03, S-04) and differentiating it from behavioral execution. It also distinguishes from sibling tools by focusing on skills, while 'run_litmus' is likely more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to statically grade a skill) and notes that remote refs are not supported. It implies the tool is not a full safety assessment by stating it is 'NOT behavioral proof,' but does not explicitly list alternative tools or conditions when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_attestationVerify a server's polygraph attestationARead-onlyIdempotentInspect
Read a server's already-published polygraph (litmus) grade — without running anything — before an agent trusts or, in agentic commerce, pays it.
When a grade is published it returns the behavioral grade (A–F), the attestation UID, the evidence CID, and the graded tool-surface fingerprint. The caller must still recompute the LIVE fingerprint and require it to equal the attested one before paying — a passing attestation can otherwise front for a tool surface the server no longer serves (rug pull).
Grade publishing is still rolling out, so this commonly returns not_available
today: that means UNEVALUATED (neither safe nor unsafe), not a failing grade — to
grade the server yourself right now, use run_litmus. A lookup_failed result
means the lookup itself failed (the index or chain was unreachable); the grade is
unknown, which is not the same as unevaluated.
Input: server_ref — e.g. npm/@modelcontextprotocol/server-filesystem.
| Name | Required | Description | Default |
|---|---|---|---|
| server_ref | Yes | Registry-prefixed server identifier, e.g. npm/@scope/server. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds valuable context: it explains the tool does not run anything, describes return fields (grade, UID, CID, fingerprint), discloses that grade publishing is rolling out so 'not_available' is common, and clarifies error semantics. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured paragraph. It front-loads the core purpose, then explains results, error handling, and ends with a parameter example. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains return values (grade, UID, CID, fingerprint) and handles two special cases ('not_available' and 'lookup_failed'). Given the complexity of attestation verification, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'server_ref', but the description adds a concrete example and explains it's a registry-prefixed identifier, going beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a published polygraph grade without running anything, specifying the verb 'read' and the resource 'server's polygraph attestation'. It distinguishes from sibling 'run_litmus' by stating when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use before trusting/paying, use 'run_litmus' if grade is not published, and explains how to interpret results like 'not_available' vs 'lookup_failed'. Also warns about needing to recompute live fingerprint to prevent rug pull.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.1.15- Removed
run_litmus - Removed
verify_skill_attestation
4 tool updates
v0.1.0- First observed
run_litmus - First observed
run_skill_litmus - First observed
verify_attestation - First observed
verify_skill_attestation
TDQS
The two tools target distinctly different objects: one reads published attestations for servers, the other grades skills. Their descriptions clearly differentiate their purposes and use cases, leaving no ambiguity.
Both tool names follow an underscore-separated verb_noun pattern, but the verbs differ (verify vs. run) and the nouns are not parallel (attestation vs. skill_litmus). Minor inconsistency, but overall predictable.
With only 2 tools, the server is at the lower end of what is reasonable. While the scope is focused, the inclusion of a third tool (e.g., run_litmus for servers) would improve coverage without bloat.
The description of verify_attestation mentions a run_litmus tool for server grading that is not present, and there is no tool for publishing attestations. These gaps mean agents cannot perform the full workflow implied by the server's purpose.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
MCP-native AI evaluation: rubric audits, eval suites, and proof reports for AI/LLM output.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
The evidence layer for MCP: live operational grades plus Trust Receipts for every registry server.
Related MCP Servers
AlicenseNot gradedqualityAmaintenanceAn MCP server that enables easy integration with coding assistants, providing security context to AI agents. This runs locally using the Snyk CLI.55Apache 2.0- AlicenseAqualityCmaintenanceDrop-in security primitives for MCP servers, addressing isError compliance, audit trails, input validation, output sanitization, and OAuth scoping.7MIT
- AlicenseAqualityDmaintenanceA compact MCP server demonstrating explicit tool boundaries, least-privilege discovery, execution-time authorization, destructive-action confirmation, and metadata-only audit logs using a local note store.3MIT
- FlicenseNot gradedqualityDmaintenanceA governed MCP server exposing 37 risk-checked tools with signed Ed25519 receipts on a Bitcoin-anchored ledger, failing closed if governance or receipt writing fails.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/polygraphso/litmus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server