Knowledge Graph MCP Server

by DeepakJangra239

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.4.0
Disambiguation4/5
Tools are mostly distinct, but get_structure, find_definitions, get_file_summary, and get_usage_context have overlapping information (e.g., both report classes/functions). Descriptions help differentiate, but an agent could be confused about which to use for a specific need.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., reindex_codebase, search_code, find_definitions). No mixing of styles or confusing verbs.
Tool Count5/5
8 tools cover indexing, search, structural exploration, context retrieval, and validation—well-scoped for a code knowledge graph server. Each tool serves a distinct purpose without being too few or too many.
Completeness4/5
The surface covers core operations: indexing, search, definitions, references, file summary, and edit validation. Minor gaps exist (e.g., no explicit graph query tool), but the set is largely complete for code understanding tasks.
Average 3.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic behavior (finds symbol usage). Does not disclose performance characteristics, dependencies, or whether it is read-only (implicit but not explicit).
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, efficient and front-loaded with purpose. No redundant information. Every word serves a purpose.
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?
Output schema exists, so return format is covered elsewhere. Description mentions list of files and lines, which is sufficient. Could optionally mention scope (entire codebase) or limitations, but overall adequate for a simple 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 has one parameter 'name' with 0% description coverage. Description clarifies name is the symbol, but does not specify format (e.g., fully qualified, case-sensitive) or provide examples. Adds some meaning but could be more precise.
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?
Clearly states it finds where a symbol is used, returns files and lines. Distinguishes from siblings like find_definitions (which finds definitions) and search_code (text search).
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 vs alternatives such as search_code or find_definitions. Does not explain conditions like requiring indexed codebase.
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. Describes return content (structure) and indexing requirement, but lacks disclosure on error handling (e.g., file not found, not indexed), performance implications, or side effects. Minimal transparency for a tool with no annotation safety net.
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 wasted words. Information is front-loaded: first sentence states purpose, second gives prerequisite. Ideal length for a simple tool.
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?
Output schema exists, so return format is covered elsewhere. However, description omits edge cases (e.g., behavior for empty file, unsupported languages) and does not state that file path must be relative to project root. Adequate for a straightforward tool but leaves some gaps.
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?
Input schema has 0% description coverage; the only parameter 'file_path' is not described in schema. Description adds no detail about expected format (absolute/relative), restrictions, or relationship to project index. Single parameter reduces need for elaboration, but description should at least specify path type.
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 returns the structure (classes, functions) of a specific file. Verb 'Returns' and resource 'structure of a specific file' are specific. Distinguishes from siblings like 'search_code' (searches across files) and 'get_file_summary' (likely a summary, not structural details).
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?
Provides a prerequisite ('requires the file's project to be indexed first'), which is helpful but does not guide when to use this tool versus siblings like 'find_definitions' or 'get_file_summary'. No explicit when-not-to-use or alternative 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?
The description discloses the return fields (file path, line number, docstring), providing basic behavioral insight. However, with no annotations, it lacks details on scope, performance, or error handling.
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?
Extremely concise: two sentences, 12 words. The first sentence states the purpose, the second details output. No unnecessary information.
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 low complexity (single parameter, no annotations), the description covers the essential purpose and output. The existence of an output schema further reduces the need for additional detail.
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%, but the description adds meaning by clarifying that the 'name' parameter refers to a class or function name. This sufficiently explains the parameter's role despite missing format specifics.
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 that the tool finds where a class or function is defined, specifying the resource and action. It distinguishes from sibling tools like search_code (text search) and find_references (usage search) by focusing on definitions.
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 explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when not to use it or provide references to sibling tools.
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. Discloses it returns a token-efficient summary and lists contents. Lacks mention of side effects or authorization, but for a read-only tool the description 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?
Two sentences with no filler. Front-loaded with verb and resource, then additional details.
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 one parameter and output schema present, the description covers purpose and content. Could mention it is read-only, but overall adequate for a simple inspection tool.
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 coverage is 0% and the description does not explain the 'file_path' parameter beyond implying it refers to a file. No format or constraints are clarified.
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?
Clearly states the tool returns a token-efficient summary of a file and lists included elements (imports, classes, functions, docstrings). Differentiates from siblings like 'get_structure' which likely returns structural details.
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?
Implied usage via 'Optimized for small context windows' but no explicit when-to-use, when-not-to-use, or alternative tools compared to siblings like 'get_structure' or 'find_definitions'.
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, description carries full burden. It mentions heavy operation and database creation location, but doesn't disclose whether previous index is overwritten, or potential side effects like file scanning delays.
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 concise sentences: purpose, usage guidance, output location. No redundancy, 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?
Given output schema exists (though not provided here) and one parameter, the description covers the main effect and usage context. Could mention asynchronicity or prerequisite like directory existence.
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 coverage is 0%, so description must compensate. Only one parameter 'root_path' is referenced in the output path but not described (e.g., must be absolute path, must exist). Lacks sufficient detail for correct invocation.
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?
Clearly states scanning and indexing a directory to build a knowledge graph, with specific output location. Distinguishes from sibling tools that 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?
Explicitly labels as heavy operation and recommends calling only when codebase changes significantly. No explicit when-not-to-use or alternatives, but context implies infrequent 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 are provided, so the description bears full responsibility. It discloses two specific checks (syntax errors and breaking changes) and emphasizes the 'before applying' nature, implying read-only validation. The presence of an output schema (not shown but known from context) further reduces the need to detail return values.
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 sentences: one for purpose, two listing checks, and one usage instruction. It is front-loaded with the primary action. Some structure could be improved (e.g., grouping checks), but it is efficient and free of 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 tool's simplicity (2 parameters, no enums, output schema exists), the description covers the main purpose and checks. However, it omits details like whether the tool returns errors or a simple pass/fail, and does not clarify the scope of 'breaking changes' (e.g., across entire codebase). The output schema likely fills some gaps, but the description could be more informative.
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?
With 0% schema description coverage, the description should compensate by explaining the two parameters. However, it provides no additional meaning beyond the schema: file_path and new_content are not described in terms of format, constraints, or examples. This leaves the agent to infer meaning from names alone.
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 validates a proposed code edit before applying it, listing specific checks (syntax errors and breaking changes). It distinguishes from sibling tools, which focus on codebase indexing, searching, structure, and references, none of which perform validation.
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 instructs 'Use this tool to check your code before writing it to a file,' making when to use clear. It does not explicitly state when not to use or mention alternatives, but the context of sibling tools implies the tool is for validation only.
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. It discloses that the tool returns definition, references, and calls, and mentions optimization for small LLMs. However, it does not detail side effects, performance implications, or permissions needed.
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 very concise, using a bulleted list for the three items, front-loading the purpose, and avoiding unnecessary words. 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?
The tool has an output schema (present but not shown), so the description does not need to explain return values. It covers the main use case of retrieving comprehensive symbol context. Minor addition: could mention that it combines multiple queries, but is still fairly complete.
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 0%, so the description must compensate. It states 'for a symbol' which clarifies the purpose, but does not provide format examples or constraints beyond type string. This is adequate for a single parameter but minimal.
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 retrieves comprehensive context for a symbol, listing three specific items: definition, references, and calls. It distinguishes itself from sibling tools like find_definitions and find_references by offering a combined one-shot retrieval.
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 mentions it is 'optimized for small LLMs to get full context in one shot', which implies when to use it. However, it does not explicitly state when not to use it or name alternative sibling tools for more targeted queries.
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 provided, so description carries full burden. It describes the search as 'semantic' and parameter effects (verbose includes technical details), but does not disclose potential side effects, read-only nature, or output structure. Adequate but not comprehensive.
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 short paragraphs: first states purpose, second lists parameters with brief explanations. No unnecessary words, well-structured and front-loaded.
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 complexity and presence of output schema, description covers prerequisites, parameters thoroughly. Lacks details about return format but output schema addresses that. Slightly incomplete in describing search algorithm, but sufficient for selection and invocation.
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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose and behavior (e.g., 'verbose: If True, include technical details like vectors and distances'). This 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?
Description states it performs a semantic search for code snippets, with clear verb and resource. It distinguishes from siblings by noting a prerequisite (reindex_codebase) and contrasting with other code analysis tools in the sibling list.
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?
Explicitly states prerequisite of reindex_codebase, giving clear context for when to use. Does not explicitly mention when not to use or alternatives, but the sibling list provides implicit differentiation.
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:

[![kgraph MCP server](https://glama.ai/mcp/servers/DeepakJangra239/kgraph/badges/card.svg)](https://glama.ai/mcp/servers/DeepakJangra239/kgraph)

Score Badge

Copy to your README.md:

[![kgraph MCP server](https://glama.ai/mcp/servers/DeepakJangra239/kgraph/badges/score.svg)](https://glama.ai/mcp/servers/DeepakJangra239/kgraph)

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/DeepakJangra239/kgraph'

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