MCP — CKG-NVIDIA-AI

MCP server — Compressed Knowledge Graph (CKG) for the full NVIDIA AI developer stack.

4× F1 · 11× fewer tokens · 1006 nodes · deterministic traversal.

Read-only. This MCP server never writes, mutates, or executes. Every response is a declared graph traversal — not inference, not retrieval, not generation.

The problem every AI team hits

More agents. More retrieval. More context. And accuracy drops.

This is the intelligence paradox: the more AI you add, the more tokens you burn re-discovering structure your system already knows — or could know. Research finds 73% of enterprise tokens are redundant context. In multi-agent pipelines, context efficiency collapses from 18.2 in Q1 to 1.6 by Q4 — 91% degradation with no model change.

The model is not the bottleneck. The context is.

Every time your agent calls out to ask what TensorRT-LLM requires to run on Hopper, it spends ~2,982 tokens re-inferring a relationship that could be declared once and traversed in 269. That difference compounds across every query, every agent, every boundary crossing.

The fix is not a better model. It is structured context.

What this package does

A CKG is a layer — a fast, inexpensive way to convert a large volume of domain documentation into structured, agent-traversable knowledge. Instead of retrieval, the agent traverses. Instead of inference, it reads declared relationships.

This package gives your agent the NVIDIA AI developer stack as its first layer: 20 domains, 1006 nodes, every prerequisite chain declared and typed.

Layers stack. Context windows open.

Each additional CKG layer costs your agent fewer tokens to operate, not more. Structured context is systematic augmentation — it does not replace what the model knows, it makes what it knows precise and auditable.

query_ckg("TensorRT-LLM", "nvidia-tensorrt-triton", depth=3)

→ TensorRT-LLM requires:
    CUDA Toolkit → CUDA Driver API, cuBLAS
    FP8 / FP4 Quantization → Hopper SM90 Architecture
  TensorRT-LLM enables:
    Triton Inference Server → NIM Microservice Runtime

That traversal cost 269 tokens. A RAG call over the same question costs ~2,982. The graph doesn't guess — it traverses.

Explore the graph

Once installed, paste this into Claude, Cursor, or any MCP client and see what comes back:

You have access to the nvidia-ai CKG. I want to understand what it actually takes to deploy
a real-time speech AI pipeline on NVIDIA Jetson at the edge — not the marketing version,
the real dependency chain.

Start here:
  get_prerequisites("Riva ASR", "nvidia-riva")

Then follow the chain into the inference layer:
  query_ckg("TensorRT-LLM", "nvidia-tensorrt-triton", depth=3)

Then map the edge hardware:
  get_prerequisites("Jetson Orin NX", "nvidia-jetson")

Present the result as a layered architecture map — foundation at the bottom, application at the
top, typed edges (REQUIRES / ENABLES) labeled between layers. Show where the three domains share
prerequisites. Flag anything that would block a cold-start deployment.

The graph will traverse four domains, surface shared prerequisites, and show you exactly what stands between an idea and a running system — no hallucination, no guessing, just declared relationships. See what it gives you.

Quickstart

Option 1 — Hosted (no install)

No pip. No CLI. Works in Claude Desktop and claude.ai out of the box.

Claude Desktop — open ~/Library/Application Support/Claude/claude_desktop_config.json and add:

{
  "mcpServers": {
    "nvidia-ai": {
      "url": "https://ckg-nvidia-ai.onrender.com/sse",
      "transport": "sse"
    }
  }
}

Restart Claude Desktop. The nvidia-ai tools appear automatically.

claude.ai — Settings → Connectors → Add custom connector → paste:

https://ckg-nvidia-ai.onrender.com/sse

Cursor / Windsurf / Cline:

{ "mcpServers": { "nvidia-ai": { "url": "https://ckg-nvidia-ai.onrender.com/sse", "transport": "sse" } } }

Option 2 — Local install (CLI / developers)

Run on a GPU in one click — L40S, qwen2.5:14b, notebook pre-loaded:

Or install locally:

pip install ckg-nvidia-ai

uvx ckg-nvidia-ai          # MCP server mode

Claude Desktop (local):

{
  "mcpServers": {
    "nvidia-ai": {
      "command": "uvx",
      "args": ["ckg-nvidia-ai"]
    }
  }
}

Claude Code:

claude mcp add nvidia-ai -- uvx ckg-nvidia-ai

Cursor / Cline / Windsurf (local):

{ "mcpServers": { "nvidia-ai": { "command": "uvx", "args": ["ckg-nvidia-ai"] } } }

System prompt snippet

You have access to the nvidia-ai MCP server — a typed dependency graph of 20 NVIDIA AI domains
(NIM, NeMo, TensorRT, CUDA, Isaac, Cosmos, Riva, and 13 more). When answering questions about
NVIDIA infrastructure, prerequisites, or deployment, call query_ckg() or get_prerequisites()
before responding. Do not guess dependency chains — traverse the graph instead.

