What can you do with this server?

The Proof of Commitment MCP server provides supply chain risk auditing and behavioral commitment scoring for software packages, GitHub repositories, Norwegian businesses, and web domains — surfacing trust signals that are harder to fake than stars, downloads, or reviews. All tools return scores (0–100) based on behavioral signals. * Audit dependencies (audit_dependencies): Batch-score up to 20 npm or PyPI packages for supply chain risk, with prioritized flags like CRITICAL (sole publisher + high downloads), HIGH (new package with rapid adoption), and WARN (no recent releases). * Lookup individual packages: Get detailed behavioral profiles (age, download trends, release consistency, publisher/contributor counts, linked GitHub activity) for npm, PyPI, Cargo (Rust), and Go modules. * Lookup GitHub repos (lookup_github_repo): Evaluate commitment signals — project longevity, commit frequency, contributor community size, and release cadence. * Lookup Norwegian businesses (lookup_business / lookup_business_by_org): Search by name or 9-digit organization number for operating years, revenue, profitability, employee count, and equity health from public registers. * Query domain commitment (query_commitment): Get verified human engagement data for any website — unique verified visitors, repeat visit rate, and average time spent. * Monitor packages over time: Track behavioral commitment scores and receive alerts if a package's risk profile degrades (requires API key). * Generate README badges: Create dynamic commitment trust badges for npm, PyPI, Cargo, and Go packages. * CI/CD and IDE integration: Automate audits in GitHub Actions (SARIF reports, PR comments, build failures) and hook into AI coding assistants like Cursor, Claude Code, and Windsurf to warn about risky packages during install commands.

de en es ja ko ru zh

proof-of-commitment

by piiiico

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Used as the technology stack for the landing page, but the MCP server itself provides behavioral scoring for npm/PyPI packages rather than direct Astro integration.

Provides behavioral commitment scoring and supply chain risk auditing for the Axios npm package, analyzing maintainer depth, download trends, and risk flags like CRITICAL status.

Used as the runtime environment for local development and deployment of the MCP server, but not a target service for the server's behavioral scoring capabilities.

Provides the hosting infrastructure (Cloudflare Workers) and edge caching for the MCP server backend and badge API endpoints.

Hosts the landing page for the Proof of Commitment web tool, while the MCP server itself runs on Cloudflare Workers.

Serves as the backend platform for the MCP server, handling API requests, badge generation, and behavioral data processing.

Provides behavioral commitment scoring and supply chain risk auditing for the Express npm package, analyzing maintainer count, download volume, and risk assessment.

Provides commitment scoring for GitHub repositories through the lookup_github_repo tool, analyzing longevity, commit frequency, and contributor depth.

Provides behavioral commitment scoring and supply chain risk auditing for the LangChain PyPI package as part of the proof-of-commitment tool's capabilities.

Provides behavioral commitment scoring and supply chain risk auditing for the Lodash npm package, analyzing maintainer count, download trends, and risk assessment.

Used for formatting audit results in PR comments and documentation, but not a target service for behavioral scoring.

Mentioned in the broader vision section as a card network identifying behavioral trust gaps, but not directly integrated with the MCP server's tools.

The primary ecosystem targeted for behavioral scoring of npm packages, with specific examples like chalk, zod, and axios analyzed for supply chain risk.

Provides behavioral scoring and risk auditing for npm packages through multiple tools including audit_dependencies and lookup_npm_package, analyzing download trends, maintainer depth, and release consistency.

Provides behavioral scoring and risk auditing for PyPI packages through tools including audit_dependencies and lookup_pypi_package, analyzing Python package ecosystems for supply chain risks.

Used as the local database (D1) for development and data storage in the Cloudflare Workers backend, but not a target service for behavioral scoring.

Mentioned as an example query target ('Is vercel/ai actively maintained?') for GitHub repository behavioral scoring through the MCP tools.

Mentioned in the broader vision section as a card network identifying behavioral trust gaps (Visa TAP), but not directly integrated with the MCP server's tools.

Used for GitHub Actions workflow configuration, but not a target service for the MCP server's behavioral scoring capabilities.

Provides behavioral commitment scoring and supply chain risk auditing for the Zod npm package, analyzing maintainer depth, download volume, and CRITICAL risk flags.

Proof of Commitment

Commitment Score npm downloads

Stars lie. Behavioral signals don't.

An MCP server and web tool that scores npm packages, PyPI packages, Rust crates, Go modules, and GitHub repos on behavioral commitment — signals that are harder to fake than stars, READMEs, or download counts.

$ npx proof-of-commitment axios zod chalk lodash minimatch
Scoring 5 npm packages... done in 3.0s

Package      Risk          Score   Publishers   Downloads      Age    Provenance
chalk        🔴 CRITICAL   72      1            432.9M/wk      14.6y  —
minimatch    🔴 CRITICAL   78      1            634.1M/wk      14.9y  —
lodash       🔴 CRITICAL   80      1            158.9M/wk      14.1y  —
zod          🔴 CRITICAL   83      1            161.2M/wk      6.3y   🔐 verified
axios        🔴 CRITICAL   88      1            115.7M/wk      11.8y  🔐 verified
                ⚠ COMPROMISED — axios token theft (2026-03-30)

