Which integrations are available for this server?

Provides dependency auditing for Composer projects by analyzing composer.lock files to identify known vulnerabilities. Allows auditing a public GitHub repository by shallow-cloning and running a dependency audit on its lockfiles. Provides dependency auditing for npm projects by analyzing package-lock.json files to identify known vulnerabilities and separate direct from transitive dependencies. Provides dependency auditing for PHP projects using Packagist by analyzing composer.lock files to identify known vulnerabilities. Provides dependency auditing for pnpm projects by analyzing pnpm-lock.yaml files to identify known vulnerabilities. Provides dependency auditing for Poetry projects by analyzing poetry.lock files to identify known vulnerabilities. Provides dependency auditing for RubyGems projects by analyzing Gemfile.lock files to identify known vulnerabilities. Provides dependency auditing for Yarn projects by analyzing yarn.lock files to identify known vulnerabilities.

How do I use closeread-verify?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@closeread-verify audit requirements.txt for vulnerabilities" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

closeread-verify

by FreeGuy-AI

Overview Schema Related Servers Score Discussions

Python

Remote

closeread-verify

PyPI Python License: MIT MCP

A verified dependency-audit verdict any AI agent can call.

A free scanner gives you raw CVEs. closeread-verify gives you the judgment: the verdict checked against the version you actually installed, the one finding that matters, and the exact fix. It runs as an MCP server, so any agent (Claude Code, Cursor, your own) can call it before it ships code and get back a checked answer, not a wall of noise.

Why this and not `npm audit`

A raw scanner and the agent itself can already produce a list of CVEs. What they cannot manufacture is the verdict. closeread-verify is built around the one discipline that separates a real audit from a scan:

It reports the INSTALLED version, not the declared floor. ^4.17.0 in a manifest is not what you shipped. The tool resolves the real pinned version from your lockfile and checks that, so it does not cry wolf over a caret range you already patched, and does not miss a vulnerable pin a manifest-only scan would wave through.
It splits direct vs transitive. The dependency you declared and own (yours to bump) is separated from the one you inherited five levels down. Most scanners flatten these into one undifferentiated list. This one tells you which is which.
It surfaces the one finding that matters. Instead of 200 rows, you get a single lead: the highest-severity direct production issue, with the exact fix. If the only findings are transitive or dev-only, the lead is honestly null rather than a manufactured headline.
It is deterministic and re-checkable. No LLM in the path. Same lockfile in, same verdict out. Advisories are confirmed against OSV.dev. The verdict carries its own basis so a reviewer can re-run it.

That verified artifact, not the raw scan, is the product.

Related MCP server: DepsGuard MCP

Install

pip install closeread-verify

Python 3.11+. No API key, no account, no source access. Lockfile in, verdict out.

See it in an agent loop

examples/agent_loop.py is a runnable agent that uses closeread-verify as a pre-ship gate: it blocks on a real Flask CVE, applies the named fix, re-checks, and ships. Real MCP over stdio, real OSV advisories, no API key.

python examples/agent_loop.py

Use it as an MCP server

closeread-verify is the stdio command that starts the server:

closeread-verify

Client config

Add it to your MCP client. Claude Code / Cursor style (mcp.json / claude_desktop_config.json):

{
  "mcpServers": {
    "closeread-verify": {
      "command": "closeread-verify"
    }
  }
}

If you installed into a specific environment, point at that interpreter instead:

{
  "mcpServers": {
    "closeread-verify": {
      "command": "python",
      "args": ["-m", "closeread.mcp_server"]
    }
  }
}

The three tools

Tool	Input	Use it when
`audit_project`	`files`: a `{filename: content}` map	You have a real checkout. Pass the manifest and its lockfile together (e.g. `package.json` + `package-lock.json`) so the direct-vs-transitive split is recovered. Subdir prefixes like `server/package.json` are allowed.
`audit_dependencies`	`lockfile_content`: str, `filename`: str	You have a single manifest or lockfile and want a one-shot verdict.
`audit_repo`	`github_url`: str	You have a public repo URL. It shallow-clones and runs the same audit. Returns an error, never a fabricated result, if the clone fails.

The filename is load-bearing: it routes the content to the right ecosystem parser. Supported lockfiles include package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile.lock, Gemfile.lock, composer.lock, and Cargo.lock.

Example

Calling audit_dependencies on a requirements.txt that pins flask==0.12.0:

