Skip to main content
Glama
verdochello

verdoc-mcp

by verdochello
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

verdoc-mcp

Give your coding agent the context of a repository it has never seen, for two cents, without an account or an API key.

An agent dropped into an unfamiliar codebase has to read it before it can work in it - and that costs tens of thousands of tokens every time. verdoc-mcp exposes two tools that answer the same questions directly:

tool

what you get

price

verdoc_agents_md

an AGENTS.md ready to commit

$0.02

verdoc_scan

the same analysis as structured JSON

$0.01

Build and test commands are quoted from the repository's own manifests, with the file each one came from named. Every path is checked against the git tree. Anything ambiguous is marked unverified rather than guessed.

No language model runs on the server. The same commit always returns the same answer.

Install

Easiest: download the .mcpb bundle and drag it into Claude Desktop, or point any MCPB-aware client at it directly - dependencies are bundled inside, nothing to install separately.

Not on npm yet. Two other ways to install straight from this repository:

{
  "mcpServers": {
    "verdoc": {
      "command": "npx",
      "args": ["-y", "github:verdochello/verdoc-mcp"],
      "env": { "EVM_PRIVATE_KEY": "0x..." }
    }
  }
}

Or clone it and point at the file directly:

git clone https://github.com/verdochello/verdoc-mcp && cd verdoc-mcp && npm install
{
  "mcpServers": {
    "verdoc": {
      "command": "node",
      "args": ["/absolute/path/to/verdoc-mcp/index.mjs"],
      "env": { "EVM_PRIVATE_KEY": "0x..." }
    }
  }
}

Works with Claude Desktop, Claude Code, Cursor, or any MCP client.

Without a key it still runs. The tools report what they would cost and what they would return, and buy nothing. That is the intended way to try it.

Related MCP server: git-daily-review

Paying

The wallet needs USDC on Base, Polygon or Arbitrum. It does not need ETH - x402 payments are signed off-chain and the facilitator pays the gas.

variable

default

meaning

EVM_PRIVATE_KEY

-

wallet that pays. Omit to run in quote-only mode.

VERDOC_MAX_SPEND_USD

0.05

hard per-call ceiling. Nothing above it is ever signed.

VERDOC_ORIGIN

https://verdoc.dev

override the endpoint (testing).

About that private key

You are handing a program the ability to spend your money, so here is exactly what this one does and does not do.

  • The key is read from the environment. It is never logged, never written to disk, and never sent anywhere. Error messages are scrubbed of anything that looks like a key before being returned.

  • The payee and the chain are pinned in the source. Before signing anything, the client reads the live payment offer and checks it. If Verdoc ever asks to be paid at a different address, or on a chain not in the list, this refuses and tells you instead of paying. That means a compromise of our own domain or DNS cannot redirect your funds.

  • Every call is capped by VERDOC_MAX_SPEND_USD, checked before a signature exists.

Use a wallet you funded for this purpose. That is good practice with any paying agent tool, including this one.

What it will refuse to do

These are tested in selftest.mjs, and the refusals are the part worth reading:

  • pay an address other than the pinned one - even if the live endpoint asks

  • pay on a chain outside the pinned set, including testnets

  • pay more than your ceiling

  • treat a short or empty 200 response as a real answer

Limits

Public GitHub repositories only. Repositories over 20,000 tracked files are rejected: GitHub truncates the git tree above that, and every claim this service makes depends on having the complete tree.

Licence

MIT. The service it calls is at verdoc.dev - OpenAPI | x402 discovery

Available Tools

2 tools
verdoc_agents_mdA

