Click on "Install 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., "@kimi-code-mcp use kimi to analyze the src folder and find potential bugs"
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.
English | 中文說明
Delegate codebase analysis from Claude to Kimi Code (kimi-for-coding, 256K) — cut Claude-side token cost ~90%.
Task | Claude only | Claude + kimi-code-mcp | Claude-side savings |
Analyze 200-file monorepo | ~250K tok | ~25K tok | ~90% |
Summarize 50-page RFC PDF | ~60K tok | ~6K tok | ~90% (sketch) |
Cross-reference 100 commits | ~80K tok | ~8K tok | ~90% (sketch) |
*Illustrative estimates — savings are on Claude tokens only and depend on the task; Kimi's subscription cost is separate. See Token Economics.
# 1. Install Kimi CLI and log in
curl -L code.kimi.com/install.sh | bash
kimi login
# 2. Install via npm
npm install -g kimi-mcp-serverAdd to .mcp.json (project-level or ~/.claude/mcp.json for global):
{
"mcpServers": {
"kimi-code": {
"command": "npx",
"args": ["-y", "kimi-mcp-server"]
}
}
}Run /mcp in Claude Code to verify — you should see kimi-code with 8 tools.
You don't need the CLI for the common case. kimi_query and kimi_verify call the Kimi Code API directly — no Python CLI install or kimi login required. Just provide an API key via $KIMICODE_API_KEY or ~/.kimi/config.toml (see Kimi Code API Setup). Only the codebase-reading tools (kimi_analyze, kimi_resume) need the CLI. See Two backends: API vs CLI for the full split.
Related MCP server: Ollama MCP Server
Claude calls the kimi_analyze tool when a task needs bulk codebase reading.
MCP routes the request to Kimi Code (kimi-for-coding, 256K context) — Kimi reads the entire codebase in one pass.
The result is piped back as a structured response — Claude acts on it with precise, targeted edits.
┌──────────────┐ stdio/MCP ┌──────────────┐ subprocess ┌──────────────┐
│ Claude Code │ ◄──────────► │ kimi-code-mcp│ ────────────► │ Kimi CLI │
│ (conductor) │ │ (MCP server) │ │ (256K ctx) │
└──────────────┘ └──────────────┘ └──────────────┘The server reaches Kimi two different ways, and each tool uses the one that fits its job. Knowing which is which tells you what you need to set up.
Backend | How it talks to Kimi | What it needs | Sees your codebase? |
Direct API | HTTPS to | An API key only ( | ❌ No — you paste in the context |
Local CLI | Spawns the | CLI installed and | ✅ Yes — reads files from disk |
Tool | Backend | Why |
| API (CLI only if no key configured) | Contextless Q&A — no codebase needed, so the API is simpler and has no login dependency |
| API | You pass the code/diff/claim inline; Kimi judges it as an independent third party |
| CLI | Must read your whole codebase (256K ctx) from disk |
| CLI | Continues a stateful CLI session that holds prior codebase context |
| local | Read local session/cache metadata |
Most users only need the API key. If you just want a second opinion / verification (kimi_query, kimi_verify), set the API key and you're done — skip the CLI entirely. Install + kimi login only when you want Kimi to read your codebase via kimi_analyze / kimi_resume.
Run kimi_status any time to see which backends are live — it reports the API-configured state and the CLI install/auth state separately.
If you are an AI agent (Claude Code, a subagent, etc.) deciding when to call these tools:
Cross-check your own work before committing → kimi_verify. Paste the actual diff/code/claim plus the surrounding context (goal, constraints, signatures). Kimi sees only the context string — no repo, no session history. Vague context → useless review.
Quick model-agnostic programming question → kimi_query. No codebase needed. Returns a different model's opinion.
Need to understand a large/unfamiliar codebase → kimi_analyze with work_dir. Prefer this over reading 50 files yourself; it's ~10× cheaper in Claude tokens. Requires the CLI to be installed and logged in.
Drill deeper after an analyze → kimi_resume with the returned session_id (retains up to 256K tokens of prior context).
Don't know why a Kimi call failed → kimi_status first. "Not authenticated" on the CLI does not affect kimi_query/kimi_verify (those use the API).
Keep outputs lean. Default detail_level: summary for orientation; raise to normal/detailed only when you need code snippets. Bigger output = more Claude tokens, defeating the purpose.
Skip Kimi for small/single-file work — Claude reading directly is faster under ~10 files.
MCP server that connects Kimi Code (model kimi-for-coding, 256K context, auto-upgraded) with Claude Code — letting Claude orchestrate while Kimi handles the heavy reading.
Stop paying Claude to read files. Kimi Code delivers frontier-class code intelligence at a fraction of the cost (see chart above). Delegate bulk codebase scanning to Kimi (256K context, near-zero cost) and let Claude focus on what it does best — reasoning, decisions, and precise code edits. One kimi_analyze call can replace 50+ file reads.
Kimi Code is an AI code agent by Moonshot AI. The model ID kimi-for-coding (1T MoE, 256K context) automatically receives backend upgrades — no version pinning required. It works across Terminal, IDE, and CLI — writing, debugging, refactoring, and analyzing code autonomously.
Key specs:
256K token context — reads entire codebases in one pass
Parallel agent spawning — handles concurrent tasks
Shell, file, and web access — full developer toolchain
Install: curl -L code.kimi.com/install.sh | bash
Kimi Code membership required. All tools ultimately hit Kimi Code, which needs an active Kimi Code plan. The API tools (kimi_query, kimi_verify) authenticate with an API key; the codebase tools (kimi_analyze, kimi_resume) additionally need the CLI installed + kimi login. See kimi.com/code for pricing tiers and quotas.
If you prefer to build locally instead of using the npm package:
git clone https://github.com/howardpen9/kimi-code-mcp.git
cd kimi-code-mcp && npm install && npm run build{
"mcpServers": {
"kimi-code": {
"command": "node",
"args": ["/absolute/path/to/kimi-code-mcp/dist/index.js"]
}
}
}Kimi Code API and Moonshot API are separate providers — their API keys are not interchangeable.
There are two ways to configure the Kimi Code API for the CLI:
In the Kimi Code CLI shell, run:
kimiThen use the /login (or /setup) command:
/loginSelect Kimi Code as the platform
Your browser opens for OAuth authorization
Config is saved automatically to ~/.kimi/config.toml
zsh: command not found: kimi after install? The installer puts the binary at ~/.local/bin/kimi, which may not be on your PATH. Add it (then restart your shell or open a new tab):
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrcThe MCP server calls the binary by absolute path, so this only affects running kimi yourself in a terminal (e.g. for kimi login).
Visit code.kimi.com
Sign in → Settings → API Keys
Create a new key (starts with sk-, shown only once)
nano ~/.kimi/config.tomlAdd:
[providers.kimi-code]
type = "kimi"
base_url = "https://api.kimi.com/coding/v1"
api_key = "sk-your-api-key"
[models.kimi-for-coding]
provider = "kimi-code"
model = "kimi-for-coding"
max_context_size = 262144
capabilities = ["thinking"]
[defaults]
model = "kimi-for-coding"# Add to ~/.zshrc (macOS) or ~/.bashrc (Linux)
export KIMICODE_API_KEY="sk-your-api-key"Then reference it in config.toml:
[providers.kimi-code]
type = "kimi"
base_url = "https://api.kimi.com/coding/v1"
api_key = "${KIMICODE_API_KEY}"You can configure both Kimi Code and Moonshot side by side:
[providers.kimi-code]
type = "kimi"
base_url = "https://api.kimi.com/coding/v1"
api_key = "${KIMICODE_API_KEY}"
[providers.moonshot-cn]
type = "kimi"
base_url = "https://api.moonshot.cn/v1"
api_key = "${MOONSHOT_API_KEY}"
[models.kimi-for-coding]
provider = "kimi-code"
model = "kimi-for-coding"
max_context_size = 262144
capabilities = ["thinking"]
[models.kimi-k2]
provider = "moonshot-cn"
model = "kimi-k2-0905-preview"
max_context_size = 256000
capabilities = ["thinking"]
[defaults]
model = "kimi-for-coding"Switch models at any time with /model or /model kimi-k2 in the CLI.
Feature | Kimi Code | Moonshot |
Focus | Optimized for coding | General-purpose chat |
Endpoint |
|
|
API Key | Separate — apply at code.kimi.com | Separate |
SearchWeb / FetchURL | Built-in | Not available |
Context | 262K | 256K |
Just tell Claude what you need. It will delegate to Kimi automatically:
Prompt | What happens |
"Analyze this codebase's architecture" | Kimi reads all files (256K ctx), Claude acts on the report |
"Scan for security vulnerabilities, then review Kimi's findings" | Kimi audits, Claude cross-examines — AI pair review |
"Map all dependencies of the auth module, then plan the refactoring" | Kimi builds the dependency graph, Claude plans the changes |
"Review the recent changes for regressions and edge cases" | Kimi reviews full context (not just the diff), Claude synthesizes |
"Resume the last Kimi session and ask about the API design" | Kimi retains 256K tokens of context across sessions |
Claude Code is powerful but expensive. Every file it reads costs tokens. Meanwhile, many tasks — pre-reviewing large codebases, scanning for patterns, generating audit reports — are high-certainty work that doesn't need Claude's full reasoning power.
The cost equation: Claude reads 50 files to understand your architecture = expensive. Kimi reads 50 files via kimi_analyze = near-zero cost. Claude then acts on Kimi's structured report = minimal tokens. Total savings: 60-80% fewer Claude tokens on analysis-heavy tasks.
┌─────────────────────────────┐
│ You (the developer) │
└──────────┬──────────────────┘
│ prompt
▼
┌─────────────────────────────┐
│ Claude Code (conductor) │
│ - orchestrates workflow │
│ - makes decisions │
│ - writes & edits code │
└──────┬──────────────┬───────┘
precise │ │ delegate
edits │ │ bulk reading
(tokens) │ │ (FREE)
▼ ▼
┌──────────┐ ┌──────────────┐
│ your │ │ Kimi Code │
│ codebase │ │ - 256K ctx │
└──────────┘ │ - reads all │
│ - reports │
└──────────────┘Claude receives your task → decides it needs codebase understanding
Claude calls kimi_analyze via MCP → Kimi reads the entire codebase (256K context, near-zero cost)
Kimi returns a structured analysis
Claude acts on the analysis with precise, targeted edits
Result: Claude only spends tokens on decision-making and code writing, not on reading files.
kimi-for-coding is a 1T MoE model designed for deep code comprehension. This enables AI pair review:
Kimi pre-reviews — 256K context means it sees the entire codebase at once: security issues, anti-patterns, dead code, architectural problems
Claude cross-examines — reviews Kimi's findings, challenges questionable items, adds its own insights
Two perspectives — different models catch different things. What one misses, the other finds
Beyond ad-hoc analysis, you can use Kimi as a dedicated reviewer in your workflow:
┌──────────────┐ diff ┌──────────────┐ structured ┌──────────────┐
│ Your PR │ ────────► │ Kimi Code │ findings │ Claude Code │
│ (changes) │ │ (reviewer) │ ────────────►│ (decision) │
└──────────────┘ └──────────────┘ └──────────────┘When | What | Why |
Before merging | Kimi scans diff + affected modules | Catch regressions early |
Weekly | Full codebase sweep | Accumulated tech debt |
Pre-release | Security-focused audit | Ship with confidence |
Each review session can be resumed (kimi_resume) — Kimi retains up to 256K tokens of context from previous sessions, building understanding over time.
Review Type | Why Kimi Excels |
Security audit | 256K context sees full attack surface, not just isolated files |
Dead code detection | Can trace imports/exports across entire codebase |
API consistency | Compares patterns across all endpoints simultaneously |
Dependency analysis | Maps full dependency graph in one pass |
Architecture review | Sees the forest and the trees at the same time |
Tool | Description | Timeout |
| CLI — deep codebase analysis (architecture, audit, refactoring) | 10 min |
| API — quick programming questions, no codebase context (CLI only if no key configured) | 2 min |
| API — independent third-party verification of code/diffs/claims; no CLI required, context-driven | 5 min |
| List existing Kimi sessions with metadata | instant |
| CLI — resume a previous session (up to 256K token context) | 10 min |
| Report API-configured state + CLI install/version/auth status | instant |
| View session cache statistics and performance metrics | instant |
| Manually invalidate cached sessions (by dir or all) | instant |
kimi_analyze and kimi_resume support these parameters to control output size:
Parameter | Values | Default | Effect |
|
|
| Controls prompt-side verbosity instructions |
| number |
| Hard ceiling — output truncated at clean boundary if exceeded |
| boolean |
| Include Kimi's internal reasoning chain (10-30K extra tokens) |
kimi_query also supports max_output_tokens and include_thinking.
The savings come fromcompression ratio, not from free reading. Kimi's subscription cost still applies, but the key benefit is reducing expensive Claude Code token consumption.
Without kimi-code-mcp With kimi-code-mcp (normal)
───────────────────── ───────────────────────────
Raw source: 50 files × ~4K = 200K Kimi reads (subscription cost)
Claude reads: 200K tokens 5-15K token report
Claude token cost: $$$ $Compression ratio by detail_level:
Level | Compression | Output Size | Equivalent Source | Best For |
| 40-100x | ~2-5K tokens | ~8-20K chars / ~200-500 lines of code | Quick orientation, file inventory |
| 15-40x | ~5-15K tokens | ~20-60K chars / ~500-1500 lines of code | Architecture review, dependency mapping |
| 5-15x | ~15-40K tokens | ~60-160K chars / ~1500-4000 lines of code | Security audit with code snippets |
When savings happen:
Large codebases (50+ files) — architecture understanding, cross-file scanning
Security audits, dead code detection, API consistency checks
Pre-review before targeted edits (scan first → edit specific files)
When to skip and let Claude read directly:
Small codebases (<10 files) — direct reading is faster
Single-file modifications — Claude's built-in file reading is sufficient
When you need every line of code — detailed output approaches raw reading cost
Under the hood:
Claude Code calls an MCP tool (e.g., kimi_analyze)
This server spawns the kimi CLI with the prompt and codebase path
Kimi autonomously reads files, analyzes the code (up to 256K tokens)
The result is parsed from Kimi's JSON output and returned to Claude Code
Claude acts on the structured results — edits, plans, or further analysis
The MCP server calls the Kimi CLI in non-interactive (print) mode:
kimi --work-dir <path> --print -p "<prompt>"Flag | Purpose |
| Non-interactive mode — outputs result and exits (required for subprocess use) |
| Pass prompt directly (bypasses interactive shell) |
| Set codebase root directory |
| Resume a specific session by ID |
| Disable thinking mode |
There is nokimi analyze subcommand. The MCP tool is named kimi_analyze, but the underlying CLI uses the flags above. Use this syntax to call Kimi directly for debugging or scripting.
For development (auto-recompile on changes):
{
"mcpServers": {
"kimi-code": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/kimi-code-mcp/src/index.ts"]
}
}
}Published as kimi-mcp-server on npm.
npx kimi-mcp-server # run directly
npm install -g kimi-mcp-server # install globallysrc/
├── index.ts # MCP server setup, tool definitions, API-vs-CLI routing
├── kimi-api.ts # Direct Kimi Code API client (kimi_query / kimi_verify)
├── kimi-runner.ts # Spawns kimi CLI, parses output, handles timeouts
├── cache-manager.ts # Session cache (warmup, reuse, invalidation)
└── session-reader.ts # Reads Kimi session metadata from ~/.kimi/See CONTRIBUTING.md for guidelines.
See CHANGELOG.md for version history.
MIT
Send a prompt to Kimi Code for codebase analysis. Kimi reads the codebase (256K context) and returns a compressed, structured report.
CACHE BEHAVIOR: If session_id is not provided, the MCP server will automatically use cached sessions when available.
First call: Creates cache (may take 60-120s for large codebases)
Subsequent calls: Reuses cached session (faster, ~10s)
Cache auto-expires after 30 minutes or when files change
Use kimi_cache_status to view cache statistics
Output is budget-controlled: Kimi reads 200K+ tokens of source but returns a 5-15K token analysis (configurable via detail_level). Use kimi_resume to drill deeper into specific areas. Takes 1-5 minutes for large codebases.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id/alias. Default: k3 (K3). Examples: k3, kimi-code/k3, kimi-for-coding. Env override: KIMICODE_MODEL or KIMI_MODEL. | |
| prompt | Yes | The analysis prompt for Kimi (be specific about what to analyze) | |
| thinking | No | Enable thinking mode for deeper analysis (default: true) | |
| work_dir | Yes | Absolute path to the codebase root directory | |
| use_cache | No | Enable automatic session caching (default: true). Set to false to bypass cache and create fresh session. | |
| session_id | No | Resume a specific Kimi session by ID (from kimi_list_sessions). If not provided, cached session will be used when available. | |
| detail_level | No | Output verbosity. summary: ~2-5K tokens (file index + key findings). normal (default): ~5-15K tokens (structured analysis). detailed: ~15-40K tokens (with code snippets). | |
| include_thinking | No | Include Kimi internal reasoning in output. Default: false (saves 10-30K tokens). Enable only for debugging. | |
| max_output_tokens | No | Max tokens in response (~4 chars/token). Default: 15000. Use 3000-5000 for quick scans, 30000+ for detailed analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Details caching, time expectations (60-120s first, ~10s subsequent), auto-expiry, budget-controlled output (5-15K tokens), and configurable detail_level. Thoroughly transparent.
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 clear sections (purpose, cache behavior, output). Front-loaded with main purpose. Somewhat lengthy but each part earns its place. Minor redundancy could be trimmed.
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?
Covers caching, timings, output budgets, relationships to sibling tools, and configuration options. No output schema needed; mentions structured report but not exact format. Fairly complete for a complex 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 coverage is 100%, baseline 3. Description adds significant value: explains caching mechanism in relation to session_id, detail_level token ranges, max_output_tokens usage, and distinction between thinking and include_thinking. Compensates well.
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?
Clearly states it sends a prompt to Kimi Code for codebase analysis, mentions reading codebase with 256K context and returning a compressed structured report. Differentiates from siblings by referencing kimi_resume and kimi_cache_status.
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 usage context: first call may be slow, subsequent calls faster via caching; suggests kimi_resume for deeper analysis. Lacks explicit when-not-to-use but covers key scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually invalidate session cache entries. Use when you want to force fresh analysis or if you suspect cached sessions are stale.
| Name | Required | Description | Default |
|---|---|---|---|
| work_dir | No | Specific working directory to invalidate. If not provided, ALL caches are cleared. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states the basic purpose and one use case, but does not disclose side effects, permissions, or what 'invalidate' actually means (e.g., deletion vs marking).
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?
Two sentences with no unnecessary words. The action and usage context are front-loaded, making it efficient for an AI agent to parse.
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?
The tool is simple (one optional parameter, no output schema), and the description covers the basic purpose and parameter behavior. However, it lacks information about the return value or what 'invalidate' entails operationally, which could be improved.
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 100%; the description adds value by explaining the default behavior when 'work_dir' is not provided (ALL caches cleared). This goes beyond the schema's own description.
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?
Clearly specifies the verb 'invalidate' and the resource 'session cache entries', and provides a reason for use. Distinguishes from sibling tools like kimi_list_sessions and kimi_analyze because it focuses on cache invalidation.
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: 'force fresh analysis' or 'suspect stale sessions'. Does not mention when not to use or explicitly reference sibling alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View session cache statistics and status. Shows cache hits/misses, active sessions, and performance metrics. Use this to monitor cache effectiveness and troubleshoot issues.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Show detailed cache entry information (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It implies a read-only operation ('View'), but does not disclose potential side effects, permission requirements, or rate limits. Minimal behavioral insight beyond the basic purpose.
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?
Two concise sentences: first states purpose, second adds usage guidance and output summary. No wasted words, though slightly more detail on output could be added without harming conciseness.
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 a single parameter, no output schema, and no annotations, the description adequately covers purpose and usage. However, it lacks details on return format, pagination, or performance overhead, leaving some gaps for an AI agent.
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 coverage is 100% with one boolean parameter 'detail' already described in the schema. The description adds no extra meaning beyond the schema, so baseline score applies.
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?
Description explicitly states 'View session cache statistics and status,' specifying the verb and resource. It distinguishes itself from sibling tools like kimi_cache_invalidate (mutation) implicitly, but does not strongly differentiate from kimi_status, which might also show status.
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 advises using the tool 'to monitor cache effectiveness and troubleshoot issues,' providing context. However, it does not explicitly state when not to use it or mention alternatives, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing Kimi Code sessions with titles, working directories, and timestamps. Use to find session IDs for kimi_resume.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max sessions to return (default: 20) | |
| work_dir | No | Filter sessions by working directory path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly implies a read-only operation and mentions a default limit (implied by the 'max sessions' parameter description). However, it does not disclose pagination behavior, cost, or whether results are sorted or cached.
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?
Two short sentences: first explains what the tool does and what it returns, second explains its primary use case. No filler words.
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 list tool with no output schema, the description covers the essential output fields and ties to a sibling. Missing details like sorting or page size limits, but given the simplicity, it is largely complete for an agent to invoke correctly.
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 coverage is 100%; both parameters ('limit' and 'work_dir') have descriptions. The tool description adds no new parameter meaning beyond listing output fields, so it meets the baseline but does not exceed it.
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 verb ('List'), the resource ('Kimi Code sessions'), and the output fields ('titles, working directories, and timestamps'). It also immediately connects to a sibling tool use-case ('find session IDs for kimi_resume'), differentiating it from other analysis tools.
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 tells when to use this tool ('find session IDs for kimi_resume'), which implies the context. It does not enumerate alternatives or exclusion cases, but siblings are distinct (analyze, query, verify, etc.), making the guidance clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask Kimi Code a question without codebase context. Default model: k3 (K3). Use for general programming questions, algorithm explanations, or getting a second opinion.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id/alias. Default: k3 (K3). Examples: k3, kimi-code/k3, kimi-for-coding. Env override: KIMICODE_MODEL or KIMI_MODEL. | |
| prompt | Yes | The question to ask Kimi | |
| thinking | No | Enable thinking mode (default: false for speed; CLI path only) | |
| include_thinking | No | Include Kimi internal reasoning. Default: false. | |
| max_output_tokens | No | Max tokens in response (~4 chars/token). Default: 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the default model and the lack of codebase context, but does not discuss idempotency, authentication, rate limits, or error handling. For a read-only query tool, this is minimally adequate but leaves gaps.
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 two sentences long, front-loading the core purpose and then providing usage guidance. Every sentence is meaningful and there is no redundancy or unnecessary detail.
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 5 parameters are well-documented in the schema and the tool is a straightforward query, the description is largely complete. It could be enhanced by mentioning the response format, but this is not critical for a simple question-answering 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 description coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond what the schema already provides (e.g., default model, examples). Therefore, no extra value is contributed.
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 verb ('Ask'), the resource ('Kimi Code'), and the key differentiator ('without codebase context'). It also lists specific use cases (general programming questions, algorithm explanations, second opinions), which distinguishes it from sibling tools that may involve codebase context.
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 tells when to use the tool: 'Use for general programming questions, algorithm explanations, or getting a second opinion.' It also implies when not to use it by specifying 'without codebase context,' indicating that for codebase-specific queries, other tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume an existing Kimi Code session with a new prompt. The session retains all previous context (up to 256K tokens). Use kimi_list_sessions to find session IDs first. Ideal for drilling deeper after an initial kimi_analyze scan.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id/alias. Default: k3 (K3). Examples: k3, kimi-code/k3, kimi-for-coding. Env override: KIMICODE_MODEL or KIMI_MODEL. | |
| prompt | Yes | New prompt to send in the resumed session | |
| thinking | No | Enable thinking mode (default: true) | |
| work_dir | Yes | Working directory (must match the original session) | |
| session_id | Yes | Session ID to resume (UUID format) | |
| detail_level | No | Output verbosity. summary: ~2-5K tokens. normal (default): ~5-15K tokens. detailed: ~15-40K tokens. | |
| include_thinking | No | Include Kimi internal reasoning. Default: false. | |
| max_output_tokens | No | Max tokens in response (~4 chars/token). Default: 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses session context retention up to 256K tokens, but omits details about authorization, rate limits, error handling, or side effects. The behavioral information is adequate but incomplete.
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 three sentences, front-loaded with the primary action and resource. Every sentence adds essential context: action+retention, prerequisite, and use case. No fluff or 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 (8 params, no output schema), the description covers purpose, context retention, and a use case. However, it lacks details on return values, error scenarios, or behavior for missing/invalid sessions. Moderately complete but with 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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it reinforces the role of session_id and prompt, but does not elaborate on parameter syntax or constraints. Meets minimum expectation.
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 verb 'Resume' with the resource 'existing Kimi Code session' and specifies the action 'with a new prompt'. It distinguishes from siblings by mentioning prerequisite use of 'kimi_list_sessions' and positioning as follow-up after 'kimi_analyze'.
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 provides explicit prerequisite ('Use kimi_list_sessions to find session IDs first') and a use case ('Ideal for drilling deeper after an initial kimi_analyze scan'). It implies when to use this tool over kimi_analyze, but lacks explicit when-not scenarios or alternative tools like kimi_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Kimi CLI/API status, default model (K3 detection), and auth. Set probe_api=true for a live Coding API model echo check.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to probe when probe_api=true (default: k3). | |
| probe_api | No | If true, send a tiny live API completion and report observed model id (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions status checks and live probes but omits safety (e.g., non-destructive read), error behaviors, or rate limits. The probe implies a network request, but consequences (cost, side effects) are undisclosed.
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 two sentences, front-loading the core purpose, then adding the optional probe. Every word is necessary and no fluff.
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?
Despite no output schema, the description fails to explain return structure (e.g., status fields, auth state, model). For a complex status tool with 8 siblings, it should suggest when to use this vs. kimi_cache_status or set expectations for output.
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 coverage is 100%, so baseline is 3. The description adds minimal value beyond repeating the schema's 'probe' behavior and default model; no new semantics for parameters like format constraints or edge cases.
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 checks Kimi CLI/API status, default model detection, and auth. It distinguishes from sibling tools like kimi_query or kimi_cache_status by focusing on overall health.
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 gives guidance on using probe_api for a live check but does not explicitly state when to use this tool over alternatives or any exclusions. The context of sibling tools helps but the description itself is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an INDEPENDENT second opinion from Kimi Code (default k3 / K3, 256K context) acting as an external third-party verifier. Calls the Kimi Code API directly — no CLI install required, just an API key (env KIMICODE_API_KEY or ~/.kimi/config.toml).
USE THIS to cross-check your own work: confirm a fix is correct, hunt for bugs / edge cases / security issues in a diff, sanity-check a claim or plan, or get a dissenting view before you commit. Different model, independent judgment.
CRITICAL — pass full context: Kimi sees ONLY the 'context' string. It has NO access to this session, the repository, prior messages, or any tools. Paste the ACTUAL code/diff/claim AND the surrounding context it needs (the goal, constraints, assumptions, relevant signatures). Vague or partial context produces vague, useless verification.
Detection: every response ends with a [kimi-model …] footer (requested/observed/k3=yes|no).
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Override the reviewer persona (system instruction). Default: a meticulous, independent senior engineer with no stake in the code. | |
| model | No | Model id/alias. Default: k3 (K3). Examples: k3, kimi-code/k3, kimi-for-coding. Env override: KIMICODE_MODEL or KIMI_MODEL. | |
| context | Yes | Self-contained material for Kimi to examine: the actual code / diff / claim / plan PLUS the context needed to judge it (intent, constraints, assumptions, relevant signatures). Kimi sees nothing but this. | |
| question | No | What to verify or focus on, e.g. "is this SQL-injection safe?" or "does this handle empty input and concurrency?". Default: a general independent correctness review. | |
| include_thinking | No | Include Kimi internal reasoning in the output. Default: false. | |
| max_output_tokens | No | Max answer tokens (~4 chars/token). Default: 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it calls the Kimi Code API directly, requires an API key, and critically states 'Kimi sees ONLY the 'context' string. It has NO access to this session, the repository, prior messages, or any tools.' This properly sets expectations for the stateless, isolated verification.
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: starts with core purpose, then usage guidelines, then critical behavioral warnings. Every sentence adds value without redundancy. It is appropriately sized for the complexity and difficulty.
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 no output schema, the description mentions the response footer detection but doesn't detail the return structure. However, it covers input requirements, behavioral constraints, and detection markers. For a text-returning tool with 6 parameters (100% schema coverage), it is largely complete, though a brief note on expected response format would strengthen it.
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 coverage is 100% (6 params described in input schema). The description adds value beyond schema by explaining the purpose of each parameter (e.g., 'context' must be self-contained, 'question' defaults to general correctness review, 'role' and 'model' are overrides). It provides practical guidance, but the schema already covers the basics.
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: 'Get an INDEPENDENT second opinion from Kimi Code ... acting as an external third-party verifier.' It uses specific verbs and resources, and distinguishes it from sibling tools (like kimi_analyze, kimi_query) by emphasizing its verification role.
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 when-to-use scenarios: 'cross-check your own work', 'confirm a fix', 'find bugs / edge cases / security issues', 'sanity-check a claim or plan', 'get a dissenting view before you commit'. It also emphasizes the importance of passing full context. While it doesn't explicitly state when not to use or name alternatives among siblings, the usage context is clear.
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. Dates show when Glama detected each change.
v0.5.0kimi_analyzekimi_cache_invalidatekimi_cache_statuskimi_list_sessionskimi_querykimi_resumekimi_statuskimi_verifyEach tool has a distinct purpose: listing sessions, analyzing codebase, querying without context, independent verification, cache management, resuming sessions, and status checking. No overlap or ambiguity.
All tools follow a consistent 'kimi_verb' pattern using snake_case (e.g., kimi_analyze, kimi_cache_status). The naming is predictable and uniform.
With 8 tools covering session management, analysis, verification, and cache control, the count is well-scoped for a code analysis assistant—neither too sparse nor overwhelming.
The surface covers core workflows (analysis, resume, verification, cache, status). A minor gap is the lack of an explicit session deletion tool, but the provided tools enable effective operation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
One identity across Claude Code, Codex, Cursor, Gemini, Windsurf: shared inbox and handoffs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/howardpen9/kimi-code-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
