Click on "Deploy 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., "@ragd-mcp find where the API rate limiting is implemented"
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.
An MCP (Model Context Protocol) adapter that exposes ragd's
POST /query endpoint as a query_codebase tool, so Claude Code can call
it for fuzzy/semantic codebase search alongside its built-in Grep/Glob.
ragd speaks plain REST/JSON, not MCP, so this exists purely to bridge the two protocols. It's a single tool, resolved automatically:
If a resource name isn't given, it looks up ragd's /resources list
and picks whichever registered resource's directory contains the
current working directory (deepest match wins).
Otherwise it queries the given resource directly.
ragd running and reachable (default http://localhost:20250,
override with RAGD_URL)
Related MCP server: RAGex
Run from inside this repo:
claude mcp add --transport stdio ragd --scope user -- uv run --project "$(pwd)" "$(pwd)/main.py"--project only sets the dependency-resolution root, not the working
directory uv run resolves the script argument against, so the script
path needs to be absolute.
--scope user makes it available in every project on this machine, since
ragd itself already scopes results per-repo. Verify with claude mcp list
or /mcp in a session.
Apache-2.0. See LICENSE.
Fuzzy/semantic RAG search over a codebase indexed by ragd.
Prefer this over Grep/Glob when the question is conceptual rather than an exact string/symbol match -- e.g. "where do we handle retry logic" or "how is auth configured" -- where you don't know the exact symbol/filename to search for. Returns a synthesized answer plus the source file excerpts it was drawn from.
Args: query: Natural-language question about the codebase. resource: Name of the ragd resource to search. If omitted, the resource whose indexed directory contains the current working directory is used automatically. top_k: Number of source chunks to retrieve and ground the answer in (default 5, max 20).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| resource | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It states the output ('synthesized answer plus the source file excerpts'), the automatic resource fallback behavior, and that top_k controls grounding. It could add a note about failure modes or index requirements, but it covers the main observable behaviors.
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 tightly structured, front-loading the core purpose, then usage guidance, then parameter documentation. Every sentence adds value, and the examples are illustrative without being padded.
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 is complete for a RAG search tool: it covers when to use it, what it returns, how each parameter behaves, and the automatic resource resolution. Since an output schema exists, detailed return-value documentation is not required.
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 description coverage is 0%, so the description must carry parameter documentation, and it does. All three parameters (query, resource, top_k) are explained with semantics beyond their schema types, including defaults, max value, and automatic fallback behavior.
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 opens with a specific verb and resource: 'Fuzzy/semantic RAG search over a codebase indexed by ragd.' It goes beyond the name by explaining the mechanism (RAG, semantic) and directly distinguishes the tool from exact-match tools like Grep/Glob.
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?
The description explicitly states when to prefer this tool: 'Prefer this over Grep/Glob when the question is conceptual rather than an exact string/symbol match.' Concrete examples and the condition for choosing an alternative make the routing decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0query_codebaseScored across 1 tool
With only one tool, there is no possibility of overlapping or confusable operations. query_codebase is clearly scoped to fuzzy/semantic codebase search rather than exact-match grep/glob.
query_codebase uses a clear verb_noun pattern and accurately describes the action and target. With a single tool, there is no naming inconsistency to create confusion.
One tool is the absolute minimum surface, making the server feel thin as a standalone integration. The narrow query-focused scope is defensible, but it is a borderline rather than fully developed toolset.
The server covers the core semantic search query flow, but it offers no way to list, inspect, or manage ragd resources. An agent can query successfully using auto-selection, yet resource discovery and index status information are notable gaps.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Project memory, semantic code search, and grounded agent context.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