Generate an AGENTS.md for a public GitHub repository: build and test commands quoted from the repository's own manifests with the source file named, a directory map, entry points and edit boundaries. Every path is checked against the git tree and anything ambiguous is marked unverified rather than guessed. Use this before working in a repository you do not already know. Costs $0.02 in USDC from the configured wallet.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesPublic GitHub repository as owner/name, or a github.com URL.
formatNo'markdown' returns the file ready to write to disk; 'json' adds provenance.markdown

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: every path is checked against the git tree, ambiguous items are marked unverified rather than guessed, and the cost in USDC. This gives the agent a strong understanding of how the tool behaves.

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 efficiently structured: it front-loads the main purpose, then adds verification behavior, usage guidance, and cost in separate short sentences. Every sentence adds value, and there is no unnecessary 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?

Given the tool has no output schema and no annotations, the description is remarkably complete. It covers what the tool produces, how it verifies data, when to use it, and the cost. The format parameter covers return details, so no gap is apparent.

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 does not add parameter-specific meaning beyond the schema; it mentions 'public' repo and cost but these are not parameter semantics. Therefore it stays at the 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 the tool's purpose: 'Generate an AGENTS.md for a public GitHub repository' with specifics about content (build/test commands, directory map, entry points, edit boundaries). This is specific and distinguishes it from the sibling tool verdoc_scan, especially with the usage note.

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?

Explicitly says 'Use this before working in a repository you do not already know,' providing clear context for when to use it. It does not name alternatives or exclusions, but the guidance is specific and actionable, so it earns a 4 rather than a 5.

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

verdoc_scanA

Structured facts about a public GitHub repository: toolchain commands with the manifest each was quoted from, directory layout, language split, CI and test presence, a 0-100 documentation-health score, and phantom_paths - paths the README cites that do not exist in the git tree. Deterministic; no language model. Costs $0.01 in USDC.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYesPublic GitHub repository as owner/name, or a github.com URL.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description discloses determinism, cost, and the public repo constraint. It doesn't discuss failure modes, auth, or rate limits, but for a read-only public scan the disclosed traits are reasonably reassuring. Lacks deeper behavioral nuance like output structure edge cases.

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?

A single, information-dense sentence that packs all key details—output fields, determinism, and cost—without redundant wording. Front-loaded with the primary purpose, making it easy to scan.

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 no output schema, the description thoroughly enumerates expected return contents (toolchain commands, phantom_paths, etc.) and adds determinism/cost context. It doesn't describe exact data structures, but that is acceptable for a fact-collection tool. The single parameter and input schema are fully covered.

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% for the single 'repo' parameter, explicitly defining it as a GitHub 'owner/name' or URL. The description adds no new parameter details, so baseline 3 applies.

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 states a clear action and resource: 'Structured facts about a public GitHub repository' with a detailed list of content types. It distinguishes itself by highlighting deterministic, non-LLM behavior and cost, setting it apart from a typical analysis tool.

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 deterministic repository analysis, noting 'Deterninistic; no language model' and cost. However, it does not explicitly mention when to use it over the sibling tool verdoc_agents_md, nor any exclusions or prerequisites beyond 'public GitHub repository'.

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.0
    • First observedverdoc_agents_md
    • First observedverdoc_scan
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation4/5

The two tools have distinct outputs: one generates an AGENTS.md file, the other returns structured facts and a score. There is some overlap in the underlying data (toolchain, directory layout), but the purpose and return type are clear enough to avoid serious confusion.

Naming Consistency3/5

Both tools share the 'verdoc_' prefix, but the suffixes are inconsistent: 'agents_md' is a noun-phrase while 'scan' is a verb. They are readable and predictable, but not a strict verb_noun pattern.

Tool Count3/5

With only two tools, the server feels thin, but it is scoped to a narrow domain (analyzing GitHub repos). The small count is not unreasonable, though it leaves room for more related tools.

Completeness4/5

The domain is repository analysis, and the two tools cover the core operations: generating an AGENTS.md guide and performing a detailed scan. Minor gaps exist (e.g., no direct metadata-only fetch), but for the stated purpose the surface is reasonably complete.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

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

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/verdochello/verdoc-mcp'

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