Skip to main content
Glama
Sign In
kconfig-mcp

kconfig-mcp

by 0xmortuex
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

kconfig_load

Parses a Kconfig tree and optional .config into a named session so an AI agent can inspect symbols, trace dependencies, and reason about configuration.

Instructions

Parse a Kconfig tree (and optionally a .config) into a session named name.

kconfig_path is the top-level Kconfig file; its directory becomes srctree. env supplies the variables the tree expands - Linux needs SRCARCH and ARCH (e.g. {"SRCARCH": "x86", "ARCH": "x86_64"}); Zephyr needs ZEPHYR_BASE and friends. Missing ones are named in the error. shell: "run" executes the tree's $(shell,...) compiler probes with a POSIX sh, as make menuconfig would. "dry" runs nothing (no compiler needed, works on Windows); compiler-feature symbols then read as absent. A Linux tree takes 10-40 s to parse; the session stays loaded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "kconfig_path": "<kconfig_path>"
    },
    "name": "kconfig_load"
  }
}

Input Schema

NameRequiredDescriptionDefault
envNo
nameYes
shellNorun
config_pathNo
kconfig_pathYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses that kconfig_path's directory becomes srctree, that missing env vars are reported by name in the error, that dry mode makes compiler-feature symbols read as absent, and that parsing takes 10-40s with the session remaining loaded. Gaps remain around what happens if a session with the same `name` already exists and whether loading has any on-disk side effects.

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?

Purpose is front-loaded in the opening line, then environment, shell mode and performance notes follow in short line-broken clauses. There is no filler; every sentence contributes operational information.

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 five-parameter tool with no annotations, the description covers inputs, prerequisites, mode trade-offs, error behavior and latency, and an output schema exists so return values need not be described. The main remaining omission is session-collision behavior (reload vs error vs replace) and what config_path actually does.

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 must compensate, and it explains four of five parameters in real depth: `name` (session identity), `kconfig_path` (top-level file, srctree derivation), `env` (with concrete example values per ecosystem), and `shell` (run vs dry semantics and their consequences). `config_path` is only acknowledged as 'optionally a .config' without saying how it affects symbol values, which is the one unaddressed parameter.

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 first sentence gives a specific verb and resource ('Parse a Kconfig tree'), names the optional input (.config), and states the result ('into a session named `name`'), which cleanly separates it from siblings like kconfig_diff, kconfig_save and kconfig_search.

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?

It conveys when this is the right call (you want a persistent, parsed session) and gives per-ecosystem prerequisites, e.g. Linux needs SRCARCH/ARCH while Zephyr needs ZEPHYR_BASE. It also frames the shell choice as a usage decision (run for faithful probes, dry for no-compiler/Windows). It stops short of explicit 'use X instead' routing or when-not-to-use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools