Senior Code MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
The 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the prerequisite (graph.json exists), the read-only nature of the search, and the return format (neighbor nodes with distance). It does not elaborate on error handling when prerequisites are not met.
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 three crisp sentences, front-loaded with the main action, followed by output and prerequisites. No redundant words or information.
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 an output schema exists, the description adequately covers purpose, parameters, and a critical prerequisite. It lacks edge-case behavior, but the core information needed for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that 'names' are the starting points and 'hops' is the distance limit, adding meaning beyond the schema's types and default. It also implies names refer to symbols in the ingested graph, which is helpful.
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 it performs structural search by expanding a graph from given names up to a hop distance. It distinguishes itself from siblings by specifying callers/callees/imports, making its purpose unambiguous.
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?
It provides clear context as a structural search and gives a prerequisite (repo must be ingested), which helps the agent know when it is applicable. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![senior-code-mcp MCP server](https://glama.ai/mcp/servers/Tamaz-sujashvili/senior-code-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Tamaz-sujashvili/senior-code-mcp)

Score Badge

Copy to your README.md:

[![senior-code-mcp MCP server](https://glama.ai/mcp/servers/Tamaz-sujashvili/senior-code-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Tamaz-sujashvili/senior-code-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Tamaz-sujashvili/senior-code-mcp'

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