closeread-verify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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. |
| 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. |
| 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool handles a distinct input: single file, multiple files, or a remote repository. The descriptions clearly differentiate their use cases without any overlap.
All tools follow a consistent 'audit_' prefix with a clear noun suffix (_dependencies, _project, _repo), making the purpose immediately obvious.
Three tools is perfectly scoped for the domain of dependency auditing, covering the primary input modes without unnecessary bloat.
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.