Skip to main content
Glama
liminalpepe

x402-codesearch-mcp

by liminalpepe

x402-codesearch-mcp

A free MCP (Model Context Protocol) server that indexes a repo's files — chunked and embedded — into the live semantic code search Worker, for free, via one MCP tool: index_code.

This is the open funnel twin of a paid, x402-gated HTTP API:

x402-codesearch-poc.theliminalguy.workers.devPOST /search, $0.01 USDC on Base per query via the x402 payment protocol, for the actual semantic search step over an indexed repo.

Why this one is different from the other free twins (read this first)

Sibling packages like x402-repohealth-mcp fully reimplement their paid Worker's logic locally (pure functions, no external account-bound dependency) and expose the entire feature for free via MCP.

This package cannot do that. The paid Worker's semantic search depends on two Cloudflare-account-bound bindings with no free, local, or portable equivalent:

  • Workers AI (@cf/baai/bge-base-en-v1.5) — generates the embeddings

  • Vectorize — stores and queries those embeddings by cosine similarity

Both only exist inside the Worker's own Cloudflare account. There is no way to run them for free outside that account, so this MCP server does not try to fake or proxy them.

What genuinely is free is POST /index on the live Worker itself — the step that chunks a file, embeds it, and upserts it into that Worker's own Vectorize index. That's the one real, free, stateless capability this package exposes as an MCP tool. The matching POST /search step stays exactly where it already is: a real x402-gated HTTP call directly against the live Worker.

Related MCP server: Acemcp

What it does

One tool, index_code:

  • Input: { repoId: string, files: [{ path: string, content: string }] }

  • Calls POST https://x402-codesearch-poc.theliminalguy.workers.dev/index (free, no payment) with that exact body.

  • Output: { repoId, filesIndexed, chunksIndexed } plus a note field reminding the caller that searching what was just indexed requires the paid endpoint.

It does not expose a search_code tool. Semantic search over data indexed with this tool requires calling the x402-gated endpoint directly:

POST https://x402-codesearch-poc.theliminalguy.workers.dev/search
Body: { "repoId": "...", "query": "..." }
Price: $0.01 USDC on Base, via the x402 protocol (e.g. x402-fetch / x402-axios)

An unpaid request to /search returns 402 Payment Required with real x402 payment instructions.

Install & run

npx x402-codesearch-mcp

Or add it to an MCP client config (e.g. Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "codesearch": {
      "command": "npx",
      "args": ["-y", "x402-codesearch-mcp"]
    }
  }
}

Tool: index_code

Input:

{
  "repoId": "my-repo",
  "files": [
    { "path": "src/retry.py", "content": "def retry_with_backoff(...): ..." }
  ]
}

Output (MCP tool text content, JSON-stringified):

{
  "repoId": "my-repo",
  "filesIndexed": 1,
  "chunksIndexed": 2,
  "note": "Indexing succeeded (free). To semantically search this repoId, call the x402-gated POST https://x402-codesearch-poc.theliminalguy.workers.dev/search directly ($0.01 USDC on Base per query) — not available through this free MCP tool."
}

Local development

npm install
npm run dev              # runs src/index.ts directly on stdio via tsx
npm run build             # compiles to dist/ for the published npm package
npm run test:index        # calls indexCode() directly against the real live Worker, no MCP transport

src/client.ts and src/types.ts hold the thin HTTP client against the live Worker's /index endpoint — src/index.ts is a thin MCP wrapper around indexCode().

What's real vs. limited

  • Real: the POST /index call this tool makes goes to the actual live Worker, which really chunks the given files, really calls Workers AI for embeddings, and really upserts into Vectorize — nothing here is mocked or hardcoded. Verified end-to-end against the live Worker (see below).

  • Genuinely free: POST /index requires no payment and no API key — confirmed live, not just documented.

  • Not free, and not exposed here by design: POST /search on the same Worker. That's a deliberate scope boundary, not an oversight — see "Why this one is different" above.

  • No local caching/dedup: every index_code call re-POSTs to the live Worker; re-indexing the same file just re-chunks/re-embeds/re-upserts it.

When to use the paid HTTP twin directly

