x402-codesearch-mcp
Indexes code files into a Cloudflare Workers-based semantic code search service, using Workers AI for embeddings and Vectorize for vector storage.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@x402-codesearch-mcpIndex the files from my repo 'acme' for code search."
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.
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.dev
— POST /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 embeddingsVectorize — 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 anotefield 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-mcpOr 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 transportsrc/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 /indexcall 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 /indexrequires no payment and no API key — confirmed live, not just documented.Not free, and not exposed here by design:
POST /searchon 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_codecall 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_codeand 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_codetool shares the same free/indexendpoint as every other caller, but/searchis metered per call regardless of caller.
License
MIT
Available Tools
1 toolindex_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 }.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | One or more files to index for this repoId | |
| repoId | Yes | Identifier to group this repo's indexed chunks under, e.g. "my-repo" or "owner/repo" |
TDQS
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.
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.
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.
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.
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.
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 tool update
v0.1.0- First observed
index_code
TDQS
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.
The single tool follows a clear verb_noun pattern ('index_code'), which is consistent and descriptive. There are no other tools to introduce inconsistency.
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.
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
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
Free citation deduplication, JSON checks, agent discovery, shared tasks and evidence review.
Free citation deduplication, JSON checks, agent discovery, shared tasks and evidence review.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables 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
- AlicenseAqualityDmaintenanceEnables 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.1806Apache 2.0
- AlicenseAqualityFmaintenanceProvides code repository indexing and semantic search capabilities, allowing natural language queries to find relevant code snippets with automatic incremental indexing and multi-language support.119360ISC
- FlicenseNot gradedqualityDmaintenanceEnables 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
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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