{
  "source": "lockfile:requirements.txt",
  "lead": {
    "summary": "flask@0.12.0 affected by GHSA-562c-5r94-xh97",
    "severity": "high",
    "is_direct": true,
    "dependency_kind": "prod",
    "location": "requirements.txt:1",
    "fix": "Update flask to a patched version (see references).",
    "confidence": 0.9
  },
  "findings": {
    "issues": [],
    "direct": [
      {
        "kind": "dependency",
        "package": "flask",
        "severity": "high",
        "is_direct": true,
        "versions": ["0.12.0"],
        "advisories": ["GHSA-562c-5r94-xh97", "GHSA-5wv5-4vpf-pj6m", "GHSA-m2qf-hxjv-5gpq"],
        "locations": ["requirements.txt:1"],
        "recommendation": "Update flask to a patched version (see references)."
      }
    ],
    "transitive": []
  },
  "counts": { "product_critical": 3, "issues": 0, "direct": 1, "transitive": 0 },
  "verification": {
    "basis": "each version is the INSTALLED version resolved from the lockfile, not the declared floor; advisories confirmed via OSV; result is deterministic and re-checkable",
    "scanner": "closeread SCA (deterministic, no LLM)",
    "advisory_source": "OSV.dev",
    "as_of": "2026-06-08T12:00:00+00:00"
  }
}

The agent does not get a scan to interpret. It gets a verdict to act on: bump flask, here is the line, here is why.

The verified-audit primitive for the agent era

Agents are starting to write, review, and ship code on their own. Before an agent opens a PR or green-lights a deploy, it needs an answer to a simple question with a checkable answer: is anything I depend on known-vulnerable, in the version I actually pinned, and is it mine to fix? closeread-verify is that primitive. One MCP call, a deterministic verdict, no LLM in the loop to hallucinate a CVE that does not exist or miss one that does.

Scope, honestly

Ecosystems: npm/yarn/pnpm, pip/poetry/pipenv, RubyGems, Packagist (Composer), crates.io (Cargo).
Deterministic: no LLM, no network beyond OSV.dev advisory lookups.
Lockfile-only: it reads manifests and lockfiles. It does not need, request, or transmit your source code.
What it is not: this is the free, deterministic dependency-audit tier. It is not a full code review, not a SAST engine, not a license or architecture audit. It does one thing: a verified verdict on your dependencies.

License

MIT. Built by Free Guy.

Available Tools

3 tools

audit_dependenciesA

Audit a single manifest/lockfile and return a VERIFIED finding.

Pass the raw lockfile text and its filename (package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile.lock, Gemfile.lock, composer.lock, Cargo.lock). Returns the one finding that actually matters (the lead), the full direct-vs-transitive split, and the basis of the verdict. Versions are the INSTALLED lockfile versions, not the declared floor; advisories are confirmed via OSV. Deterministic.

ParametersJSON Schema

Name	Required	Description	Default
`lockfile_content`	Yes
`filename`	Yes

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 full burden. It discloses that the tool returns a verified finding, the lead, split, and verdict basis, and states it is deterministic. It does not cover potential side effects or auth requirements, but the behavior is clearly outlined.

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 two sentences, densely packed with information, and front-loaded with the core action ('Audit a single manifest/lockfile'). Every sentence contributes 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?

Given the simple two-parameter input and no output schema, the description adequately covers input format, supported file types, and output components. It lacks error handling or edge cases, but is reasonably complete for the tool's complexity.

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?

Despite 0% schema description coverage, the description explains the two parameters: 'raw lockfile text' corresponds to lockfile_content and 'its filename' to filename, with examples. This adds meaning beyond the schema, though parameter-level details are minimal.

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 audits a single manifest/lockfile and returns a verified finding. It distinguishes from siblings (audit_project, audit_repo) by focusing on a single file, making the purpose 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 instructs users to pass raw lockfile text and filename, and lists supported file types. It implies this tool is for individual files but does not explicitly contrast with sibling tools for projects or repos, leaving some room for interpretation.

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

audit_projectA

Audit one or more manifest/lockfiles TOGETHER and return a VERIFIED result.

Pass a {filename: content} map. When you have both a manifest and its lockfile (e.g. package.json AND package-lock.json), send both: that pairing is what recovers npm's direct-vs-transitive split, so the production dependency you actually own surfaces as the DIRECT lead instead of collapsing to transitive. A single-file map works too (e.g. just requirements.txt). A subdir prefix like server/package.json is allowed. Versions are the INSTALLED lockfile versions, not the declared floor; advisories are confirmed via OSV. Deterministic, no LLM.

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Given no annotations, the description fully discloses behavior: deterministic, no LLM, versions from installed lockfile, advisories via OSV. It also explains the pairing effect on dependency classification.

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 front-loaded with a clear summary, followed by necessary details. It is slightly lengthy but each sentence adds value. Minor redundancy in the pairing explanation could be tightened.

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?

