codelore-mcp

by Ayush-Sadekar

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: estimation, exploration, search, ingestion, syncing, etc. There is no overlap or ambiguity in their purposes.
Naming Consistency5/5
All tool names follow the verb_noun snake_case pattern consistently (e.g., estimate_cost, explore_repo, find_todos). Even informal terms like 'todos' fit the pattern.
Tool Count5/5
10 tools cover the full lifecycle of repository ingestion and querying without being excessive or thin. The count is well-scoped for the server's purpose.
Completeness4/5
The tool set covers estimation, ingestion, exploration, search, syncing, and annotation assistance. Missing a delete tool, but the core workflows are complete.
Average 4.5/5 across 10 of 10 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively communicates that the tool is a read-only report with no destructive side effects. It implies safe usage without altering state. However, it does not detail error behavior or edge cases (e.g., what happens if scope is not set), but for a simple informational tool, this is sufficient.
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 sentences, each adding value. It front-loads the main purpose and immediately follows with usage guidance. No wasted words or redundant information.
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?
While the description covers purpose and usage well, it is incomplete because it fails to explain the three optional parameters. These parameters are likely used to specify paths for resolution, and their absence from the description leaves the agent uncertain about how to use them. Given the tool's simplicity, this omission significantly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (repo_root, vault_root, chroma_path) with 0% schema description coverage, meaning no descriptions in the schema. The tool description does not mention these parameters at all, failing to explain their purpose or how they influence the tool's behavior. This is a critical gap, as the description adds no value over the raw 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 clearly states the tool's purpose with a specific verb ('Report') and resource ('which repo this codelore server is currently scoped to'). It also distinguishes from sibling tools by noting that other tools already refuse to resolve to codelore's source, making this tool useful for sanity-checking.
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 explicitly tells when to use the tool ('useful to sanity-check before a multi-step task, or to debug a misconfigured .mcp.json') and when not ('Not required before calling other tools: they already refuse...'). This provides clear guidance on context.
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, but the description discloses that file/directory summaries are loaded from JSON (skipping Claude calls) while explaining that ChromaDB question generation still requires a Claude call per chunk. This provides valuable behavioral insight beyond the input schema.
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 moderately sized and front-loaded with the main purpose. It is structured into clear paragraphs (purpose, usage, parameter detail, additional note). Every sentence adds value, though some parameter details could be more succinct.
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 tool has 4 parameters, no annotations, and an output schema (not shown), the description covers usage context and one parameter well but omits details for other parameters and potential side effects (e.g., overwriting existing vault). It is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 provides detailed semantics only for extra_frontmatter_json (type, example, supported data types) and explains explanations_json_path's origin. However, repo_path and vault_output_path lack any description beyond their names, leaving significant gaps.
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 verb (rebuild) and resource (vault and search index) with specific context (from an existing explanations file). It distinguishes from siblings like ingest_repo and sync_vault by highlighting the avoidance of Claude CLI calls for file summaries.
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 explicitly states when to use this tool: to re-run vault generation without making Claude CLI calls for file summaries, such as after code changes or to iterate on vault structure without LLM cost. It also notes that ChromaDB still calls Claude once per chunk, setting clear expectations.
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 exist, so the description carries full disclosure burden. It explains the tool is read-only (resolves path, does not modify), returns relative and absolute paths, and that vault_root/chroma_path are optional. It does not mention authentication or rate limits, but these are not relevant for a resolver tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, workflow, guardrail, return info), but it is verbose and contains some repetition (e.g., the workflow is described twice). A tighter version could be more efficient.
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?
Given the tool is a coordinator that resolves a path for appending, the description covers all necessary context: the workflow, interaction with sibling tools (vault_read, vault_append), fallback path logic, and environment variable defaults. No gaps remain for correct agent usage.
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?
With 0% schema description coverage, the description must compensate. It explains that 'query' is the annotation text for semantic search, and that 'vault_root' and 'chroma_path' are optional (omit to use env vars). This adds meaning, but lacks details on query format or value constraints.
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's purpose: 'Find the most relevant vault note... and return its path' for appending. It distinguishes this from the actual append tool. However, the tool name 'vault_append' is misleading because the tool itself does not append, which may cause initial confusion.
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?
Provides explicit when-to-use examples ('add a note', 'mark TODO as resolved'), a detailed 3-step workflow, and a guardrail against using vault_write. This gives the agent clear context and exclusions for correct usage.
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 the burden. It explains the behavior: semantic search for relevant files, scanning for comments, showing recent commits. It also describes optional parameters and guardrails. However, it does not detail the output format, but this is somewhat mitigated by the presence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy with multiple paragraphs. It is front-loaded with purpose and usage, but includes guardrails and alternatives that could be more concise. While structured, it could be tightened.
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 complexity (5 parameters, 0% schema coverage, no annotations), the description covers purpose, usage, behavior, guardrails, and parameter explanations. It differentiates from siblings and mentions output schema existence. Almost complete, but parameter details are slightly lacking.
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 0%, so description must compensate. It explains that vault_root, chroma_path, and repo_root are optional and can be omitted to use env vars. It also states query is required for semantic search. However, it does not describe n_files or chroma_path explicitly, and no parameter-level details are given. Partial compensation.
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 finds TODO/FIXME comments and recent git activity. It distinguishes from siblings like search_code by focusing on project progress and task management. The verb 'find' and resource 'todos' are specific and unambiguous.
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 provides when to use: for project progress/task management questions with example queries (e.g., 'what's left to do'). It also advises against using vault_write unless explicitly requested, and suggests vault_append and vault_read as alternatives. This is excellent guidance.
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 carries the full burden of behavioral disclosure. It mentions the optional guidelines_path and default behavior, but does not explicitly state that the tool is read-only or describe side effects. The guardrail about vault_write is a behavioral rule but relates to another tool.
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 concise with four structured sentences: purpose, usage, guardrail, parameter explanation. It is front-loaded and each sentence adds value, though the guardrail could be considered extraneous to the tool definition.
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?
Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description adequately covers purpose, usage, and parameter semantics. The guardrail provides additional context for safe usage, making it informationally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains the parameter: 'guidelines_path is optional — omit to use CODELORE_GUIDELINES_PATH, or pass a path directly to read any guidelines document without reconfiguring.' This adds meaning beyond the schema's default 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 returns architectural guidelines and coding conventions, with specific verb 'Return' and resource 'project's architectural guidelines'. It distinguishes from sibling tools (e.g., explore_repo, search_code) by focusing on guidelines and conventions.
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 lists explicit use cases: 'questions about coding style, architectural patterns, conventions, how to structure new code, or what rules the project follows.' It provides clear context for when to use, but does not explicitly state when not to use or name 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?
The description explicitly states it 'Does not call Claude or modify anything — safe to run at any time', which is critical behavioral information. Since no annotations are provided, this fulfills the transparency burden.
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 compact with three sentences, no redundancy, and the main purpose is front-loaded. Every sentence adds value.
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?
Given the simple input (one required parameter) and the presence of an output schema, the description sufficiently covers the purpose and usage. No additional details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'repo_path' has no description in the input schema (0% coverage). The description does not clarify format or expected values, leaving the agent to infer from the tool name. More detail would improve usability.
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 verb 'Estimate' and the resource 'Claude CLI calls ingesting a repo'. It distinguishes from the sibling tool 'ingest_repo' by specifying it is a preliminary estimation step.
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 advises to 'Use this BEFORE running ingest_repo on a large codebase', and explains what it reports and that it is safe to run at any time, providing clear guidance on when to use.
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?
No annotations are provided, so the description carries the full burden. It thoroughly explains behavior: dry_run modes, conflict detection logic, handling of new/deleted files, and sync log entries. No contradictions.
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 somewhat lengthy but front-loaded with the core purpose. Every sentence earns its place, but some consolidation could improve conciseness without losing clarity.
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?
Given the tool complexity (5 params, 0% schema coverage, output schema present), the description is complete. It covers behavior, usage prerequisites, and dry_run workflow. No gaps with the output schema.
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 0%, so the description must compensate. It explains the dry_run parameter in detail and mentions repo_path implicitly. Other parameters like vault_root are standard paths; the description adds value beyond the schema but stops short of explicitly documenting every parameter.
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 'Detect and apply repo changes since the last ingest,' specifying the verb (sync) and resource (vault). It distinguishes from siblings like ingest_repo and rebuild_vault by focusing on incremental updates.
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 advises when to use ('after code changes') and recommends a dry_run first. It also notes the requirement for a git repository. Explicit alternatives are not named, but the context is clear.
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?
Despite no annotations, the description fully discloses behavior: starts from vault INDEX, breadth-first traversal, returns summaries at increasing depth, and explains vault_root resolution (optional, defaults to CODELORE_VAULT_ROOT, resolves to configured repo). No destructive actions implied.
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?
Well-structured: purpose sentence, use-case list, traversal behavior, alternatives, guardrail, parameter details. Every sentence serves a purpose. No filler.
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?
Given the tool's complexity (graph traversal, optional root, integration with other tools) and existence of output schema, the description covers all necessary aspects: usage, behavior, parameters, and context. No gaps remain.
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 has 0% property descriptions, but the description adds meaning: max_depth controls traversal depth (implied by 'increasing depth'), and vault_root is optional with explicit fallback behavior. Could explicitly mention default values but still adds significant value beyond the 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 clearly states 'Get a structured overview of the repo by traversing the vault graph.' It distinguishes from sibling tools like vault_read (drill down) and vault_write (modification) by specifying appropriate use cases and alternatives.
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 advises when to use: onboarding questions such as 'explain the repo' or 'give me an overview.' Provides explicit alternatives (vault_read for drilling) and a guardrail against using vault_write unless explicitly requested, leaving no ambiguity.
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?
No annotations provided, so description carries full burden. It discloses all behavioral traits: runs AI summaries via Claude CLI, writes Obsidian vault, indexes into ChromaDB, and warns about cost. No contradictions.
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?
Well-structured: clear first sentence, then parameter details, post-ingestion steps, and warning. No redundant sentences. Front-loaded with purpose.
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?
Covers all aspects for a complex tool: inputs, pipeline steps, outputs, warnings, and links to other tools. Output schema exists, so return values need not be detailed. Complete for effective use.
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 description must compensate. It explains repo_path_or_url (local or URL) and extra_frontmatter_json in detail. vault_output_path is only implied in post-ingestion instructions, but overall adds significant meaning beyond 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?
Description clearly states the tool ingests a code repository into codelore, generating a vault and search index. It distinguishes from sibling tools like estimate_cost, explore_repo, etc., by specifying the full pipeline unique to this tool.
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?
Explicit guidance on when to use: accepts local path or GitHub URL. Warns to run estimate_cost first on large repos, and directs to pass outputs to query tools. Provides clear context for usage.
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?
No annotations provided, so description carries full burden. It explains the vector search mechanism, confidence labeling based on cosine distance, max_distance tuning, fallback logic, and integration with Obsidian MCP tools. Fully transparent about behavior.
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?
Information-dense and structured with clear sections, but somewhat lengthy. Every sentence adds value, yet could be more concise without losing clarity. Front-loaded with purpose.
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?
Given output schema exists (so return values need not be described), the description covers all relevant aspects: behavior, parameters, fallback, guardrails, and integration with sibling tools. Complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates thoroughly: explains query as natural language, n_results default, vault_root/chroma_path as optional env-var overrides, and max_distance as similarity threshold. Adds meaningful context beyond schema defaults.
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 searches the codebase using semantic similarity for functional questions, and distinguishes it from sibling tools like search_simple and grep through explicit fallback and avoidance instructions.
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?
Provides explicit when-to-use (functional questions), when-not-to-use (avoid grep, vault_write only on user request), and fallback behavior (call search_simple on low confidence results). Includes detailed post-processing steps (read file directly, use vault_read).
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:

[![codelore-mcp MCP server](https://glama.ai/mcp/servers/Ayush-Sadekar/codelore-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Ayush-Sadekar/codelore-mcp)

Score Badge

Copy to your README.md:

[![codelore-mcp MCP server](https://glama.ai/mcp/servers/Ayush-Sadekar/codelore-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Ayush-Sadekar/codelore-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/Ayush-Sadekar/codelore-mcp'

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