Accuracy model

Every edge was declared by a human reviewer. The graph is in active development — corrections arrive from the community weekly.

Three-state confidence:

Typed edges — semantic precision:

If an edge isn't declared, the traversal returns nothing rather than hallucinating a path. That silence is signal.

Tools

All tools are read-only. No writes, no side effects.

list_domains()

Returns all 20 NVIDIA AI domains. Start here — domain slugs are required by every other tool.

search_concepts(query, domain)

Find concepts by keyword within a domain.

search_concepts("speculative decoding", "nvidia-nim")
→ Speculative Decoding [Optimization]
   Draft Model [Component]
   KV Cache [Infrastructure]

query_ckg(concept, domain, depth=3)

Traverse the graph from a concept — prerequisites and dependents.

query_ckg("FlashAttention-3", "nvidia-cuda-x-libraries", 3)
→ Prerequisites: SRAM Tiling → On-Chip Memory → Warp Occupancy → ...
   Enables: Multi-Head Attention → KV Cache → Speculative Decoding

get_prerequisites(concept, domain)

Full ordered prerequisite chain — everything needed to understand or deploy first.

get_prerequisites("Isaac Lab", "nvidia-isaac")
→ Isaac Lab → Isaac Sim → USD Composer → Omniverse Kit → ...

ask_nvidia(question, domain="") — new in v0.4.0

Natural-language question answered by Qwen, grounded on the CKG. Runs entirely locally via Ollama. The model answers only from graph-declared relationships — not parametric memory.

ollama pull qwen2.5:14b   # one-time setup

ask_nvidia("What does TensorRT-LLM require to run on Hopper?")

→ [REQUIRES] CUDA Toolkit → cuBLAS, CUDA Driver API
  [REQUIRES] FP8 / FP4 Quantization → Hopper SM90 Architecture
  [ENABLES]  Triton Inference Server → NIM Microservice Runtime
---
Grounded via TensorRT-LLM · nvidia-tensorrt-triton · model: qwen2.5:14b

ask_nvidia("What does Clara Parabricks require for whole-genome sequencing?")

→ Parabricks requires: NVIDIA GPU (Volta or later) → CUDA Toolkit ≥ 11.0
  Uses: cuBLAS, cuFFT for acceleration kernels
  Integrates with: MONAI for downstream analysis
---
Grounded via Parabricks · nvidia-clara · model: qwen2.5:14b

If Ollama is not running, ask_nvidia() returns raw graph context so the calling agent can still use it.

No new dependencies. mcp[cli] is still the only install requirement.

route_query(question, domain) — CKG Router

The graph depth IS the routing signal. Returns the optimal model tier and reasoning approach derived from hop count — not a heuristic, not a cost threshold. The NVIDIA dependency graph decides.

A/B — before vs after routing:

# Baseline (no routing)
query_ckg("TensorRT-LLM", "nvidia-tensorrt-triton")
→ subgraph returned, caller guesses model...
→ calls GPT-4o on everything, ~2,400 tokens, $0.072/query

# Treatment (route_query)
route_query("TensorRT-LLM", "nvidia-tensorrt-triton")
→ model_tier: opus
→ reasoning_approach: sparql_cot
→ why: 4-hop chain (CUDA → cuBLAS → TensorRT → TensorRT-LLM)
→ calls Opus with SPARQL CoT scaffold, ~847 tokens, $0.013/query

Same answer. 65% cheaper. Zero guesswork. Graph depth made the decision.

Works with any LLM — Claude, GPT-4o, Gemini, Llama. The routing decision is model-agnostic.

Resources

Two static resources readable from any MCP client — no auth required.

Example: read ckg://nvidia/nvidia-nim

# nvidia-nim — CKG

## Nodes
- NIM Microservice Runtime [Framework]
- Speculative Decoding [Optimization]
- KV Cache [Infrastructure]
...

## Edges (prerequisites)
- NIM Microservice Runtime —[REQUIRES]→ TensorRT-LLM
- NIM Microservice Runtime —[REQUIRES]→ Triton Inference Server
...

Resource Templates

Parameterized domain access — fill {domain} with any slug from list_domains().

Prompts

Three built-in prompts — invoke from any MCP client to start a structured traversal session.

explore_nvidia_stack

Traverses TensorRT-LLM, Isaac Lab, and NIM in parallel, then renders an interactive D3.js force-directed graph with color-coded domains and labeled edge types.

map_deployment_chain

Maps the full dependency chain for a production Riva ASR pipeline on Jetson at the edge — finds shared prerequisites across three domains, flags cold-start blockers.

find_what_i_need

