ckg-mcp is an MCP server that serves Compressed Knowledge Graphs (CKGs) — pre-structured, typed dependency graphs — enabling LLM agents to traverse exact relationships instead of searching unstructured text chunks.
Available Tools:
list_domains() — List all available CKG domains (65 free, 85 with Pro). Call this first, as exact domain names returned here are required by other tools.
query_ckg(domain, concept, depth) — Retrieve the dependency subgraph around a concept, showing prerequisites and dependents up to a configurable number of hops (1–5).
get_prerequisites(domain, concept) — Trace the full ordered chain of prerequisite concepts back to root concepts. Useful for onboarding, gap-filling, or sequencing study paths.
search_concepts(domain, query) — Find concepts within a domain using partial, case-insensitive matching. Use this to discover exact concept labels before calling other tools.
list_agent_blueprints() — List pre-built agent configurations for specific use cases.
get_agent_blueprint(use_case) — Get a full agent blueprint including required domains, workflow steps, constraints, prompt template, and orchestration hints.
Key Characteristics:
No database, vector store, embeddings, or API key required
Compatible with any LLM (Claude, GPT, Gemini, Llama, Mistral) and agent frameworks (LangChain, AutoGen, CrewAI)
Deterministic traversal — cannot fabricate relationships
~11× fewer tokens than RAG with ~4× better F1 accuracy
Domains span AI tools, STEM, life sciences, pedagogy, business, and more
Enables LangGraph agents to use structured graph queries for dependency analysis, prerequisite chains, and blast radius computations as part of agent workflows.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ckg-mcp Show prerequisites for Prior Authorization in glp1-obesity"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your agents retrieve. They should traverse.
Read-only. The server can only return edges that exist in the data. It returns nothing rather than inferring a path that isn't there.
Get Pro → · Benchmark → · graphifymd.com →
Every agent that reasons about a domain — HIPAA, GPU inference, calculus, contract law — does one of three things:
Approach | What breaks |
Long system prompt | No structure. Drifts with every model update. Cannot traverse. |
RAG retrieval | Probabilistic. Accuracy degrades at each hop. Expensive per query. |
Fine-tuning | 6-month cycle. Stale by delivery. Retrains when knowledge shifts. |
All three share the same failure: the agent re-infers domain structure on every query instead of reading structure that was declared once.
In our open benchmark (KRB v0.6.2 — reproduce it yourself): RAG achieves 0.123 macro F1 on multi-hop domain queries. CKG achieves 0.471. At 5 hops, the gap widens: RAG 0.170, CKG 0.772.
The token cost compounds the accuracy problem: the average RAG query costs 2,982 tokens. The average CKG traversal costs 269 — measured across 19 benchmark domains.
These numbers are ours, on our benchmark. The dataset is public on HuggingFace. Run it yourself.
Related MCP server: kg-memory-mcp
A Compressed Knowledge Graph (CKG) is a domain structured for traversal, not retrieval.
Not a document. Not a vector index. A pre-compiled DAG of concepts, typed dependency relationships, and prerequisite chains — compressed to the minimum tokens that carry the maximum structure. Served over MCP. Traversed deterministically.
Agent asks: "What does TensorRT-LLM require to run on Hopper?"
CKG returns: TensorRT-LLM
├─ [REQUIRES] CUDA Toolkit
│ ├─ [ENABLES] cuBLAS
│ └─ [ENABLES] CUDA Driver API
├─ [REQUIRES] FP8/FP4 Quantization
│ └─ [REQUIRES] Hopper SM90 Architecture
└─ [ENABLES] Triton Inference Server
└─ [ENABLES] NIM Microservice Runtime
269 tokens · declared edges only · no inference at query time
RAG would: ~2,982 tokens · probabilistic retrieval · degrades at 3+ hopsYou go from prompting the domain into existence to asking questions inside it.
Perplexity is a model aggregator. Shortest route to Nemotron — click the dropdown, select the model, query. But it's their pipeline, their infrastructure. Your queries go through their system.
If you want to run Nemotron yourself — sovereign, private, on your own hardware — you need to navigate NVIDIA's stack: NGC API key, NIM container, Enterprise License, inference endpoint. The dependency chain is non-obvious. Most developers hit the wrong door first.
Without CKG: search the docs, hit the Enterprise License wall, spend two hours finding build.nvidia.com.
With CKG:
query_ckg("Nemotron Model", "nvidia-nim")
→ [REQUIRES] Model Weights
→ [REQUIRES] NGC Container Registry
→ [REQUIRES] NGC API Key ← start here
query_ckg("NIM Docker Container", "nvidia-nim")
→ [REQUIRES] NGC API Key
→ [REQUIRES] NVIDIA AI Enterprise License ← production path
→ [ENABLES] NIM Microservice ← what you're building towardTwo traversals. Correct path. No wrong doors. The graph knew — the model just told you.
Edge type | Meaning | Agent use |
| Hard prerequisite — must exist first | Sequencing, gap detection |
| Unlocks a downstream capability | Optimization paths |
| Conceptual proximity | Disambiguation |
| Concrete realization of an abstraction | Architecture mapping |
| Meaningful opposition | Tradeoff reasoning |
ConceptID, ConceptLabel, Dependencies, TaxonomyID
1, Taylor Series, "", Analysis
2, Power Series, "", Analysis
3, Convergence, "2:REQUIRES", Analysis
4, Higher-Order Der., "5:REQUIRES", Calculus
5, Derivative, "6:REQUIRES", Calculus
6, Continuity, "7:REQUIRES", CalculusNo embeddings. No probabilistic retrieval. Built once, reviewed once, traversed forever. Graph data is authored and versioned by Graphify.md — served remotely, not shipped in the package.
Single-agent traversal is the efficiency gain. Multi-agent orchestration is where it compounds.
Liu et al. (arXiv:2606.30986) measure Context Transaction Cost (CTC): the tax paid every time context crosses an agent boundary. Their finding: context efficiency collapses from 18.2 in Q1 to 1.6 by Q4 across pipeline stages — 91% degradation with no model change.
CKG addresses all three root causes they identify:
CTC component | What it is | CKG's response |
Token Latency Burden | Compute cost of transmitting context | 269 tokens instead of 2,982 |
Handoff Cost | Serialization loss at agent boundaries |
|
Compression Loss | Information destroyed when context is summarized | The graph is the compressed form — done once, offline |
When agent A hands off to agent B, neither re-retrieves the domain. They both traverse the same declared graph. Structured context doesn't consume your context window — it opens it.
uvx ckg-mcp # no install — runs immediately
# or
pip install ckg-mcp # Python ≥ 3.10How it works: The package is a thin MCP shell. Graph data lives on Graphify.md's servers — no domain CSVs are bundled in the wheel. Every traversal calls
ckg-mcp.onrender.com, so a network connection is required. Free tier: 10 calls/hour per IP, resets automatically. Pro tier: unlimited withCKG_API_KEY.
{
"mcpServers": {
"ckg": { "command": "uvx", "args": ["ckg-mcp"] }
}
}claude mcp add ckg -- uvx ckg-mcp{ "mcpServers": { "ckg": { "command": "uvx", "args": ["ckg-mcp"] } } }You have access to the ckg MCP server — a typed dependency graph catalog
of 97 domains (mathematics, GPU inference, healthcare, law, robotics,
regulatory, AI tooling, and more). When answering questions about any of
these domains, call query_ckg() or get_prerequisites() before responding.
Do not infer dependency chains — traverse the graph instead.list_domains()
→ see all 68 free domains
query_ckg("Taylor Series", "calculus", 3)
→ prerequisite chain: Function → Limit → Continuity → Derivative →
Higher-Order Derivatives → Convergence → Power Series → Taylor Series
route_query("Taylor Series", "calculus")
→ model_tier: haiku · reasoning: direct
→ why: 2-hop, 1 branch — shallow lookup
→ subgraph: [Taylor Series → Power Series → Convergence] (31 tokens)
get_prerequisites("Business Associate Agreement", "hipaa-compliance")
→ Covered Entity → PHI Definition → Minimum Necessary Standard →
Access Controls → Breach Notification Rule → BAA
query_ckg("FlashAttention-3", "nvidia-gpu-inference", 3)
→ SRAM Tiling · On-Chip Memory Budget · Transformer Attention ·
Softmax Stability → FlashAttention-3 → Multi-Head Attention → KV CacheEvery node carries a source_url and a source_hash (SHA-256 of source bytes at extraction time) where available. The full audit chain: edge answer → graph commit hash → source_content_hash → knowledge_source_ref.
# For domains with per-node hashes:
curl -s <source_url> | sha256sum
# compare to source_hash — mismatch = stale edge or silent upstream editVia MCP — verify_source(concept, domain) returns source URL, hash, and verification command. Run scripts/refresh_hashes.py to recompute.
Reference implementation from GuardrailDecisionV1.
These are our numbers on our open benchmark. The dataset is on HuggingFace. Run it yourself before citing them.
git clone https://github.com/Yarmoluk/ckg-benchmark && cd ckg-benchmark
pip install -r evaluation/requirements.txt
python evaluation/ckg_harness.py --domain calculus
python evaluation/analyze_results.pySystem | Macro F1 | Tokens / query | Cost / 1K queries | F1 at 5 hops |
CKG (this package) | 0.471 | 269 | $7.81 | 0.772 |
RAG (text-embedding-3-small) | 0.123 | 2,982 | $76.23 | 0.170 |
GraphRAG (MS global, v1.1) | 0.120 | 3,450+ | — | — |
What this means:
4× F1 — in our benchmark, on our dataset. Open and reproducible.
11× fewer tokens — the 269 and 2,982 figures are averages across 19 benchmark domains.
F1 rises with depth — CKG 0.37 at 1 hop → 0.77 at 5 hops. RAG is flat. Graph traversal does not degrade at depth; retrieval does.
GraphRAG — not a meaningful improvement over RAG at higher token cost. The word "graph" is not the win. A pre-compiled, declared graph is.
One derived metric we use internally: Retrieval Density Score (F1 ÷ tokens per query). CKG scores roughly 42× higher than RAG on this ratio. It is not a standard benchmark metric — we use it to reason about accuracy-per-token efficiency.
Mathematics
calculus · pre-calc · algebra-1 · linear-algebra · geometry-course · statistics-course · functions · fft-benchmarking
Engineering & Computer Science
circuits · digital-electronics · computer-science · quantum-computing · signal-processing · intro-to-graph
Life Sciences
biology · bioinformatics · genetics · ecology · chemistry
Clinical & Health (free)
glp1-obesity · glp1-muscle-loss · dementia
Regulatory & Government
fda-drug-approval-chain · fda-adverse-event-chain · federal-procurement-chain · gao-oversight-chain
AI, ML & Data
machine-learning-textbook · data-science-course · conversational-ai · langchain-core · dbt-core · apache-iceberg
AI Tools (provider graphs)
claude-anthropic · claude-skills · cursor · deepseek · gemini-api · grok-xai · kimi-moonshot · midjourney · openai-platform · qwen · vercel-ai-sdk
Robotics & Physical AI
ros2-architecture · robot-motion-planning
Learning & Pedagogy
prompt-class · tracking-ai-course · automating-instructional-design · microsims · infographics · it-management-graph
Business & Society
economics-course · personal-finance · ethics-course · theory-of-knowledge · systems-thinking · digital-citizenship · blockchain · unicorns
Reference & Culture
art-of-war · laudato-si · learning-linux · us-geography · asl-book · reading-for-kindergarten · moss
Free — MIT | Pro — $99/mo | |
Domains | 68 | 97 |
Healthcare & clinical | — | HIPAA · CPT coding · ICD-10 · payer formulary · drug interactions · clinical decision chain · medical billing |
Enterprise data stack | — | Databricks Unity · Snowflake Horizon · PostgreSQL · AWS Data Catalog · Azure Purview · GCP Dataplex · OpenLineage |
AI infrastructure | — | NVIDIA GPU inference · context-as-a-service · agent reliability · AI governance · token cost crisis |
Legal & compliance | — | Legal citation chain · contract law elements · AML/KYC chain · investment risk chain |
Agent blueprints | 2 | 2 + priority access |
Domain updates | Community | Managed |
License | MIT | Commercial |
Activate in 60 seconds:
export CKG_API_KEY=cs_live_your_key_here
# restart your MCP client — all 97 domains appear in list_domains()Pre-built agent specs: which domains to load, step-by-step workflow, ready-to-paste system prompt, and a LangGraph orchestration hint. Skip writing the context layer from scratch.
list_agent_blueprints()
→ gpu-inference-optimizer — trace GPU bottlenecks, surface optimization paths
context-as-a-service-advisor — design CKG-based retrieval pipelines
get_agent_blueprint("gpu-inference-optimizer")
→ Required domains: nvidia-gpu-inference, context-as-a-service
Workflow: diagnose → trace prerequisites → identify path → recommend
Prompt template: [ready to paste]
LangGraph hint: StateGraph · 4 nodesAll read-only. No database. No embeddings. Requires network — graph data is served from ckg-mcp.onrender.com, not bundled locally.
Tool | What it does |
| Every available domain. Start here. |
| Prerequisites + dependents, up to N hops |
| Full upstream chain in dependency order |
| Find concepts by keyword — use before query_ckg |
| Returns subgraph + model tier (haiku/sonnet/opus) from graph depth — context and model routing in one call |
| Browse pre-built agent configs |
| Full spec: domains, workflow, prompt, LangGraph hint |
ckg-mcp is the core product of Graphify.md.
We build the context optimization layer that sits between agents and the domains they operate in. The same layer that powers this package runs inside enterprise deployments, sealed appliances, and custom vertical CKGs.
What we can say without overstating:
The benchmark is open and reproducible — not self-reported, verifiable
The graphs are human-authored and human-reviewed — not generated
The methodology is patent pending — not just a wrapper around an existing system
Plain CSV DAGs, MIT-licensed for free domains — no lock-in
Compatibility — model-agnostic:
LLM | Agent framework | MCP client |
Claude (all tiers) | LangChain / LangGraph | Claude Desktop |
GPT-4o / GPT-4 | AutoGen | Claude Code |
Gemini 2.0 / 2.5 | smolagents | Cursor |
Llama 3.x | CrewAI | Cline |
Mistral / DeepSeek | OpenAI Agents SDK | Any MCP stdio client |
No graph database. No vector store. Python ≥ 3.10. Single dependency (mcp). stdio transport.
The free and Pro catalog covers breadth. Enterprise needs are specific: your regulatory environment, your internal taxonomy, your product domain, your data stack.
Graphify.md builds and maintains custom CKG domain graphs for enterprise teams — compressed, versioned, deployed over your MCP stack.
Sealed Appliance — a private CKG + query server in your environment. Air-gapped. Your data stays yours.
Typical entry: a pilot on your highest-value domain, delivered in one session, measured against your existing retrieval setup.
Spotted a wrong edge? A RELATES_TO that should be REQUIRES? A missing concept?
Edge corrections are the highest-value contribution — the graph gets more useful with every fix. Open an issue or PR on GitHub.
Package | What it does |
This repo — 97 domains, context optimization layer | |
20 NVIDIA AI domains, free, MCP-native | |
Cross-session agent memory | |
Open benchmark — reproduce the F1 numbers | |
Path-Fidelity Score — reasoning path correctness |
benchmark: ckg-benchmark v0.6.2
dataset: huggingface.co/datasets/danyarm/ckg-benchmark
benchmarked: true
this_domain_f1: 0.471
queries_tested: 19
rag_baseline_f1: 0.123
graphrag_baseline_f1: 0.120
mean_tokens: 269
paper: github.com/Yarmoluk/ckg-benchmark/blob/main/paper/main.pdf@misc{yarmoluk2026ckg,
title = {Benchmarking Knowledge Retrieval Architectures Across Educational
and Commercial Domains: RAG, GraphRAG, and Compressed Knowledge Graphs},
author = {Yarmoluk, Daniel and McCreary, Dan},
year = {2026},
note = {v0.6.2. https://github.com/Yarmoluk/ckg-benchmark}
}graphifymd.com · Pro · Benchmark
Patent pending. Built by Daniel Yarmoluk / Graphify.md.
Return the full ordered chain of concepts to understand before a target concept.
Use this for onboarding, gap-filling, or sequencing study — it walks every upstream dependency back to the root concepts. For a two-directional neighborhood (prerequisites AND dependents) use query_ckg; to resolve an exact concept name use search_concepts.
Args: domain: Exact domain name from list_domains. concept: Target concept to trace back to its roots. Matched case-insensitively; a partial name resolves to the first containing match.
Returns: One line listing the prerequisite chain in dependency order, e.g. "Prerequisite chain for 'Taylor Series' in calculus (5 concepts): Function -> Derivative -> ... -> Taylor Series". States that the concept is a root if it has no prerequisites, or that it was not found.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| concept | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses matching behavior (case-insensitive, partial name resolution), output format with examples, and edge cases (root concept, not found). Lacks mention of side effects or rate limits, but these are not critical for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, and front-loaded with purpose. Somewhat verbose but every sentence adds value, so it maintains clarity without being overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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) and lack of output schema, the description is remarkably complete. It explains purpose, usage context, parameter behavior, return format with examples, and edge cases. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds significant meaning. For 'domain' it specifies to use exact name from list_domains; for 'concept' it details matching behavior and partial resolution. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return the full ordered chain of concepts to understand before a target concept.' It specifies the verb, resource, and scope, and distinguishes from siblings by directing to alternative tools for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'for onboarding, gap-filling, or sequencing study.' Also provides clear exclusions: for two-directional neighborhood use query_ckg, for exact name resolution use search_concepts. This provides excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every Compressed Knowledge Graph (CKG) domain this server can answer about.
Call this FIRST, before the other tools. Each domain is a self-contained dependency
graph for one subject area (e.g. "calculus", "google-dataplex", "glp1-obesity"). The
domain argument required by query_ckg, get_prerequisites, and search_concepts must be
an exact name returned here. Takes no arguments.
Returns: One line: the domain count followed by the comma-separated domain names, e.g. "Available domains (65): algebra-1, aws-data-catalog, calculus, ...".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no arguments, describes return format with example, and implies read-only behavior, fully adequate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading purpose, usage, and output. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument list tool with output schema, description provides complete context: what it returns with example. No gaps given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, 100% coverage). Description states 'Takes no arguments' which adds value beyond schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every CKG domain, using specific verb 'list' and resource 'domain'. It distinguishes from siblings (query_ckg, get_prerequisites, search_concepts) by noting they require a domain argument.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this FIRST, before the other tools' and explains that the domain required by siblings must be an exact name returned here, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the dependency subgraph around a concept: what it requires, and what builds on it.
Use this for the local neighborhood of a concept — both the prerequisites it depends on and the downstream concepts that depend on it. For ONLY the upstream prerequisite chain, use get_prerequisites instead. If unsure of the exact concept name, call search_concepts first to find it.
Args: domain: Exact domain name from list_domains (e.g. "calculus", "google-dataplex"). concept: Concept to center the subgraph on. Matched case-insensitively; a partial name resolves to the first containing match (e.g. "taylor" -> "Taylor Series"). depth: Upstream prerequisite hops to include, 1-5 (default 3; higher values are capped at 5). Downstream "builds toward" concepts are always included to 2 hops.
Returns: A Markdown report titled with the resolved concept, with a "Prerequisites (what you need to know first)" tree and a "Builds toward (concepts that depend on this)" tree, plus the concept's taxonomy tag when present. If the concept is not found, returns a message listing up to 5 similar names to retry with.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| concept | Yes | ||
| depth | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though no annotations are provided, the description details key behaviors: case-insensitive matching, partial name resolution, depth limits (upstream 1-5, downstream fixed 2 hops), return format (Markdown report with two trees and taxonomy tag), and error handling (similar names listed if not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a succinct summary, usage guidance, parameter details, and return format. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dependency subgraph), zero schema coverage, and no annotations, the description covers all essential aspects: purpose, parameters, behavior, return format, error handling, and differentiation from siblings. The output schema exists but the description adds necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 providing clear meanings for each parameter: domain (exact name from list_domains), concept (case-insensitive partial match), and depth (default 3, range 1-5). It also explains how concept matching works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the dependency subgraph around a concept, specifying both prerequisites and downstream concepts. It distinguishes itself from the sibling tool 'get_prerequisites' by noting that the latter is for only upstream chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool ('local neighborhood of a concept') and when not to ('For ONLY the upstream prerequisite chain, use get_prerequisites instead'). It also suggests calling 'search_concepts' if the concept name is uncertain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find concepts in a domain by partial name — use this to discover exact concept labels.
Run this before query_ckg or get_prerequisites when you do not know the precise label a concept is stored under. Does a case-insensitive substring match over every concept name in the domain.
Args: domain: Exact domain name from list_domains. query: Substring to match against concept names (e.g. "mask", "iceberg", "lineage").
Returns: Up to 20 matching concept names (title-cased), each annotated with its taxonomy tag in brackets when present, e.g. " - Masking Policy [GOV]". Returns a "no concepts matching" message when there are no matches.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It fully explains behavior: case-insensitive substring match, return up to 20 results with taxonomy tags, or a 'no concepts' message. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary first, then parameter details and return description. Approximately 100 words with no fluff, earning each sentence's presence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete given context: explains behavior, parameters, return format, and usage context relative to siblings. Lack of error handling details is acceptable for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but description provides full semantics: domain is exact name from list_domains, query is substring with examples. Return format is also detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds concepts in a domain by partial name, with a specific verb and resource. It distinguishes itself from siblings by advising use before query_ckg or get_prerequisites when exact labels are unknown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (before query_ckg/get_prerequisites when label is unknown) and describes the behavior (case-insensitive substring match). Implicitly suggests alternatives for when label is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.1get_prerequisiteslist_domainsquery_ckgsearch_conceptsScored across 4 tools
Each tool has a distinct purpose: listing domains, searching concepts, getting full dependency subgraphs, and fetching only prerequisite chains. Descriptions explicitly differentiate when to use each, eliminating ambiguity.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_domains, search_concepts, query_ckg, get_prerequisites.
Four tools is appropriate for a knowledge graph query server. Each tool covers a fundamental operation without redundancy or gaps.
The set covers the full lifecycle of querying a knowledge graph: listing domains, searching for concepts, and retrieving both prerequisite chains and full dependency neighborhoods. No obvious gaps given the read-only purpose.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
Repository knowledge graph MCP server for codebase understanding and debugging.
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Shared, peer-validated knowledge archive for AI agents — search, contribute, and validate via MCP
