CIP Kernel MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CIP_MCP_AUDIT_LOG | No | Environment override for the audit log location used by the CIP Kernel MCP Server. | |
| CIP_MCP_CACHE_DIR | No | Environment override for the cache directory used by the CIP Kernel MCP Server. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_systemB | Collect a read-only kernel inventory: version, config, loaded modules, distro. Read-only, least privilege (R2/R3). |
| query_cveB | Look up a CVE by id (kernel.org cve records first, NVD fallback). Returns a normalized record with affected files, version ranges, and fixing commits (R1/R3). |
| find_patchesB | Locate existing fixes along the provenance chain: mainline -> stable -> CIP branches. Live linux-cip mirror queries resolve the CIP backports (backport commit, first tagged CIP release, e.g. v5.10.163-cip35); degrades to record-derived candidates when the mirror is unavailable (R1/R2/R4). |
| cve_applicabilityB | Cross-reference a CVE against this system version + config + modules. Two gates: version range (fix already present / not introduced) and config mapping. Verdict always carries an evidence chain (R3). |
| build_dependency_graphB | Build a dependency graph from the system inventory: kernel config, loaded modules, and known subsystem mappings. Nodes include subsystems, modules, drivers, symbols. Edges represent dependencies, hierarchy, and usage relationships (Module A3, Rule R6). |
| query_dependency_graphA | Query a dependency graph for impact analysis, dependency chains, or paths. Query types: impact-analysis (what depends on these nodes?), dependency-chain (what do these nodes depend on?), subgraph, path (find paths between nodes). Built from system inventory (Module A3, Rule R6). |
| draft_backportA | Draft a kernel-rule-compliant backport into a staging directory. Creates draft patches with proper backport headers (commit upstream, Rule R4). Never applies to running system (Rule R1/R5). Returns conflict report and evidence chain. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool maps to a distinct step or resource: inventory (scan_system), CVE lookup (query_cve), fix discovery (find_patches), applicability assessment (cve_applicability), graph build vs. graph query, and drafting (draft_backport). The build/query dependency graph pair is cleanly split by verb, and find_patches vs. cve_applicability are separated by purpose (locate fixes vs. decide applicability). No meaningful overlap remains.
Six of seven tools use a consistent verb_noun pattern (scan_system, query_cve, find_patches, build_dependency_graph, query_dependency_graph, draft_backport). The lone exception, cve_applicability, is noun-only and breaks the verb-first convention, but it is still readable and unambiguous.
Seven tools is well-scoped for a CVE assessment and backport drafting workflow, with each tool earning its place. Nothing feels padded or missing at the count level.
The surface covers the core lifecycle: scan inventory, look up a CVE, find fixes, assess applicability, explore dependencies, and draft a backport. Minor gaps exist around CVE discovery (no way to list/enumerate CVEs affecting a version) and post-draft verification of the staged patches, but agents can work around these.