Interactive: asks which NVIDIA technology you want to use, then calls get_prerequisites() + query_ckg() at depth 4 and presents a layered architecture — what to install first, what depends on what, what you unlock when it's running.

Domains

20 stacks · 1006 nodes · call list_domains() for the full machine-readable list.

Source provenance — verifiable to the byte

Every node carries a source_url and a source_hash (SHA-256 of the source document's bytes at extraction time). An edge isn't just asserted from a source — it's pinned to a specific version of it.

curl -s https://docs.nvidia.com/nim/large-language-models/latest/about-nim-llm/overview.html | sha256sum
# expected: 069a128bb69b165e49aa315c375dcdbffbf7a37f21b6eb258c815fda73950109

Via MCP — verify_source("NIM Endpoint", "nvidia-nim"):

source_url:  https://docs.nvidia.com/nim/large-language-models/latest/about-nim-llm/overview.html
source_hash: sha256:069a128bb69b165e49aa315c375dcdbffbf7a37f21b6eb258c815fda73950109
verify:      curl -s '<url>' | sha256sum

Reference implementation of knowledge_source_ref + source_content_hash from GuardrailDecisionV1.

Benchmark

Evaluated on KRB Benchmark v0.6.2 — open dataset, reproducible methodology, fixed baselines.

4× F1 · 11× fewer tokens · 5-hop F1 0.772 vs 0.170 · auditable by design

5-hop reasoning is where the gap compounds: retrieval degrades with each hop; graph traversal does not.

How the graph is built

Each domain is a DAG stored as typed edge CSV — human-authored and human-reviewed:

ConceptID, ConceptLabel, Dependencies, TaxonomyID
1, TensorRT-LLM,    "",                    Framework
2, CUDA Toolkit,    "",                    Platform
3, FP8 Quantization,"2:REQUIRES",          Optimization
4, Hopper SM90,     "2:REQUIRES",          Architecture
5, Speculative Dec.,"1:REQUIRES|4:REQUIRES",Optimization

No embeddings. No vector index. No probabilistic retrieval. The graph is the compressed form — built once, reviewed once, traversed forever.

Why context efficiency collapses — and how CKG reverses it

Liu et al. (arXiv:2606.30986) formally quantify Context Transaction Cost (CTC): the compound tax paid every time context crosses an agent boundary. In multi-agent pipelines, CTC efficiency falls from 18.2 in Q1 to 1.6 by Q4 — 91% collapse with no model change.

CKG attacks all three root causes:

Structured context doesn't consume your context window. It opens it.

The alternative to fine-tuning

When task-specific data is scarce, fine-tuning is often the first instinct — and frequently the wrong one. Fine-tuning requires thousands of labeled examples, a training budget, and a retraining cycle every time your domain shifts. By the time a large enterprise model project completes, the knowledge it was trained on is often already stale.

CKG encodes domain knowledge once as a typed graph. When the knowledge changes — new regulations, new product, new market — you update the graph. Not the model.

Directional intelligence, deployed today, updatable tomorrow — at 11× lower token cost.

The commercial case in three parts:

The opponent isn't just fine-tuning — it's the perfectionism-as-procurement-strategy trap: 18 months and significant budget chasing the last few accuracy points while competitors ship directional answers at $7.81/query. Fine-tuning handles the final mile of specialization. CKG handles the knowledge architecture the fine-tuned model still needs to operate correctly.

Enterprise risk coverage:

Corrections welcome

Spotted a wrong edge? A RELATES_TO that should be REQUIRES? A missing concept in Riva or Isaac?

Edge corrections are the highest-value contribution. The graph gets more useful with every fix. Open an issue or PR — see CONTRIBUTING.md for the review format.

EVAL

benchmark: ckg-benchmark v0.6.2
dataset: huggingface.co/datasets/danyarm/ckg-benchmark
benchmarked: false
rag_baseline_f1: 0.123
graphrag_baseline_f1: 0.120
mean_tokens: 269
paper: github.com/Yarmoluk/ckg-benchmark/blob/main/paper/main.pdf

Want a CKG for your domain?

A CKG is a knowledge layer — the context optimization component of an agent stack. Instead of retrieval, your agent traverses declared relationships. Fast to build, inexpensive to run, updatable without retraining.

Turn your company documentation, internal APIs, competitive intelligence, or regulatory requirements into a CKG layer in a single session. Stack it with this one. Each layer opens more of your context window without adding token cost.

graphifymd.com — contact us for custom domain CKGs and enterprise solutions, including Sealed Appliance: a private CKG + query server deployed in your environment.

CKG Catalog · Context Optimization · Context Architecture · Token Efficiency · Accuracy

Ecosystem

This package is part of the Graphify.md CKG stack.

graphifymd.com/pro/ — custom domain CKGs, sealed appliances, enterprise.

Patent pending. 42× Token Intelligence — more intelligence per watt.