⚠  5 CRITICAL packages found.
   CRITICAL = sole npm publisher + >10M weekly downloads (publish-access concentration risk)

npm audit flags none of these. They're not vulnerabilities — they're attack-surface concentration. One stolen npm token, one phished maintainer, and a single push reaches the whole ecosystem (axios, March 30 2026 — happened).

The supply chain problem

26 of the 91 npm packages with >10M weekly downloads have a single npm publisher. Together they account for over 3 billion downloads per week. npm audit doesn't surface this. Stars don't either.

Four packages in a typical Node.js project are CRITICAL right now:

chalk — 432M downloads/week, 1 npm publisher
zod — 185M downloads/week, 1 npm publisher (30+ GitHub contributors)
lodash — 156M downloads/week, 1 npm publisher
axios — 113M downloads/week, 1 npm publisher (attacked March 30, 2026)

They won't appear in your package.json either — but these are in almost every project:

minimatch — 625M downloads/week, 1 npm publisher
glob — 366M downloads/week, 1 npm publisher
cross-spawn — 215M downloads/week, 1 npm publisher

Behavioral signals surface this. Stars and READMEs don't.

Related MCP server: @4da/mcp-server

Quick install (MCP)

No login required. Add to any MCP-compatible AI tool and start querying supply chain risk.

Claude Desktop

Open ~/Library/Application Support/Claude/claude_desktop_config.json on macOS (config file reference) or %APPDATA%\Claude\claude_desktop_config.json on Windows, then add:

{
  "mcpServers": {
    "commit": {
      "type": "streamable-http",
      "url": "https://poc-backend.amdal-dev.workers.dev/mcp"
    }
  }
}

Restart Claude Desktop. A tool icon appears in the chat input — ask it to audit your package.json.

Cursor

Open ~/.cursor/mcp.json (Cursor MCP docs) and add:

{
  "mcpServers": {
    "commit": {
      "type": "streamable-http",
      "url": "https://poc-backend.amdal-dev.workers.dev/mcp"
    }
  }
}

Smithery (once indexed)

npx -y @smithery/cli install proof-of-commitment --client claude

Try it now

Terminal (zero install):

# New in v1.8.0: zero-arg auto-detect — cd into any project, run once:
npx proof-of-commitment
# Picks the highest-coverage manifest in cwd (package-lock.json > yarn.lock >
# pnpm-lock.yaml > pnpm-workspace.yaml > package.json; requirements.txt;
# Cargo.toml; go.sum > go.mod). When multiple ecosystems are present, the
# file with the most recent mtime wins.

# Explicit package list still works:
npx proof-of-commitment axios zod chalk

# Or point at a specific file:
npx proof-of-commitment --file package.json
npx proof-of-commitment --file package-lock.json   # npm (transitive)
npx proof-of-commitment --file yarn.lock           # yarn
npx proof-of-commitment --file pnpm-lock.yaml      # pnpm
npx proof-of-commitment --file pnpm-workspace.yaml # pnpm monorepo
npx proof-of-commitment --pypi litellm langchain requests
npx proof-of-commitment --cargo serde tokio reqwest
npx proof-of-commitment --golang github.com/gin-gonic/gin golang.org/x/net
npx proof-of-commitment --file go.mod
npx proof-of-commitment --file go.sum              # full transitive Go set

# JSON output for downstream tools:
npx proof-of-commitment --file package-lock.json --json | jq '.criticalCount'

CI integration (v1.8.0+)

--fail-on=<level> turns the CLI into a one-line CI gate. No GitHub Action required.

