ckg

by MohitAswani

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: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: locate finds definitions, entry_point finds starting points, search is hybrid, get_context retrieves summaries, get_source retrieves raw code, neighbors returns adjacent nodes, expand does BFS, get_repo_map gives an overview, pack_neighborhood packs dependency context, and get_minimal_context offers a quick orientation. No two tools are easily confused.
Naming Consistency4/5
Tool names mostly follow a verb-based or get_ prefix pattern (locate, search, expand, get_context, get_source, get_repo_map). However, entry_point, neighbors, and pack_neighborhood deviate from the verb-first pattern, causing minor inconsistency. Still, all names are descriptive and lowercase.
Tool Count5/5
With 10 tools, the server is well-scoped for navigating a code knowledge graph. Each tool serves a specific need in the exploration workflow, from quick lookup to deep context gathering, without redundancy.
Completeness4/5
The toolset covers major aspects of codebase exploration: finding symbols (locate), entry points (entry_point), searching (search), retrieving context/source (get_context, get_source), graph traversal (neighbors, expand), overview (get_repo_map), and packing context (pack_neighborhood). A minor gap might be a dedicated tool for listing all entry points or finding usages, but the existing tools largely compensate.
Average 3.6/5 across 10 of 10 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
With no annotations, the description should disclose behavioral traits. It mentions 'source packed in topological order to a token budget' but does not clarify side effects, output format, or required permissions. The behavior is opaque.
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 a single sentence, making it concise. However, it is cryptic and lacks structure, reducing readability and clarity. It would benefit from clearer organization.
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 mention what the tool returns. For a complex operation like packing a neighborhood, this is a critical gap. The tool's role among siblings (e.g., locating, searching) is also unclear.
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 relates 'hops' to 'k-hop dependency' and 'budget' to 'token budget', but does not explain each parameter's meaning, format, or constraints. The description is insufficient for understanding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'k-hop dependency neighborhood' and 'packed in topological order to a token budget', which gives a vague sense of the operation. However, it lacks a clear verb and does not explicitly state what the tool returns or accomplishes, making it moderately unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The phrase 'single-shot static fallback' hints at a fallback role but does not specify context or conditions.
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?
With no annotations, the description must fully disclose behavior. It states the tool returns neighbors grouped by type, but it does not mention read-only status, performance implications, pagination, or potential side effects. This is insufficient for a tool that likely returns a complex structured result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core functionality with no redundant words. It is appropriately sized for a simple tool.
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?
Given no output schema and potential overlap with siblings, the description lacks important details: the meaning of 'adjacent', the structure of the response, and the enumeration of edge families. It is not complete enough for an agent to use confidently.
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 schema has 0% description coverage for the only parameter 'id'. The description does not explain what 'id' refers to (e.g., a node identifier in the graph). The parameter is left implicit, which may confuse agents unfamiliar with the domain.
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 that the tool returns all adjacent nodes of an id, grouped by edge family. This provides a specific verb-resource combination and distinguishes from siblings by mentioning edge family grouping. However, it could be more explicit about what 'adjacent nodes' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'get_context', 'expand', or 'pack_neighborhood'. There is no mention of prerequisites, exclusions, or typical use cases.
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, so the description must cover behavioral traits. It lists returned fields but does not mention any side effects, permissions, rate limits, or whether it is read-only. The term 'generated summary/context' implies a fetch, but explicit read-only hint is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. It front-loads the purpose ('A node's generated summary/context') and immediately explains parameter usage. Every word earns its place.
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 params, no output schema), the description covers the basics. However, it does not define 'node' or its relationship to sibling tools, and it lacks output details (e.g., format of the returned fields). Additional context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well: it explains that 'id' is for a single node and 'ids' for multiple nodes. This adds meaning beyond the bare schema. Could be improved by specifying format or 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 returns a node's generated summary/context with specific fields (title, summary, etc.). It distinguishes between single and batch retrieval via 'id' vs 'ids'. However, it does not differentiate from sibling tools like 'get_source' or 'get_minimal_context'.
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 gives basic guidance on using 'id' for one node and 'ids' for multiple nodes, but lacks when-not-to-use instructions or alternatives among siblings. No explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the BFS algorithm and k-hop limit, but does not mention if it's read-only, error handling, default for k, or performance traits.
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?
One tightly packed sentence with no wasted words. Front-loaded with the core algorithm name (BFS), efficiently conveying the essential constraints.
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, yet the description omits what the tool returns (nodes, edges, paths?). Missing any mention of limits on k, error conditions, or relationship to sibling tools.
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%, but description adds meaning for all parameters: 'k hops' for k, 'ONE edge family' for edge_type, and 'from a node' for id. The example 'calls' clarifies enum usage. However, id could be more precisely defined.
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 it performs BFS up to k hops along a single edge family from a node, using 'calls' as an example. It differentiates from siblings like 'neighbors' (likely one-hop) and 'search' (different scope), but doesn't specify the output type.
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 traversal along a single edge type with limited depth, but provides no explicit when-to-use or when-not-to-use guidance. No contrast with other tools like 'neighbors' or 'locate' is given.
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 adds behavioral context: the tool ranks summaries by PageRank and packs them to a token budget. However, it does not disclose potential costs, auth needs, or whether it mutates state, which is a gap for a read-oriented 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?
Two sentences: the first defines the tool's output, the second gives a usage cue. No redundancy, every word contributes value.
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 simple input schema and no output schema, the description explains what the tool returns (summaries) and the ranking method (PageRank), but lacks details on output format (e.g., text, JSON) or how the budget affects results, leaving some ambiguity.
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 one parameter 'budget' described as 'token budget (default 2000)'. The description adds the meaning of 'packed to a token budget', which aligns with the schema, but does not provide additional constraints or examples.
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 provides file/package summaries ranked by PageRank, which is a specific purpose. It also gives a use case ('orient on an unfamiliar repo'), but does not explicitly differentiate from all sibling tools, though its unique output distinguishes it.
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 orientation ('Reach for it to orient on an unfamiliar repo') but does not provide explicit when-not-to-use or alternatives, leaving usage context implicit.
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?
With no annotations, the description must fully disclose behavior. It mentions the operation is 'expensive' but fails to explain error handling, rate limits, or what happens if the node does not exist. The return format is not described, leaving significant gaps for an agent.
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 short sentences convey purpose, usage guidance, and parameter hints. No unnecessary words.
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 complexity (2 params, no output schema), the description covers purpose and parameter usage but omits the return value structure, error scenarios, and prerequisites. It is adequate but not 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 descriptions are missing (0% coverage), so the description adds meaning by explaining the difference between `id` and `ids`. However, it implies these are mutually exclusive ('for one' vs 'for several'), which the schema does not enforce, potentially misleading an agent.
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 'raw source' for a node, contrasting with `locate` which provides a snippet. However, it does not define what 'source' means in this context (e.g., code text), and only differentiates from one sibling, leaving ambiguity with other siblings like `get_context`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says `locate` already includes a snippet, so this tool is often unnecessary, providing direct when-to-use guidance. It also labels the operation as 'expensive', implying careful use. However, it does not address alternatives like `search` or `get_context` for similar purposes.
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 entire burden. It describes the output (ranked hits with summaries and snippet) but does not disclose behavioral traits like read-only nature, side effects, permissions, or limitations beyond being a one-call 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 two sentences, front-loaded with the main action and output, followed by usage guidance. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the core functionality and output structure. It lacks details on parameter ranges, error conditions, or permission requirements, but for a search tool this is reasonably 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?
The input schema has 50% description coverage (only 'k' has a schema description). The description adds context that 'query' represents a feature or symbol, but does not explain the 'k' parameter or provide format constraints. More parameter detail in the description would help.
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 where a feature/symbol lives, returning ranked hits with summaries and a top-hit snippet. It differentiates from siblings by emphasizing 'ONE call' and 'no setup call required.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Start here for "where is X" / "where do we do Y" — usually all you need; no setup call required first.' This provides clear context for when to use the tool, though it does not list explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description reveals key behaviors: outputs summaries (not source), hybrid method, ranked ordering, no snippets, returns several candidates. This covers main behavioral aspects for a search 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?
Two sentences with zero wasted words. Each sentence adds distinct value: first defines the hybrid nature and output type, second specifies behavior and alternative. Ideal conciseness.
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?
While it addresses purpose and one sibling, it doesn't cover the broader toolset context (e.g., when to use get_context vs. search) or return format details. Given the sibling count and no output schema, more context would improve completeness.
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 only 50% (k described, query not), and description adds no further parameter information. It doesn't clarify query syntax or how k affects results, failing to compensate for the schema gap.
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 it performs hybrid search returning ranked summaries (not source), and distinguishes itself from the sibling 'locate' by noting it returns multiple candidates. This gives a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring 'locate' when only one item is needed, providing a clear alternative. Implies usage for multi-result scenarios, but does not contrast with other siblings like get_context or get_source.
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 carry full weight. While it describes what the tool returns (entry point, call path), it doesn't disclose any side effects, authentication requirements, or rate limits. The behavioral traits are only partially specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the core purpose, and contains no superfluous information. 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?
For a tool with 2 parameters and no output schema, the description provides sufficient context: it states the return type (entry point, call path) and usage context. However, it does not describe the return format or behavior when no entry point is found, which would be helpful for completeness.
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 50% (only 'k' has a description). The tool description mentions 'feature' but does not elaborate on the 'query' parameter's format or expected input. It adds marginal value beyond the schema, but does not fully compensate for the missing description of 'query'.
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 defines the tool's purpose with a specific verb ('Returns') and resource ('entry/boundary that dominates the feature'). It also distinguishes from the sibling 'locate' by specifying that 'entry_point' is for understanding where a feature begins, while 'locate' is for finding where a symbol is defined.
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 ('where do I start to understand X') and when not to use it ('for 'where is symbol X defined' use locate'), providing clear guidance for the AI agent.
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, but the description discloses the approximate output size (100 tokens) and content (stats, top nodes). It is a safe read operation with no side effects mentioned. Could be improved by explicitly stating it is read-only, but the description is 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 wasted words. The first sentence defines the tool, the second adds usage guidance. Perfectly front-loaded and concise.
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 (no parameters, no output schema), the description fully covers its purpose, content, and usage context. No gaps.
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?
No parameters exist, so the description does not need to add parameter details. The baseline for zero parameters is 4, and the description explains what the output contains, adding value 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?
The description clearly states the tool provides a ~100-token orientation with stats and top nodes by importance. It distinguishes itself from siblings by noting it is not a prerequisite, implying other tools are for deeper exploration.
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 to call only for a quick lay of the land, and that it is NOT a prerequisite for other tools. This provides clear when-to-use and when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/MohitAswani/ckg'

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