Codebase Context

by PatrickSys

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2.3.0
Disambiguation5/5
Each tool targets a distinct aspect of codebase context: detection, health, metadata, indexing, memory, style guide, references, patterns, refresh, remember, and search. No two tools have overlapping purposes; descriptions clearly differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_codebase_health, detect_circular_dependencies). The only exception is 'remember' which is a single verb but remains clear and fits the pattern.
Tool Count5/5
11 tools is well-scoped for a codebase context server. It covers indexing, querying, analysis, and memory without being overwhelming. Each tool earns its place.
Completeness4/5
The tool set covers reading and writing codebase knowledge, analysis (dependencies, health, references), and search. Minor gaps exist, such as no direct file content retrieval or code review integration, but the domain of 'context' is well-served.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on April 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Elastic License 2.0.
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?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It reveals one behavioral trait (automatic routing), but does not address potential error states, authentication requirements, or the read-only nature of the operation. This provides moderate transparency but leaves gaps.
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 extremely concise with two sentences, front-loading the key behavioral hint. Every word adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the moderate complexity of the tool (multiple metadata types), the description provides a reasonable overview but does not fully specify the return structure, error conditions, or behavior when no project is known. It is adequate but not comprehensive.
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?
The input schema has 100% description coverage for both parameters (project and project_directory). The description adds no additional meaning beyond what the schema already provides. Per the guidelines, with high schema coverage, a baseline of 3 is appropriate.
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 the tool retrieves codebase metadata including specific items like framework, dependencies, architecture patterns, and statistics. This sufficiently distinguishes it from sibling tools that have different focuses (e.g., health, style guide), though it could be more explicit about what it does not cover.
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?
The description mentions automatic routing to the active project when known, providing some context. However, there is no explicit guidance on when to use this tool versus alternatives like get_codebase_health or get_team_patterns, nor any mention of prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions auto-routing to active project and returns risk info, but does not explicitly state read-only nature or any side effects. Incomplete for a tool with no annotations.
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?
Three sentences with no fluff. First sentence sets behavioral expectation, second states purpose, third gives filtering options. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a read tool with good schema coverage, but lacks detail on return format (e.g., what constitutes 'health signals' or 'highest-risk'). Output schema is absent, so more description would help.
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 description coverage is 100%, so baseline is 3. Description adds context for 'file' parameter (why to use it) but largely mirrors schema. Does not compensate for any missing schema details.
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 retrieves actionable codebase health signals, returns highest-risk files with reasons, or single file when requested. It distinguishes from siblings like get_codebase_metadata and detect_circular_dependencies.
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?
Implies routing to active project automatically, so user may not need to specify project, but no explicit when-to-use or when-not-to-use compared to alternatives. Lacks exclusions for specific scenarios.
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 provided, the description carries the full burden. It reveals that results are sorted by length and notes that shorter cycles are often more problematic. However, it does not explicitly state whether the operation is read-only or has side effects, nor does it mention performance implications for large codebases.
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 three sentences, efficient but with a minor redundancy: the first sentence about routing ('Routes to the active/current project automatically') is not central to the tool's purpose. Overall, it is well-structured and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return value sorting and interpretation but lacks details on output format, data structure of cycles, or potential limitations (e.g., large graphs). Given no output schema, this is adequate but leaves ambiguity for complex filtering needs.
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?
The input schema covers all three parameters with descriptions, achieving 100% schema description coverage. The tool description does not add meaningful detail beyond what the schema already provides (e.g., 'scope' is described as an optional path prefix in both). Baseline score of 3 applies.
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: 'Analyze the import graph to detect circular dependencies between files.' It identifies a specific verb (analyze/detect) and a distinct resource (circular dependencies in imports), differentiating it from sibling tools like get_codebase_health.
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 explains why circular dependencies are problematic ('can cause initialization issues, tight coupling'), implying the tool's value. However, no explicit guidance on when to use this tool versus alternatives (e.g., get_codebase_health), nor any exclusions or prerequisites.
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 bears full responsibility. It mentions automatic routing to active project and return values, but lacks details on error cases, latency, or index prerequisites. Adequate but not thorough.
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?
Two concise sentences that front-load key information: routing and core function. No fluff, every sentence adds value.
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?
Despite lacking an output schema, the description mentions return values (usageCount and snippets). It covers the core function and project routing, but could elaborate on snippet ranking and error conditions.
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%, so baseline is 3. The description adds little beyond what the schema already provides for parameters. The routing behavior hinted at is not tied explicitly to parameters.
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 purpose: finding concrete references to a symbol in indexed chunks. It uses specific verbs and resources, and the name itself is descriptive. Though it doesn't explicitly differentiate from siblings, the function is distinct.
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 on when to use this tool versus alternatives like search_codebase or detect_circular_dependencies. The description does not mention prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions automatic routing to the active project. It fails to disclose behavioral traits such as read-only nature, side effects, error handling, or limitations, which is a significant gap for a retrieval tool.
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 extremely concise: two sentences plus a line listing filters. Every sentence provides essential information without extraneous words, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description covers purpose and usage well but lacks details on return values, result count, pagination, or error conditions. It is adequate but not fully complete for a tool that influences important decisions.
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?
The description adds value by listing filter enums and query usage, but it omits two parameters (project and project_directory) entirely. Since schema description coverage is 100%, the baseline is 3, but missing param details reduce the added value.
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 retrieves team conventions, architectural decisions, and known gotchas, with automatic routing to the active project. It distinguishes itself from siblings like get_style_guide or get_team_patterns by being a general memory retrieval tool.
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 advises 'CALL BEFORE suggesting patterns, libraries, or architecture,' providing clear context for when to use. It lacks explicit when-not-to-use or alternative tool mentions, but the usage instruction is strong.
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?
The description mentions automatic routeing to the active project and re-indexing behavior, but does not disclose side effects, permissions, or what happens to the existing index. With no annotations, more detail would be beneficial.
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?
Three sentences conveying essential info, though the first sentence is slightly ambiguous ('Routes to...'). Still, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns or how to interpret results, leaving the agent without critical information for a re-index operation.
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?
All parameters have schema descriptions (100% coverage). The description adds minor guidance on incrementalOnly usage, but mostly restates schema info, so it provides limited added value.
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 re-indexes the codebase and supports full or incremental modes, distinguishing it from siblings like search_codebase or get_indexing_status.
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 advises using incrementalOnly=true for faster re-indexing of changed files, but does not explicitly state when not to use the tool or mention alternative tools for specific scenarios.
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 reveals the automatic project routing behavior and the query nature, suggesting a read-only operation. However, it does not explicitly state that it is non-destructive, what happens if no project is active, or any error conditions, leaving some behavioral ambiguity.
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 only two sentences, front-loading the key automatic routing feature and then the main query purpose. Every sentence is necessary and without fluff, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the tool returns. It does not describe the return format, error handling, or behavior when no results are found. The deprecated 'project_directory' parameter is not addressed. This leaves significant gaps for an agent to use the tool 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?
Parameter descriptions in schema cover 100% of parameters, already defining each parameter's purpose. The description adds value by explaining the automatic routing behavior for the optional 'project' parameter, clarifying that omitting it uses the active project, which goes beyond the schema's description.
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 queries style guide rules and architectural patterns from project documentation, using the verb 'Query' and resource 'style guide rules and architectural patterns'. It distinguishes itself from siblings like search_codebase (which is broader) and get_team_patterns (which is team-specific) by focusing specifically on style guide documentation.
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 usage for querying style guide rules in the current project due to automatic routing, but does not explicitly state when to use it over alternatives (e.g., search_codebase for general search, get_team_patterns for team patterns). No when-not or explicit alternative 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?
No annotations provided, so description carries full burden. Mentions automatic project routing (a behavioral trait) and returns consensus patterns. No side effects or mutability mentioned, but seems read-only.
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?
Two concise sentences, front-loaded with key purpose and automatic behavior. No unnecessary words.
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 tool with 3 params and no output schema, description is fairly complete: explains what it does, mentions project auto-routing, and lists pattern types. Could clarify return structure or 'consensus patterns' further.
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 coverage is 100% with clear param descriptions. Description adds context by listing example pattern categories (DI, state, testing) which correspond to the enum values, providing meaning beyond 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?
Description clearly states the tool retrieves team pattern recommendations for specific categories (DI, state management, etc.) and mentions automatic project routing. Distinguished from siblings like get_codebase_health and get_style_guide.
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 when-to-use or when-not-to-use guidance. Context signals and sibling names imply usage for pattern analysis, but no direct alternatives mentioned.
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?
No annotations are provided, so the description must cover behavioral traits. It mentions 'Routes to the active/current project automatically' but does not disclose side effects (e.g., whether memories overwrite, persistence, permissions, or rate limits). The instructions on writing style give some behavioral expectations but leave significant gaps.
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 structured with headings (USER TRIGGERS, DO NOT, HOW TO WRITE) and front-loads the key action. While it is somewhat lengthy, every section serves a purpose. Minor redundancy in listing all triggers could be trimmed, but overall it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters (4 required) and no output schema, the description provides good guidance on when and how to call, but omits post-call behavior (e.g., success confirmation, error handling). The agent must infer that memories are stored since get_memory exists. Context is adequate but not fully 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?
Schema coverage is 100%, so baseline is 3. The description adds value by providing guidance on how to write 'memory' (5-10 words) and 'reason' (1 sentence), and explains when to use 'failure' type. This enriches the schema descriptions and helps the agent use parameters effectively.
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 purpose: to remember/record something when the user explicitly asks. It lists specific user triggers ('Remember this', 'Record this', 'Save this for next time') and provides instructions for when to call it. This differentiates it from siblings like get_memory, which retrieves memories.
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?
The description provides explicit guidelines: 'CALL IMMEDIATELY when user explicitly asks to remember/record something' and 'DO NOT call unless user explicitly requests it.' It also gives writing conventions ('ONE convention per memory', 'memory: 5-10 words', 'Skip: one-time features, code examples, essays'), making the usage clear.
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 provided, so description carries full burden. It mentions automatic routing behavior, which is useful. No destructive actions implied, but lacks details on permissions or rate limits. For a read-only status tool, it's transparent enough.
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?
Two sentences, no fluff. First sentence gives routing behavior, second gives tool purpose and sibling reference. Exceptionally concise.
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?
Covers purpose, routing, and sibling reference. No output schema, but description mentions return includes state, statistics, and progress. Missing detailed output structure, but adequate for a status check tool.
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 descriptions for both parameters. Description adds that project accepts various formats and project_directory is deprecated, slightly complementing schema. Baseline 3 is appropriate.
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?
Description clearly states 'Get current indexing status: state, statistics, and progress.' Verb and resource are specific, and it distinguishes from sibling refresh_index.
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?
Explicitly says 'Routes to the active/current project automatically' and 'Use refresh_index to manually trigger re-indexing when needed,' providing clear when-to-use and alternatives.
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, the description fully carries behavioral transparency. It describes default behavior (compact mode, 6 results, graph context), full mode, intent parameter effects, and hints about response metadata. It also warns about includeSnippets default and recommends read_file for code.
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 well-structured, front-loading key information about routing and search function. It provides detailed mode and intent guidance but could be more concise by merging some sentences. Overall, it balances detail and readability.
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 no output schema, the description explains the compact mode return shape (graph context, pattern summary, etc.) and mentions budget metadata. It covers filters and parameters. However, it omits error handling, pagination beyond limit, and behavior for empty queries. Still fairly complete for a search tool.
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 coverage is 100%, baseline is 3. The description adds value by explaining the compact mode result count (at most 6 vs schema default limit of 5), clarifying the intent parameter's role for preflight, and noting the routing behavior for project. This exceeds basic schema info.
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 searches the indexed codebase, auto-routes to active project, and details the return format. It distinguishes from siblings like get_codebase_health or detect_circular_dependencies by being a search tool.
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 guides when to use compact vs full mode and when to pass intent for preflight. It notes that includeSnippets is false by default and to prefer read_file. However, it does not contrast with sibling tools or mention when not to use the tool.
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:

[![codebase-context MCP server](https://glama.ai/mcp/servers/PatrickSys/codebase-context/badges/card.svg)](https://glama.ai/mcp/servers/PatrickSys/codebase-context)

Score Badge

Copy to your README.md:

[![codebase-context MCP server](https://glama.ai/mcp/servers/PatrickSys/codebase-context/badges/score.svg)](https://glama.ai/mcp/servers/PatrickSys/codebase-context)

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/PatrickSys/codebase-context'

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