Use POST /search on the live Worker instead of (in addition to) this MCP server when:

  • You've indexed a repo with index_code and now want to actually search it semantically.

  • Your agent already speaks x402 (e.g. via x402-fetch / x402-axios) and can pay $0.01 USDC on Base per query.

  • You need production/high-volume search — this MCP server's index_code tool shares the same free /index endpoint as every other caller, but /search is metered per call regardless of caller.

License

MIT

Available Tools

1 tool
index_codeIndex CodeA

Index a repo's files into the live x402-codesearch Worker (https://x402-codesearch-poc.theliminalguy.workers.dev) so they become semantically searchable: each file is chunked, embedded via Workers AI, and upserted into that repoId's Vectorize index. Free, unauthenticated MCP tool — no payment required to index. IMPORTANT: this tool only calls the free POST /index endpoint. The matching semantic search step (POST /search on the same Worker) is real but x402-gated at $0.01 USDC on Base per query, and depends on Cloudflare Vectorize + Workers AI bindings that have no free or local equivalent — so it is NOT exposed here. To actually search a repo you've indexed with this tool, call POST https://x402-codesearch-poc.theliminalguy.workers.dev/search directly with an x402-aware HTTP client (e.g. x402-fetch / x402-axios) and a funded Base wallet, passing { repoId, query }.

ParametersJSON Schema
NameRequiredDescriptionDefault
filesYesOne or more files to index for this repoId
repoIdYesIdentifier to group this repo's indexed chunks under, e.g. "my-repo" or "owner/repo"

TDQS

A4.3/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 exact operation (chunk, embed, upsert), that it is unauthenticated and free, and warns that search is gated and requires external dependencies. It does not mention potential behavior like idempotency or overwriting existing chunks, but overall provides substantial transparency.

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 the core action and efficiently covers the important caveats. The extensive explanation of the external search endpoint and x402 dependency is relevant but somewhat lengthy; still, every sentence contributes to correct usage.

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?

The description covers the tool's role in a broader pipeline, clarifies limitations (no search), and provides alternative invocation guidance. It omits the return value/response format, but for an indexing tool with no output schema, the provided context is largely sufficient.

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 both repoId and files described in the schema. The description does not add syntax or format details beyond the schema, though it does explain the end-to-end processing (chunked, embedded, upserted), leaving the schema as the primary documentation.

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 explicitly states the tool indexes repo files into a specific Worker and makes them semantically searchable, detailing chunking/embedding/upserting. It distinguishes itself from search by stating this tool only calls the free POST /index endpoint.

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?

It clearly explains when to use this tool (for indexing) and when not to (for searching), explicitly noting the search endpoint is not exposed and directing users to call POST /search directly with an x402-aware client. It also mentions it is free and unauthenticated.

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. 1 tool updatev0.1.0
    • First observedindex_code

TDQS

A4/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose (indexing code) is clearly distinct from any other, as there are no other tools.

Naming Consistency5/5

The single tool follows a clear verb_noun pattern ('index_code'), which is consistent and descriptive. There are no other tools to introduce inconsistency.

Tool Count2/5

Having only one tool for a 'codesearch' server is severely insufficient. The index tool is only half of the workflow; the search operation is intentionally not exposed, making the tool count a poor match for the apparent scope.

Completeness1/5

The core functionality of a codesearch server—searching—is completely missing from the MCP toolset. Only indexing is provided, and the description explicitly notes that search must be done via an external endpoint. This is a critical gap that prevents the tool from fulfilling its stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables semantic code search across multiple repositories using natural language queries. Provides intelligent code discovery, symbol lookups, and cross-repo dependency analysis for AI coding agents.
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Enables semantic code search across codebases with automatic incremental indexing. Searches return relevant code snippets with file paths and line numbers based on natural language queries.
    1
    806
    Apache 2.0
  • A
    license
    A
    quality
    F
    maintenance
    Provides code repository indexing and semantic search capabilities, allowing natural language queries to find relevant code snippets with automatic incremental indexing and multi-language support.
    1
    19
    360
    ISC
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to semantically search and navigate code repositories using natural language, with support for multiple repos, incremental indexing, and no local install needed.
    -

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/liminalpepe/x402-codesearch-mcp'

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