# .github/workflows/supply-chain.yml
name: Supply Chain
on: [pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npx -y proof-of-commitment --fail-on=critical

Levels:

`--fail-on`	Exit 1 when…
`critical`	any package is flagged CRITICAL (publish-access concentration)
`risky`	any package is CRITICAL or HIGH (score < 40)
`none`	never — report only

Defaults: critical in CI (when CI=true is set, which every major CI runner does) and for --json output. Interactive (TTY, non-CI) keeps the v1.7 default of exit 0 — running locally won't break your shell habits.

The dedicated piiiico/commit-action@v1 is still the right choice when you want PR comments and step summaries; --fail-on is for minimal pipelines that just need a yes/no answer.

SARIF output for GitHub Code Scanning (v1.26.0+)

--sarif outputs SARIF 2.1.0 — the standard format for static analysis results. Upload it to GitHub Code Scanning and Commit findings appear in the Security tab alongside CodeQL and Snyk.

# .github/workflows/supply-chain.yml
name: Supply Chain
on: [pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npx -y proof-of-commitment --file package-lock.json --sarif --fail-on=none > results.sarif
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: results.sarif
          category: commit-supply-chain

CRITICAL and HIGH packages show as alerts in the repo's Security tab. Compromised packages (in the Commit incident registry) get a separate alert. --fail-on still controls the exit code independently — use --fail-on=critical to also block the PR.

Web demo (no install): getcommit.dev/audit — paste your packages, see risk scores in seconds.

IDE Hooks (Cursor + Claude Code + Windsurf)

poc hook installs a supply chain gate for Cursor (beforeShellExecution), Claude Code (PreToolUse), and Windsurf (pre_run_command) in one command. The same hook script intercepts package installs from any agent, auto-detects which client called it, and blocks CRITICAL packages before they run.

# Install for the current project (writes .cursor/hooks.json + .claude/settings.json + .windsurf/hooks.json):
poc hook

# Or protect every project for your user:
poc hook --global

# Narrow to one client:
poc hook --cursor          # only .cursor/hooks.json
poc hook --claude-code     # only .claude/settings.json
poc hook --windsurf        # only .windsurf/hooks.json

# Remove (cleans all three):
poc hook --uninstall

The hook writes .cursor/hooks.json, .claude/settings.json, and .windsurf/hooks.json (project) or the equivalents under ~/ (with --global). When Cursor, Claude Code, or Windsurf runs npm install axios, pip install litellm, cargo add serde, or go get github.com/gin-gonic/gin, the hook calls the Commit API and either blocks, warns, or allows — in under 500ms.

What gets intercepted:

Package manager	Example command
npm / npx	`npm install <pkg>`, `npm add <pkg>`
pnpm	`pnpm add <pkg>`
yarn	`yarn add <pkg>`
pip / pip3 / uv	`pip install <pkg>`
cargo	`cargo add <pkg>`, `cargo install <pkg>`
go	`go get <module>`, `go install <module>`

Why this matters: Supply chain attacks now happen in minutes. The Shai-Hulud worm (May 2026) compromised 637 packages in 39 minutes and specifically targeted AI coding assistants — planting persistence hooks in .claude/settings.json and .vscode/tasks.json. When your AI assistant installs a dependency, it bypasses the human review that used to be the last line of defense. poc hook puts a gate back in — same gate, whether Cursor, Claude Code, or Windsurf is driving.

Default behavior: CRITICAL packages (sole npm publisher + >10M downloads/week — the exact LiteLLM/axios attack profile) are blocked. HIGH packages trigger an "ask user" prompt (Cursor/Claude Code) or are blocked with a message (Windsurf). Set COMMIT_HOOK_SEVERITY_BLOCK=HIGH to block both.

With an API key: poc login sk_commit_… before running poc hook — the key is embedded in the hook config and lifts the rate limit.

Get notified before the next attack

The CLI tells you what's risky today. A free API key unlocks monitoring — score recomputation across the packages you depend on, with alerts when one degrades (publisher drops, release stalls, score falls ≥10 points).

Open (free): Watch 3 packages · weekly digest every Monday
Developer ($15/mo): Watch 15 packages · daily scans · instant email alerts

Get a free API key → (no card, 30 seconds · 200 audits/day included)

npm install -g proof-of-commitment   # then:
poc watch axios --email you@company.com  # free key + monitoring in one step
poc watch chalk                          # add more packages (3 free)
poc init                                 # add CI gate to this repo

GitHub Action

Add supply chain auditing to any CI pipeline in 30 seconds — auto-detects packages from package.json or requirements.txt, posts results as a PR comment, writes to GitHub Step Summary, and optionally fails on CRITICAL packages.

Use the dedicated action at piiiico/commit-action:

# .github/workflows/supply-chain.yml
name: Supply Chain Audit
on:
  pull_request:
    paths: ['package.json', 'package-lock.json', 'bun.lock']

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: piiiico/commit-action@v1
        with:
          fail-on-critical: true   # blocks merges on CRITICAL packages
          comment-on-pr: true      # posts results as a PR comment

When comment-on-pr: true (default), the action automatically posts the audit table as a comment on the pull request — and updates the same comment on re-run, so you don't get comment spam. Reviewers see the risk table without leaving the PR.

Inputs:

Input	Default	Description
`packages`	(auto)	Comma-separated package names (auto-detected from `package.json`/`requirements.txt` if not set)
`packages-file`	(auto)	Path to `package.json` or `requirements.txt` (default: auto-detect in workspace root)
`fail-on-critical`	`true`	Fail the workflow if CRITICAL packages are found
`max-packages`	`20`	Max packages to audit when auto-detecting
`include-dev-dependencies`	`false`	Include `devDependencies` from `package.json`
`comment-on-pr`	`true`	Post audit results as a PR comment (requires `pull-requests: write` permission)
`api-key`	(none)	Commit Pro API key — enables batch requests and 10K requests/month
`api-url`	(prod)	Override API endpoint (useful for self-hosting)

Outputs: has-critical, critical-count, audit-summary (markdown table, also written to Step Summary).

Free vs Pro: Without an API key, packages are audited one at a time (with delays to respect rate limits). With a Pro API key, all packages are audited in a single batch request — faster and with higher monthly limits.

Example PR comment / Step Summary output:

| Package | Risk        | Score | Publishers | Downloads/wk | Age   |
|---------|-------------|-------|------------|--------------|-------|
| chalk   | 🔴 CRITICAL | 75    | 1          | 380M         | 12.7y |
| zod     | 🔴 CRITICAL | 83    | 1          | 133M         | 6.1y  |
| axios   | 🔴 CRITICAL | 89    | 1          | 93M          | 11.6y |

README Badges

Add a Commit Trust badge to any npm package you maintain or depend on:

![Commit Trust](https://poc-backend.amdal-dev.workers.dev/badge/YOUR-PACKAGE)

Examples:

Package	Badge URL
chalk	`![Commit Trust](https://poc-backend.amdal-dev.workers.dev/badge/chalk)`
react	`![Commit Trust](https://poc-backend.amdal-dev.workers.dev/badge/react)`
express	`![Commit Trust](https://poc-backend.amdal-dev.workers.dev/badge/express)`
@babel/core	`![Commit Trust](https://poc-backend.amdal-dev.workers.dev/badge/@babel/core)`

Grades: 🟢 OK (75+) · 🟠 WARNING (40–74) · 🔴 CRITICAL (<40 or sole npm publisher with 10M+ weekly downloads)

Badges are cached 1 hour. No API key needed.

Also supports PyPI, Cargo, Go modules, and the full ecosystem-specific format:

![commit score](https://poc-backend.amdal-dev.workers.dev/api/badge/npm/YOUR-PACKAGE)
![commit score](https://poc-backend.amdal-dev.workers.dev/api/badge/pypi/YOUR-PACKAGE)
![commit score](https://poc-backend.amdal-dev.workers.dev/api/badge/cargo/YOUR-CRATE)
![commit score](https://poc-backend.amdal-dev.workers.dev/api/badge/golang/github.com/owner/repo)

REST API

No API key. No install.

curl https://poc-backend.amdal-dev.workers.dev/api/audit \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"packages": ["axios", "zod", "chalk", "lodash", "express"]}'

{
  "count": 5,
  "results": [
    {
      "name": "chalk",
      "ecosystem": "npm",
      "score": 75,
      "maintainers": 1,
      "weeklyDownloads": 398397580,
      "ageYears": 12.7,
      "trend": "stable",
      "riskFlags": ["CRITICAL"],
      "scorecardScore": 3.6,        // null if no GitHub repo
      "hasDangerousWorkflow": false  // null if no Scorecard data
    },
    ...
  ]
}

12 MCP tools

Tool	Description
`audit_dependencies`	Batch risk audit for up to 20 npm/PyPI/Cargo/Go packages
`audit_github_repo`	Fetch a repo's package.json/requirements.txt and audit every dep
`audit_dependency_tree`	Map an npm package's full dependency tree (incl. transitive CRITICAL deps)
`lookup_npm_package`	Single npm package behavioral profile
`lookup_pypi_package`	Single PyPI package behavioral profile
`lookup_cargo_crate`	Single Rust crate behavioral profile (crates.io)
`lookup_go_module`	Single Go module behavioral profile (proxy.golang.org + GitHub)
`lookup_github_repo`	GitHub repo commitment score (longevity, commit frequency, contributor depth)
`lookup_business`	Norwegian business register — operating years, employees, financials
`lookup_business_by_org`	Same, by org number
`query_commitment`	Browser extension behavioral data (unique verified visitors, repeat rate)
`get_api_key`	Create a free API key in-chat — no browser needed, key returned instantly

Anonymous: 15 requests/IP/UTC day across both /mcp and /api/audit. Free key (no card, 30s signup at https://getcommit.dev/get-started): 200/day. Higher tiers at https://getcommit.dev/pricing.

What the score measures

Each package is scored 0–100 across:

Longevity — How long has the package existed? Abandoned packages get reactivated for attacks.
Publisher depth — Single npm publisher + millions of weekly downloads = the attack surface LiteLLM exploited. (Publisher = person with npm publish access, distinct from GitHub contributors.)
Release consistency — Regular releases signal active oversight. Long gaps = vulnerability accumulation.
Download trend — Growing packages attract more scrutiny (and attacks). Stable = lower profile.
OpenSSF Scorecard — Process security (code review enforcement, branch protection, CI/CD safety). Separate from behavioral signals. High Scorecard ≠ safe from credential theft attacks.

Both axios (8.1/10 Scorecard) and chalk (3.6/10 Scorecard) score CRITICAL on behavioral signals. They measure different attack surfaces — Scorecard catches process gaps, behavioral signals catch publisher concentration.

Risk flags:

CRITICAL — single npm publisher + >10M weekly downloads (exact LiteLLM/axios attack profile)
HIGH — package <1yr old + rapid adoption
WARN — no release in 12+ months

Real data points

# packages you know about:
chalk       — score 75, 1 publisher, 432M/week  ⚑ CRITICAL
zod         — score 83, 1 publisher, 185M/week  ⚑ CRITICAL  (30+ GitHub contributors)
lodash      — score 81, 1 publisher, 156M/week  ⚑ CRITICAL
axios       — score 88, 1 publisher, 113M/week  ⚑ CRITICAL  (attacked Mar 30 2026)
express     — score 90, 5 publishers, 95M/week

# packages probably not in your package.json, definitely in your lock file:
minimatch   — score 78, 1 publisher, 625M/week  ⚑ CRITICAL
glob        — score 80, 1 publisher, 366M/week  ⚑ CRITICAL
cross-spawn — score 72, 1 publisher, 215M/week  ⚑ CRITICAL

# post-attack:
litellm     — score 74, 1 publisher            ⚑ CRITICAL  (supply chain attack Mar 2026)

# Rust crates (new in v1.3.0):
serde       — score 78, 1 owner,  13M/week  ⚑ CRITICAL  (dtolnay sole owner)
tokio       — score 89, 2 owners, 10M/week
reqwest     — score 85, 1 owner,   8M/week  ⚑ HIGH

Why behavioral signals

The LiteLLM attack (March 2026) and axios attack (March 30, 2026) followed the same pattern: stolen credentials → malicious package pushed → 97M+ machines exposed. Both packages scored CRITICAL by these metrics before the attacks.

Declarative signals (stars, README quality, CI badges) don't capture this risk. Behavioral commitment does.

Blog

The LinkedIn Backdoor: Why npm audit Missed a 250-Line Attack — A fake recruiter clone attack hid malware in test files and ran it via npm lifecycle scripts. npm audit: silent. What behavioral signals would have flagged.
Axios Attack Prediction — We flagged axios as CRITICAL (sole npm publisher, 113M downloads/week) before the March 30, 2026 token theft.

Stack

Layer	Technology
Backend	Cloudflare Workers + D1
MCP	Model Context Protocol SDK
Data	npm registry, PyPI, crates.io, proxy.golang.org, deps.dev, GitHub API, Brønnøysund (NO)
Landing	Astro + Cloudflare Pages

Roadmap

Planned, not promised. The project is early-stage — contributions welcome on any of these.

Feature	Status	Notes
Cargo (Rust) registry support	✅ Live	MCP tool, REST API, badge endpoint — `ecosystem: "cargo"`
Go modules support	✅ Live	proxy.golang.org + deps.dev + GitHub-primary scoring — `ecosystem: "golang"`
Score breakdown visualization	Planned	Chart component for the 5 dimensions on getcommit.dev/audit
`--json` flag for CLI	✅ Live	`npx proof-of-commitment --file package-lock.json --json \| jq '.criticalCount'`
pnpm workspace monorepo support	✅ Live	`--file pnpm-workspace.yaml` or auto-detected from `pnpm-lock.yaml`
Historical score tracking	Planned	Trend charts — was this package getting riskier over time?
Org-level dashboards	Planned	Aggregate risk view across all repos in a GitHub org

See open issues for things you can help with today.

The broader vision

Supply chain auditing is the first tool. The underlying primitive is a commitment graph — behavioral signals that replace content-based trust across any domain.

When content is free to fake (reviews, stars, READMEs), commitment becomes the signal. A publisher who has shipped 847 releases over 12 years is a different kind of commitment than one who published once in 2023.

The same logic applies to websites, businesses, and AI agents. Two card networks have independently named this gap: Mastercard Verifiable Intent §9.2 explicitly lists behavioral trust as "not covered." Visa TAP identifies agents without answering whether to trust them.

Proof of Commitment is the trust layer they're pointing at.

→ getcommit.dev

Run locally

bun install
bun run dev:backend     # local server with SQLite
bun run test:e2e        # E2E test with mock World ID

Deploy:

bun run deploy          # deploys to Cloudflare Workers

Releasing

Publish is triggered automatically when a tag v* is pushed, or manually via GitHub Actions workflow_dispatch.

Funnel smoke gate

Before npm publish runs, the CI workflow executes scripts/funnel-smoke.sh — a local-mock pre-publish check that exercises four key funnel paths:

Path	What it tests	Bug class caught
A	CLI audit with `COMMIT_API_KEY` set → 200 + results	v1.20.0: missing `Authorization` header → 0 paid conversions
B	CLI audit anonymous, 429 → message + `instant_key_url`	429 handling / CTA surfacing
C	cursor-hook (Cursor stdin) 429 → `permission: ask` + signup URL	v1.21.0: silent `allow` on 429 → security gap + 0 conversions
D	cursor-hook (Claude Code `PreToolUse` stdin) 429 → `hookSpecificOutput.permissionDecision: ask` + `claude-code-hook-429` attribution	v1.22.0: wrong-shape reply when Claude Code drives → silent allow / mis-attributed conversion

Any path failure blocks the release. The gate runs a local Python mock server so it's deterministic in CI and doesn't depend on production rate-limit state.

Optional CI secret: Set COMMIT_TEST_API_KEY in GitHub repo secrets to use a real API key for Path A. Falls back to a mock key that the local server accepts unconditionally.

Run locally:

bash scripts/funnel-smoke.sh

Available Tools

8 tools

audit_dependenciesAInspect

Batch-score multiple npm or PyPI packages for supply chain risk. Takes a list of package names and returns a risk table sorted by commitment score (lowest = highest risk first).

Risk flags:

CRITICAL: single npm publisher + >10M weekly downloads (publish-access concentration risk)
HIGH: new package (<1yr) + high downloads (unproven, rapid adoption = supply chain risk)
WARN: no release in 12+ months (potential abandonware)

Perfect for auditing a full package.json or requirements.txt — paste your dependency list and get a prioritized risk report.

Examples: score all deps in a project, compare two similar packages, identify abandonware before it becomes a CVE.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes	List of package names to score. Up to 20 at once. Examples: ["langchain", "litellm", "openai", "axios"] or ["@anthropic-ai/sdk", "zod", "express"]
`ecosystem`	No	Package ecosystem. "auto" defaults to npm. Force "pypi" for Python packages.	auto

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully explains the risk flag criteria (CRITICAL, HIGH, WARN), sorting by commitment score, and batch size constraints (up to 20 packages). It lacks explicit read-only safety confirmation but is otherwise transparent.

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 a summary, risk definitions, and examples. It is concise and front-loaded, though slightly verbose in the examples section.

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?

Given the tool's simplicity (2 params, no output schema), the description fully explains input, output format, risk logic, and usage scenarios. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond what the schema provides, but the schema is clear.

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 specifies the verb 'batch-score', the resource 'multiple npm or PyPI packages', and the outcome 'supply chain risk' with a risk table. It clearly distinguishes from sibling tools that perform single-package lookups.

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 provides explicit use cases like auditing package.json or requirements.txt, and examples of applications. However, it does not explicitly state when not to use this tool, though the batch nature implies it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_businessBInspect

Search for a Norwegian business and get its commitment profile from public data (Brønnøysund Register Centre). Returns real commitment signals that can't be faked:

Temporal commitment: how long the business has operated
Financial commitment: revenue, profitability, equity health
Operational commitment: employee count, active status
Overall commitment score (0-100)

Data source: Norwegian government registers (Brreg). No user-contributed data needed — immediate trust verification for any Norwegian business.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Business name to search for (e.g. 'Peppes Pizza', 'Equinor')
`maxResults`	No	Maximum number of results to return (default: 3)

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the data source (Brreg) and the categories of commitment signals, but lacks details on edge cases (e.g., business not found, rate limits, required permissions).

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 a single paragraph with front-loaded purpose. It is concise but includes some marketing language ('can't be faked') that slightly reduces efficiency. Overall, it is well-structured for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain return values. It lists the commitment categories, which is helpful, but omits details on output format, error handling, pagination, and data freshness. It is moderately complete but not fully sufficient for all agent needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description does not add substantial semantic value beyond the schema; it mentions the query parameter implicitly but does not enrich the meaning of 'maxResults' or provide additional constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for a Norwegian business and returns its commitment profile from public data. It specifies the verb 'search' and the resource 'Norwegian business', but does not explicitly distinguish from the sibling tool 'lookup_business_by_org'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for verifying Norwegian businesses via government registers and lists the return data. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'lookup_business_by_org' or 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.

lookup_business_by_orgAInspect

Look up a specific Norwegian business by organization number and get its commitment profile from public data (Brønnøysund Register Centre). Returns real commitment signals: longevity, financial health, operational activity, and overall commitment score.

ParametersJSON Schema

Name	Required	Description	Default
`orgNumber`	Yes	Norwegian organization number (9 digits, e.g. '984388659')

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explicitly states the tool performs a lookup from public data (Brønnøysund Register Centre), implying read-only and non-destructive behavior. This is sufficient for transparency, though it does not detail any caveats like rate limits or data freshness.

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 a single sentence that efficiently conveys purpose, input, and output. It is front-loaded and contains no redundant information, earning its place. However, it could be slightly more structured (e.g., separate sentence for output details).

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 simple lookup tool with one parameter and no output schema, the description adequately explains the input and the expected return values (four signals). It is complete enough for an agent to understand what results to expect, though adding a brief note on the format of the returned data would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters (orgNumber) with description. The tool description adds context about what the parameter is used for (Norwegian organization number) and example format, but essentially repeats schema info. Baseline 3 is appropriate as schema already does the heavy lifting.

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 action (lookup), the resource (Norwegian business by organization number), and the output (commitment profile with specific signals: longevity, financial health, operational activity, overall commitment score). It distinguishes itself from sibling tools like lookup_github_repo or lookup_npm_package by focusing on Norwegian businesses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when needing commitment profile for a Norwegian business), but it does not explicitly state when not to use it or provide direct comparison to sibling tools such as lookup_business or query_commitment. Usage context is clear but lacks explicit alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_github_repoAInspect

Get a behavioral commitment profile for any public GitHub repository. Returns real signals: how long the project has existed, recent commit frequency, contributor community size, release cadence, and social proof. These are behavioral commitments — harder to fake than README claims.

Useful for: vetting open-source dependencies, evaluating AI tools/frameworks, assessing vendor reliability. Examples: "vercel/next.js", "facebook/react", "https://github.com/piiiico/proof-of-commitment"

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes	GitHub repository in "owner/repo" format or full URL. Example: "vercel/next.js"

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool is read-only ('Get' and 'Returns'), works only with public repos, and describes the nature of the returned signals (behavioral commitments). It does not mention rate limits or authentication, but the read-only nature is clear.

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 a first paragraph explaining functionality and a second paragraph for use cases and examples. It is concise without redundant words, but could be slightly tighter.

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?

Given the low complexity (one parameter, no nested objects), the description fully covers what the tool does, what it returns, and when to use it. No output schema is present, but the listed signals provide adequate expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the 'repo' parameter's description already explaining the format and providing an example. The tool description repeats the example without adding new meaning beyond the schema, so baseline of 3 is appropriate.

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 it gets a 'behavioral commitment profile' for any public GitHub repository and lists the returned signals. It distinguishes itself from sibling tools which cover different domains (business, npm, Go modules, etc.).

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 explicitly lists use cases: 'vetting open-source dependencies, evaluating AI tools/frameworks, assessing vendor reliability.' It provides examples but does not specify when not to use or mention alternatives. Since siblings cover other package types, the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_go_moduleAInspect

Get a behavioral commitment profile for any Go module on proxy.golang.org. Takes a full module path (e.g., "github.com/gin-gonic/gin", "golang.org/x/net", "k8s.io/client-go", "gopkg.in/yaml.v3") and returns real signals: module age, version count, publish cadence, GitHub contributors (the closest equivalent to "publishers" since Go has no centralized publisher concept — git push access is the publish equivalent), GitHub stars, OpenSSF Scorecard score.

The Go ecosystem has no centralized download counter, so this profile is GitHub-primary — the linked source repository's activity, contributor count, and Scorecard carry more weight than for npm/PyPI/Cargo. Stars are used as the popularity proxy.

Useful for: vetting Go dependencies before adding to go.mod, identifying abandonware, supply chain risk assessment. Examples: "github.com/gin-gonic/gin", "golang.org/x/crypto", "github.com/spf13/cobra", "k8s.io/api"

ParametersJSON Schema

Name	Required	Description	Default
`module`	Yes	Full Go module path. Must include the host. Examples: "github.com/gin-gonic/gin", "golang.org/x/net", "k8s.io/client-go", "gopkg.in/yaml.v3". Case-sensitive.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: input constraints, return signals, and ecosystem nuances (no download counter, GitHub-primary). No contradictions.

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?

Well-structured with separate paragraphs for output, ecosystem notes, and usage; not overly verbose. A bit lengthy but justified by the need to explain Go ecosystem specifics.

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 lacking output schema, the description enumerates all returned signals and addresses potential ambiguities (e.g., publisher vs contributor). The single parameter is fully documented.

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 covers 100% of the single parameter, and the description adds value with examples, case-sensitivity mention, and context about module paths. Exceeds baseline.

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 it obtains a 'behavioral commitment profile' for a Go module, listing specific signals (age, versions, etc.). It distinguishes from sibling tools which target different ecosystems or actions.

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?

Explicit usage scenarios are given ('vetting Go dependencies, abandonware identification, supply chain risk') with concrete examples. Lacks exclusion criteria but is sufficient for correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_npm_packageAInspect

Get a behavioral commitment profile for any npm package. Returns real signals: package age, download volume and trend (growing/stable/declining), release consistency, npm publisher count, GitHub contributor count, and linked GitHub activity.

Supply chain attacks target packages with low publisher depth (few people with npm publish access). Behavioral signals reveal what download counts hide.

Useful for: vetting dependencies, identifying abandonware, due diligence on open-source packages. Examples: "langchain", "@anthropic-ai/sdk", "express", "litellm"

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes	npm package name. Examples: "langchain", "@anthropic-ai/sdk", "express". Scoped packages need the @ prefix.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the nature of the tool (read-only, returns signals) and mentions supply chain attack relevance, publisher depth, and behavioral signals. It does not describe rate limits or API dependencies, but for a simple lookup tool, the transparency is sufficient.

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 concise: 4 sentences plus bullet-point use cases and examples. It front-loads the purpose, details outputs, then provides context and examples. Every sentence is informative and earns its place.

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?

Given one parameter and no output schema, the description explains the return values (signals list) and usage scenarios. It covers input semantics well, though lacks potential notes on data freshness or API limitations. Overall, it is adequately complete for a straightforward tool.

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?

The single parameter 'package' has a schema description covering 100%. The description adds value by specifying scoped packages need '@' prefix and giving examples, which aids correct input. This exceeds the baseline of 3 for full schema coverage.

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 identifies the tool as retrieving a 'behavioral commitment profile' for npm packages, listing specific signals (package age, download volume, trend, etc.). It distinguishes from siblings like lookup_pypi_package and lookup_github_repo by focusing on npm packages, making the purpose precise and unambiguous.

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 explicitly states use cases ('vetting dependencies, identifying abandonware, due diligence') and provides examples. It does not mention when not to use it or name alternative tools, but the context signals and sibling list imply differentiation. The guidance is strong but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_pypi_packageAInspect

Get a behavioral commitment profile for any PyPI (Python) package. Returns real signals: package age, download volume and trend, release consistency, publisher/owner count, and linked GitHub activity.

Supply chain attacks target Python packages — LiteLLM (97M downloads/mo) was compromised via stolen PyPI token in March 2026. Behavioral signals reveal what star counts hide.

Useful for: vetting Python dependencies, identifying abandonware, supply chain risk due diligence. Examples: "langchain", "litellm", "openai", "anthropic", "requests", "fastapi", "pydantic"

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes	PyPI package name. Examples: "langchain", "openai", "requests", "fastapi". Case-insensitive.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses behavioral signals: 'package age, download volume and trend, release consistency, publisher/owner count, and linked GitHub activity.' It also mentions a real-world supply chain attack to illustrate relevance. While it lacks details on output format or performance, the description is sufficiently transparent about what the tool returns.

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 concise, with three clear sections: purpose, detailed signals, and usage scenarios. It uses bold text for key phrases and provides specific examples. Every sentence adds value without redundancy.

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 lookup tool with a single parameter and no output schema, the description is fairly complete. It explains what the tool does, what signals are returned, and when to use it. Minor gaps include lack of output format details, but these are secondary given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the sole parameter 'package' with a description of 'PyPI package name' and examples. The description does not add new information beyond the schema; it merely repeats examples. With 100% schema coverage, a score of 3 is appropriate.

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's purpose: 'Get a behavioral commitment profile for any PyPI (Python) package.' It specifies the resource (PyPI packages) and the action (getting a profile). Sibling tools like lookup_npm_package and lookup_go_module differentiate by ecosystem, so the purpose is distinct.

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 provides explicit usage contexts: 'vetting Python dependencies, identifying abandonware, supply chain risk due diligence.' It also lists examples of packages. However, it does not explicitly state when not to use the tool or mention alternatives, which would justify a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_commitmentAInspect

Query verified behavioral commitment data for a domain. Returns aggregated signals: unique verified visitors, repeat visit rate, and average time spent. These prove real human engagement — harder to fake than reviews or content.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	The domain to query (e.g. 'example.com'). Will be normalized to lowercase without protocol or path.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It correctly indicates a read operation returning aggregated signals, but omits details like data freshness, verification method, potential rate limits, or error conditions. The claim 'verified' lacks elaboration.

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 consists of two clear, front-loaded sentences (35 words) with no filler. Every sentence provides essential information: query action, return values, and a qualitative remark about authenticity.

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 simple single-parameter tool without output schema, the description adequately covers purpose, inputs, and outputs. However, adding data source or recency info would improve completeness. Sibling tools are distinct enough to not cause confusion.

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?

The sole parameter 'domain' has 100% schema coverage, and the description adds value by specifying normalization ('lowercase without protocol or path'). This extra context clarifies input processing 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 the tool queries 'verified behavioral commitment data for a domain' and lists exact return values (unique verified visitors, repeat visit rate, average time spent). It distinguishes from siblings by emphasizing 'real human engagement' as opposed to generic lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is useful for assessing authentic engagement ('harder to fake than reviews or content'), but lacks explicit guidance on when to use this tool versus alternatives (e.g., when to prefer audit_dependencies). No exclusions or prerequisites are mentioned.

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 tool updatev1.8.0May 16, 2026
- Addedlookup_go_module
7 tool updatesv0.1.0May 8, 2026
- First observedaudit_dependencies
- First observedlookup_business
- First observedlookup_business_by_org
- First observedlookup_github_repo
- First observedlookup_npm_package
- First observedlookup_pypi_package
- First observedquery_commitment

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct entity type (business, GitHub repo, Go module, npm package, PyPI package, domain) or a distinct operation (batch audit). No two tools have overlapping purposes; even the two business lookup tools are differentiated by search method (name vs. org number).

Naming Consistency3/5

Most tools use 'lookup_' prefix, but 'audit_dependencies' and 'query_commitment' break the pattern. Additionally, 'lookup_business' and 'lookup_business_by_org' have differing suffixes, though still consistent. The mix of verbs (lookup, audit, query) is a minor inconsistency.

Tool Count5/5

With 8 tools, the server covers the essential entity types (business, GitHub, Go, npm, PyPI, domain) plus a batch audit function, without unnecessary bloat. This count is well-scoped for the domain of commitment verification across multiple ecosystems.

Completeness4/5

The tool set covers the main package ecosystems (npm, PyPI, Go) and GitHub repos, but lacks other popular ecosystems like Ruby gems or Cargo crates. Businesses are limited to Norway only. A minor gap given the stated focus on 'commitment profiles' for common supply chain vectors.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Repo Security Scanner — Malicious Code & Supply ChainOAuth
io.github.eltociear
Audit GitHub repos for malicious and supply-chain code before you depend on them.
Security Code Analysis Version Control
1
AnteproofOAuth
com.anteproof
Dependency risk + calibrated, publicly scored forecasts on OSS packages. Docs: anteproof.com/docs
1
Nekzus-npm-sentinel-mcpOAuth
ai.smithery
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Developer Tools Monitoring Security
218
databutler-provenance A
io.github.physics-star-cat
Live trust signals for domains & packages: age, registrar, typosquat resemblance.
Security
21

Related MCP Servers

vet-mcp
Code Execution CI/CD & DevOps Security
safedep
A
license
Not graded
quality
A
maintenance
Protect against malicious open source packages 🤖
Updated 3 days ago (2026-09-03 04:39 UTC)
1,103
Apache 2.0
@4da/mcp-server
Security Developer Tools Code Analysis
4DA-Systems
A
license
A
quality
A
maintenance
Dependency intelligence for AI agents. CVE scanning, health checks, upgrade planning.
Updated 14 hours ago (2026-09-05 17:40 UTC)
9
517
2
Apache 2.0
@buygit/mcp-server
Developer Tools Search Code Analysis
genoxdeveloper
A
license
A
quality
D
maintenance
The only MCP that returns license + supply-chain risk + popularity + price in a single call. 78,094 curated Git assets. Zero config. MIT. Free forever.
Updated 3 months ago (2026-05-26 06:11 UTC)
14
40
1
MIT
brandguard
Security Legal & Compliance
Baneado98
F
license
Not graded
quality
C
maintenance
Scans npm, PyPI, and GitHub for typosquatting and brand impersonation, risk-scores findings, and drafts takedown notices.
Updated 2 months ago (2026-06-22 18:01 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/piiiico/proof-of-commitment'

If you have feedback or need assistance with the MCP directory API, please join our Discord server