Kitden
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Shows which MCP servers, skills, plugins, hooks, marketplaces and instruction files (CLAUDE.md, AGENTS.md, rules, commands, agents) Claude Code, Codex and Cursor have on this computer, where each comes from, and problems such as duplicates. Read-only: this tool cannot change settings. Do not edit client settings files to work around this; tell the developer to make the change on the local page (run kitden open), which previews, backs up and can undo it.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| show_setupA | Show what each AI coding client loads for a project: MCP servers, skills, plugins, hooks, marketplaces and instruction files, with source, scope and on/off state. project_path defaults to the current folder; client (claude_code, claude_desktop_code_tab, codex, cursor) defaults to all. Read-only: this tool cannot change settings. Do not edit client settings files to work around this; tell the developer to make the change on the local page (run |
| list_findingsA | List problems for a project: duplicates, items loaded from another client's folder, the same name from another source, overrides, unknown states, untested versions, and MCP servers that bypass the gateway. Each names its clients. project_path defaults to the current folder. Read-only: this tool cannot change settings. Do not edit client settings files to work around this; tell the developer to make the change on the local page (run |
| explain_itemA | Explain one name: every definition across clients and scopes, which one loads in the project, and why. kind is optional (mcp_server, skill, plugin, hook, marketplace, instructions). Read-only: this tool cannot change settings. Do not edit client settings files to work around this; tell the developer to make the change on the local page (run |
| list_projectsA | List the projects the clients know, which clients know each one, and whether the folder still exists. Read-only: this tool cannot change settings. Do not edit client settings files to work around this; tell the developer to make the change on the local page (run |
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 4 tools
Each tool has a clearly distinct target: project inventory (list_projects), loaded configuration (show_setup), detected problems (list_findings), and single-name resolution (explain_item). The show_setup vs. list_findings boundary is reinforced by descriptions—one reports what loads, the other reports what is wrong—so misselection is unlikely.
All four names follow the same verb_noun snake_case pattern: show_setup, list_findings, explain_item, list_projects. The verbs are predictable and match the read-only nature of the server.
Four tools is well-scoped for a read-only configuration diagnostic server; each covers a distinct query axis (projects, setup, findings, single item). There are no redundant or filler tools, and the count sits comfortably in the typical 3–15 range.
The read-only diagnostic surface is largely complete: projects, per-project setup, problem findings, and per-item resolution are all covered. Minor gaps remain—no raw config export, change history, or explicit gateway-status query—but these are not central to the stated purpose and are partly addressed by list_findings.