Skip to main content
Glama

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-filesystem

Point 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.

litmus grading npm/@modelcontextprotocol/server-filesystem — five probe steps, then grade: A

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/mcp

or 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, with grade/limit/offset filters 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@polygraphso

then /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 graded

Inputs: 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 fixtures

See 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/dist

Release

@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 tools
run_skill_litmusRun a safety litmus on a Claude Code skillA
Read-only
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
skill_refYesLocal path to a skill directory (must contain SKILL.md). Remote refs are not yet supported in this version.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 attestationA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
server_refYesRegistry-prefixed server identifier, e.g. npm/@scope/server.

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

  1. 2 tool updatesv0.1.15
    • Removedrun_litmus
    • Removedverify_skill_attestation
  2. 4 tool updatesv0.1.0
    • First observedrun_litmus
    • First observedrun_skill_litmus
    • First observedverify_attestation
    • First observedverify_skill_attestation

TDQS

A4.3/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivitySlowing
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that enables easy integration with coding assistants, providing security context to AI agents. This runs locally using the Snyk CLI.
    55
    Apache 2.0
  • A
    license
    A
    quality
    C
    maintenance
    Drop-in security primitives for MCP servers, addressing isError compliance, audit trails, input validation, output sanitization, and OAuth scoping.
    7
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    A 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.
    3
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    A 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

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