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., "@Senior Code MCP search for retry implementation and all functions that call it"
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.
Give your coding agent a memory of your codebase — so it reuses proven patterns instead of guessing, cuts the tokens you burn pasting whole files into context, and ships higher-quality code.
An MCP server that lets Cursor, Claude Code, or any MCP client search your repos two ways before writing a line of new code:
Semantic similarity — symbol-level chunks embedded with a local model and stored in Qdrant.
Structural relationships — a graph of calls and imports between symbols, expanded via NetworkX.
One search_context call does both: vector search for the concept, then graph expansion on the top hits, in one combined result.
Most code-search tools give an agent one lens. A plain vector store returns chunks of text that look similar to the query — useful, but blind to structure: it can't tell you that the retry helper it just found is called by 14 services, or that it implements an interface three other modules depend on. A pure code-graph tool gives the opposite lens — relationships without semantic ranking, so you have to already know the symbol name before you can expand from it.
Senior Code MCP runs both lenses on symbol-level chunks produced by a real AST parse:
Senior Code MCP | Generic vector memory (e.g. | Code-graph MCPs ( | |
Semantic vector search | yes | yes | yes |
Call/import graph expansion | yes | no | yes |
Chunk granularity | AST symbols (Python | raw text windows | AST symbols (Tree-sitter, many languages) |
Default deployment | local; code stays on the machine | depends on config | local |
Language coverage | Python | language-agnostic | 10+ languages |
The tradeoff is deliberate. The tools on the right do more; this one does less, in a slice small enough to read, run, and reason about in an evening. What that focus buys is a retrieval step that returns not just "here is similar code" but "here is similar code, and everything that calls it, imports it, or shares its shape" — the context an agent needs to reuse a proven implementation instead of writing a parallel one.
Related MCP server: GraphHub
repo -> parse (Python stdlib ast) -> symbol chunks
-> embed (Ollama nomic-embed-text, 768d) -> Qdrant
-> call/import edges -> NetworkX graph (graph.json)Ingestion walks a repo, extracts functions/classes/methods with the Python ast module, embeds each symbol's source, upserts into Qdrant, and builds a directed graph of call and import relationships. Multiple repos coexist in one collection, each chunk tagged with its repo name.
Tool | What it does |
| Embeds a natural-language or code query, returns top-k matching symbols (path, lines, docstring, truncated source, score). |
| Given symbol names, expands N hops through the call/import graph and returns connected symbols. |
| One call, two-stage retrieval: vector search for the query, then graph expansion on the top hits' symbol names. Returns one combined result ( |
| Runs the full pipeline on a local repo path (parse, embed, upsert, build graph). |
| Diagnostic: vector count in Qdrant, node/edge counts in the graph. |
| Read-only prerequisite self-diagnosis (qdrant reachable, collection exists + vector count, ollama reachable + embed model present, graph file + node/edge counts). The onboarding agent's first call. |
Typical agent flow: doctor first to confirm the store is healthy, then search_similar_code for a concept, then search_related_code on the hit names — or search_context to get both stages in a single call.
Fully local by default. Ollama embeddings + Qdrant on the machine. Code never leaves the perimeter — no cloud embedding API, no hosted vector DB, no surprise egress. (A cloud embedding API is supported only with explicit written approval, per AGENTS.md.)
Three commands to a working index. docker run qdrant, ollama pull nomic-embed-text, senior-code-ingest /your/repo. No cluster, no accounts, no billing.
Self-onboarding agent. AGENTS.md is a runbook an AI coding agent auto-reads on repo open: it calls doctor, asks the org the three questions that actually need a human (code perimeter, which repos, re-index cadence), respects hard guardrails (never reset a collection, never send code externally without approval, secrets in env), then ingests + registers + verifies on its own.
Drops into existing agent stacks. Std MCP over stdio — Cursor, Claude Code, any MCP client. One entry in mcp.json.
No vendor lock-in. Open Python, stdlib ast, Qdrant, NetworkX. Read every file in an evening.
docker run -d --name qdrant -p 6333:6333 -p 6334:6334 qdrant/qdrant
ollama pull nomic-embed-text
uv sync
senior-code-ingest /path/to/any/python/repoAlternative: docker compose up brings up Qdrant + Ollama together — on macOS, native Ollama is preferred (faster, uses Metal GPU) over the container.
Then register in Cursor (.cursor/mcp.json in this repo is an example, or add to global ~/.cursor/mcp.json):
{
"mcpServers": {
"senior-code-mcp": {
"command": "/absolute/path/to/.venv/bin/senior-code-mcp",
"args": []
}
}
}Restart Cursor, then ask it to "call doctor", "call store_stats", and "search similar code for ".
Setting | Default | Env var |
Qdrant URL |
|
|
Collection |
|
|
Ollama URL |
|
|
Embed model |
|
|
Graph path |
|
|
Python files only (stdlib ast; tree-sitter multi-language is the planned upgrade).
Fully local: no hosted embeddings, no cloud vector DB.
Single shared collection; multi-tenant separation is future work.
No incremental ingest yet — re-running re-embeds the repo (idempotent via deterministic IDs, but not free).
Built at the Cursor x Superteam Georgia hackathon (Tbilisi, Jul 22 2026) — built with Cursor, end to end, in one night.
Self-diagnose prerequisites before any org-facing setup.
The onboarding agent calls this first to learn what is already healthy and what is missing, so it only asks the org about the things that actually need a human decision. Non-destructive: never writes, never creates a collection, never pulls a model.
Checks:
Qdrant reachable on the configured URL.
Target collection exists and its vector count.
Ollama reachable and the configured embed model is pulled.
Graph file exists with node and edge counts.
Returns:
Per-check status (ok bool + detail) and an overall healthy flag.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explicitly states 'Non-destructive: never writes, never creates a collection, never pulls a model,' and enumerates exactly what is checked. This is thorough and goes beyond what an annotation would provide.
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 well-structured: opens with purpose, gives usage context, lists checks in bullets, and describes return values. Every sentence earns its place, and the most important information is front-loaded.
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?
Despite having no output schema, the description explicitly states the return shape: 'Per-check status (ok bool + detail) and an overall healthy flag.' Combined with clear usage guidance, non-destructive guarantees, and zero parameters, this is complete for an AI agent to select and invoke correctly.
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?
The tool has zero parameters and the schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies for 0-parameter tools. The description adds no parameter-specific detail because none is needed.
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 uses a specific verb and resource: 'Self-diagnose prerequisites before any org-facing setup.' It clearly states the tool's role as a preflight check and distinguishes it from sibling search/ingest tools by focusing on health checks. The bullet list of checks further clarifies the scope.
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 says 'The onboarding agent calls this first,' giving clear context for when to use it. It explains the rationale (only ask the org about things needing human decisions) but does not mention explicit exclusions or alternatives beyond the implicit contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest a repo: parse, chunk, embed + upsert to Qdrant, build + save graph.
Appends to the existing collection by default so multiple repos coexist;
pass reset=True to drop + recreate the collection first. Every chunk is
tagged with its repo name.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| reset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden and does well: it discloses the side effects (appends to existing collection, reset=True drops and recreates), and adds context about chunk tagging. It does not mention error handling or return values, but the key behavioral traits are transparent.
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 concise and front-loaded with the core action. Each sentence earns its place: the first summarizes the pipeline, the second details the append/reset behavior and the repo tagging. No redundant or vague wording.
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?
Given the tool's complexity (parsing, chunking, embedding, upserting, graph building) and lack of output schema, the description covers the main steps and side effects but omits details like return values, error cases, or idempotency across repeated ingests. Overall, it provides a solid but not exhaustive picture.
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 compensate. It explicitly explains the 'reset' parameter (drop + recreate collection first) and implies 'path' by describing the tool as 'ingest a repo'. While path is not explicitly described, the intent is clear enough; the description adds meaningful semantics beyond the bare schema.
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 uses a specific verb ('Ingest') with a clear resource ('repo') and enumerates the exact steps: parse, chunk, embed + upsert to Qdrant, build + save graph. This clearly distinguishes it from sibling search tools like search_context or search_similar_code, which are query-oriented.
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 implies usage for adding a repo to the knowledge base, contrasting with the search-focused siblings. It explains the default append behavior and the reset option, providing clear context. However, it does not explicitly state 'when not to use' or name alternatives, so it misses the explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two-stage retrieval in one call: semantic search + graph expansion.
Runs vector search for query (top-k), takes the symbol names from those
hits, expands the graph one hop from them, and returns a combined result:
similar_chunks (the vector hits) plus related_symbols (graph neighbors).
| Name | Required | Description | Default |
|---|---|---|---|
| hops | No | ||
| query | Yes | ||
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It thoroughly explains the pipeline: vector search, symbol extraction, one-hop graph expansion, and the exact combined result fields (similar_chunks and related_symbols). This is strong transparency beyond a simple action statement.
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 two sentences with no wasted words. It front-loads the main purpose and then details the mechanism and output fields. The output format is presented clearly without unnecessary elaboration.
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?
For a retrieval tool with no output schema and no annotations, this description is quite complete: it explains the process, the inputs' roles, and the exact return structure. It could mention edge cases or error behavior, but the core functionality and expected output are clearly covered, making it sufficient for a typical agent to invoke and interpret the result.
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?
Despite 0% schema description coverage, the description adds meaning to the parameters: 'query' is the vector search term, 'top-k' is the number of hits, and 'one hop' explains the default graph expansion depth (hops). It does not explicitly mention that hops is configurable, but the schema's default and the description's narrative cover the core semantics.
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 'Two-stage retrieval in one call: semantic search + graph expansion', which precisely states the tool's function and distinguishes it from siblings like search_similar_code (semantic only) and search_related_code (graph only). It clearly identifies the resource (context combining chunks and symbols).
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 implies the tool is used when both semantic and graph context are needed, but it does not explicitly state when to use it over the sibling tools or mention alternatives. The phrase 'in one call' hints at consolidation, but no direct when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search: embed query, return top-k matching code chunks.
Each result carries score + payload (path, name, kind, line range, docstring, text).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | 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 full burden. It discloses the core behavior (embedding query, returning top-k results) and the result payload shape, but it does not mention whether prior ingestion is required, whether the operation is read-only, or any error/rate-limit behavior. It is adequate for a search tool but not fully transparent.
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 two concise, front-loaded sentences that state the core action and result format. Every phrase earns its place with no redundant or filler content.
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?
For a two-parameter tool with an output schema, the description is nearly complete: it specifies the query input, top_k behavior, and result fields. However, it does not differentiate from sibling search tools or mention the dependency on ingest_repo, leaving some selection uncertainty.
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 compensate. It does clarify the roles of both parameters: 'embed `query`' explains the query as a semantic input, and 'top-k matching code chunks' explains the top_k integer. However, it does not specify query format constraints or top_k bounds, leaving some ambiguity.
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 clearly states a specific action: semantic search that embeds the query and returns top-k matching code chunks. It distinguishes itself from sibling search tools by emphasizing 'semantic' and 'code chunks', though it does not explicitly name alternatives.
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?
No guidance is provided on when to use this tool versus search_context or search_related_code. The description implies a semantic similarity use case but does not state prerequisites, such as requiring a previously ingested repository, nor does it offer exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return store stats: vector count (Qdrant) + node/edge counts (graph).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully specifies the data returned and that it aggregates from two stores, but it does not explicitly confirm it is read-only or mention potential costs, permissions, or consistency caveats.
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 a single concise sentence that front-loads the action ('Return store stats') and then specifies the exact metrics. Every word earns its place with no redundancy.
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?
For a parameterless stats tool, the description adequately conveys the return value content. It could mention the format or types of counts, but given the simplicity and lack of output schema, it is substantially complete.
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?
The tool has zero parameters, so the schema is fully complete. The baseline for 0 params is 4, and the description adds context by explaining what the tool returns, which is sufficient since there are no parameters to document.
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 clearly states the tool's function: returning store statistics with specific metrics (vector count from Qdrant, node/edge counts from graph). The verb+resource structure is specific and distinguishes it from the sibling search/ingestion tools.
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?
No explicit timing, prerequisites, or alternative tools are mentioned. The usage is implied—if you need store stats, this is the tool—but there is no direct guidance on when to choose it over siblings or any exclusions.
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. Dates show when Glama detected each change.
v0.1.0doctoringest_reposearch_contextsearch_related_codesearch_similar_codestore_statsThe tools are clearly distinct: search_similar_code handles semantic search, search_related_code handles graph-based structural search, and search_context combines both. ingest_repo, store_stats, and doctor cover ingestion, statistics, and diagnostics respectively, with no overlapping purposes.
Most tools follow a verb_noun pattern (search_context, search_related_code, ingest_repo, store_stats). The 'search_*' prefix is consistently used for search operations. The 'doctor' tool deviates by using a noun instead of a verb, but it is still recognizable and not chaotic.
With 6 tools, the set is well-scoped for a code comprehension server. Each tool serves a distinct and necessary function (ingest, search, stats, diagnostics), and the count is well within the optimal range.
The tool surface covers the full lifecycle for code search and understanding: ingestion with reset capability, multiple search modalities (semantic, structural, combined), statistics, and pre-flight diagnostics. No major gaps are apparent for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Project memory, semantic code search, and grounded agent context.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tamaz-sujashvili/senior-code-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server