While the usage and parameters are well covered, the description lacks details about the output format (e.g., the structure of the verified result, how advisories are presented). Without an output schema, this gap reduces completeness.

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

Parameters5/5

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

With 0% schema coverage, the description compensates fully by explaining the files parameter as a {filename: content} map, giving concrete examples (package.json + package-lock.json), and clarifying allowed prefixes and value interpretations.

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 audits manifest/lockfiles together, with a specific verb and resource. It distinguishes itself from siblings by emphasizing the pairing logic to recover direct-vs-transitive split.

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 clear when-to-use guidance, explaining the benefit of sending both manifest and lockfile, and that single-file works too. It does not explicitly mention alternatives like audit_dependencies or audit_repo, but the context is sufficient for correct usage.

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

audit_repoA

Shallow-clone a public GitHub repo and return the same VERIFIED result.

Use when you have a repo URL rather than a raw lockfile. Same output shape as audit_dependencies. Returns an error (never a fabricated result) if the repo cannot be cloned.

ParametersJSON Schema

Name	Required	Description	Default
`github_url`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Discloses that it shallow-clones, returns an error (no fabrication), and shares output shape with audit_dependencies. No annotations exist, so description carries burden; it could mention more about side effects or prerequisites but is reasonably transparent.

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?

Three sentences, each with distinct purpose: action, usage context, and behavior. No wasted words, front-loaded with the core action.

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 (one required param, no output schema, no annotations), the description covers all essential aspects: purpose, when to use, error behavior, and output shape similarity. Sibling tools are referenced, providing adequate context.

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 schema has 0% description coverage, so the description adds value by explaining that the single parameter is a GitHub repo URL and contextualizing its use. It does not provide format constraints but the parameter is straightforward.

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 shallow-clones a public GitHub repo and returns a verified result. It distinguishes from sibling tools by specifying the input type (repo URL vs raw lockfile).

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?

Explicitly states when to use this tool ('Use when you have a repo URL rather than a raw lockfile') and references the sibling tool audit_dependencies for comparison. Also provides an error guarantee.

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.

3 tool updatesv0.1.2Jun 25, 2026
- First observedaudit_dependencies
- First observedaudit_project
- First observedaudit_repo

Install Server

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

TDQS

A4.6/5.0

Disambiguation5/5

Each tool handles a distinct input: single file, multiple files, or a remote repository. The descriptions clearly differentiate their use cases without any overlap.

Naming Consistency5/5

All tools follow a consistent 'audit_' prefix with a clear noun suffix (_dependencies, _project, _repo), making the purpose immediately obvious.

Tool Count5/5

Three tools is perfectly scoped for the domain of dependency auditing, covering the primary input modes without unnecessary bloat.

Completeness4/5

The set covers the main workflows (single file, project, repo), but lacks a tool for auditing a directory without a known lockfile or for output customization, which are minor gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
dependency-trust A
ai.kaiv
Trust-check any dependency for agents: OpenSSF Scorecard, licenses, CVEs, deps. 7 ecosystems.
Security Developer Tools
51
LicenseGate A
io.github.Computersmarts1
Open-source licence risk checks for AI coding agents and dependency trees.
Legal & Compliance Code Analysis
11
Package Intel MCP A
io.github.selflabbs
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Developer Tools Code Analysis
2

Related MCP Servers

@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 4 hours ago (2026-09-05 13:01 UTC)
9
517
2
Apache 2.0
DepsGuard MCP
Developer Tools Security Code Analysis
Kim-Kyowon
A
license
A
quality
C
maintenance
AI-powered dependency vulnerability and breaking change analyzer that scans dependencies, identifies vulnerabilities via OSV.dev, and uses AI to assess real impact and suggest fixes.
Updated 3 months ago (2026-06-17 07:56 UTC)
3
Apache 2.0
DepHealth MCP
Security Code Analysis
hasarahman
A
license
A
quality
D
maintenance
Dependency security & health auditing for AI agents with no account or API key required.
Updated 2 months ago (2026-07-04 22:58 UTC)
2
2
MIT
agentguard
Security Code Analysis AI & Machine Learning
shuaicongxiaomai
A
license
Not graded
quality
B
maintenance
Provides security checks for AI agents, including secret scanning, CVE lookup, and dependency vulnerability scanning, all running locally except for CVE lookups.
Updated 2 months ago (2026-07-02 10:56 UTC)
MIT

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/FreeGuy-AI/closeread-verify'

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

closeread-verify

Why this and not npm audit

Install

See it in an agent loop

Use it as an MCP server

Client config

The three tools

Example

The verified-audit primitive for the agent era

Scope, honestly

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Why this and not `npm audit`