Skip to main content
Glama
Arhimage

ladder-mcp

by Arhimage
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Ladder_mcp

npm license platform

Windows-first MCP bridge for the Kimi CLI (v24). It exposes Kimi Code as MCP tools so a client like Claude Code can run codebase analysis, native sessions, API queries, ACP chat, background tasks, and CLI admin/diagnostics — all on Windows without hardcoded POSIX assumptions.

Published on npm (version badge above). Supported platform is Windows 11 only.

Highlights

  • Agentic codegen & analysis — point Kimi at a repo to read or edit files.

  • ACP-only transport — kimi_code drives Kimi over the ACP JSON-RPC protocol (one kimi acp process per call; continuity via session_id), with granular watchable live progress and interactive permission prompts.

  • Background tasks — run several Kimi tasks in parallel and wait for each with a single blocking kimi_tasks action=wait call (no polling loop), with a live TODO checklist surfaced as Kimi works.

  • Multi-agent support — agent_ask, agent_code, agent_cycle, agent_sessions, agent_status, and agent_tasks add a provider-neutral layer over Kimi and the local MiniMax mmx CLI. Kimi stays the default and all kimi_* tools are unchanged.

  • Dev cycle — agent_cycle runs an automated coder→reviewer loop (two independent agent sessions) until the reviewer approves or the caller's max_iterations budget is spent. This is the recommended way to write code with provider=minimax.

  • Independent review — kimi_ask runs stateless questions or a skeptical second-opinion review of supplied material (no repo access, no edits).

  • Session-aware — list, inspect, and resume Kimi sessions across the CLI catalog and ACP.

  • Diagnostics & setup — one call to check install/auth/health, one to emit the MCP config for a Kimi-hosted server.

  • Windows-native — resolves kimi.exe, ~/.kimi-code, and PATH correctly; no POSIX assumptions.

Related MCP server: kimi-code-mcp

Requirements

  • Windows 11

  • Node.js ≥ 18

  • Kimi Code CLI installed (kimi.exe on PATH or at ~/.kimi-code/bin/kimi.exe), authenticated (~/.kimi-code/)

  • (Optional) MiniMax CLI (mmx on PATH) for agent_ask and agent_code with provider=minimax

Quick start (from npm)

You don't need to clone or build — the package is published on npm and your MCP client launches it via npx, or you can install the package directly.

Claude Code (one command):

claude mcp add ladder-mcp -- npx -y ladder-mcp

Or add it manually to your MCP config:

{
  "mcpServers": {
    "ladder-mcp": {
      "command": "npx",
      "args": ["-y", "ladder-mcp"]
    }
  }
}

Then in Claude Code run /mcp (should show ladder-mcp: connected) and call kimi_status to confirm the environment is detected.

The server speaks MCP over stdio: it is launched and managed by the client, not run by hand. Running npx ladder-mcp directly will appear to "hang" — that is the server correctly waiting for a client. Exit with Ctrl+C.

Prefer a global install? npm install -g ladder-mcp, then use ladder-mcp as the command instead of npx -y ladder-mcp.

Or install locally into your project:

npm install ladder-mcp

Then point your MCP config at ./node_modules/.bin/ladder-mcp (or use npx -y ladder-mcp, which resolves the locally installed copy when available).

To let Kimi Code itself host this server, use the kimi_setup tool to produce/merge a .kimi-code/mcp.json entry.

Tools

Core (always on)

Tool

Purpose

Key parameters

kimi_code

Agentic work in a repository — analyze and (optionally) edit files.

prompt, work_dir, edit (default false = analysis-only), background, session_id (continue a session), timeout_ms (floor 30 min)

kimi_ask

Stateless question, or independent review when context is supplied. Text only — no repo, no edits.

prompt*, context (switches to verify mode), role (reviewer persona), timeout_ms

kimi_sessions

List/inspect Kimi sessions from the CLI catalog, ACP, or both.

source (cli|acp|all, default all), work_dir, limit (default 20)

kimi_tasks

Manage background work.

action (wait|status|output|cancel)*, task_id, session_id (cancel an ACP session), mode (final|full), offset, limit, timeout_ms (wait)

kimi_status

Installation, auth, and diagnostics.

detail (basic|full), doctor_target (config|tui), doctor_path

kimi_setup

Generate/merge the Kimi-hosted MCP config entry for this server.

scope (project|user), write (default false = preview only), project_dir, server_name

agent_ask

Provider-neutral stateless question/review.

prompt*, provider (kimi|minimax, default kimi), context, role, timeout_ms

agent_code

Provider-neutral agentic code work — analyze and (optionally) edit files. For MiniMax codegen prefer agent_cycle.

prompt, work_dir, provider (kimi|minimax, default kimi), edit, background, session_id, timeout_ms

agent_cycle

Iterative dev cycle: coder agent implements, independent reviewer agent reviews the diff, loop repeats until VERDICT: APPROVED or the iteration budget runs out. Recommended for codegen with provider=minimax.

prompt, work_dir, max_iterations* (1–10), provider (both roles, default kimi), coder_provider, reviewer_provider, edit (default true), background, timeout_ms (per agent run)

agent_sessions

List sessions across providers: Kimi (CLI catalog + ACP) and MiniMax (Ladder session store).

provider (kimi|minimax|all, default all), work_dir, limit

agent_status

Installation/auth diagnostics for Kimi and MiniMax together.

detail (basic|full)

agent_tasks

Provider-neutral background-task management (same store as kimi_tasks).

action (wait|status|output|cancel)*, task_id, session_id, mode, offset, limit, timeout_ms

* = required.

kimi_code drives Kimi exclusively through the ACP JSON-RPC transport. Prefer the default foreground call: it blocks until Kimi finishes, streams live progress to clients that render it (Claude Code does), and costs the host model nothing while it waits. Set background: true only when you need several Kimi tasks running in parallel.

Experimental (off by default)

Enable with the environment variable LADDER_EXPERIMENTAL=1:

Tool

Purpose

kimi_export_session

Export a Kimi session ZIP (requires explicit output_path; excludes the global diagnostic log by default).

kimi_visualize_session

Preview or launch the Kimi session visualizer on localhost (kimi vis --no-open).

kimi_desktop_status

Read-only Kimi Desktop Work status probe.

kimi_budget_probe

Guided budget-separation evidence workflow (does not submit Work tasks).

Background tasks

Foreground (the default) is the right choice for a single task: the call blocks, live progress is visible, and no tokens are spent while waiting. Use background: true to run several Kimi tasks in parallel — each call returns immediately with a task id. Then wait with one blocking call instead of a polling loop (every status poll is a full model turn and costs tokens):

// 1. start two tasks in parallel
kimi_code { "prompt": "...", "work_dir": "C:\\repo1", "edit": true, "background": true }
kimi_code { "prompt": "...", "work_dir": "C:\\repo2", "edit": true, "background": true }
// 2. wait — blocks until the task finishes (or timeout_ms, default 20 min);
//    returns the status snapshot plus the last log lines
kimi_tasks { "action": "wait", "task_id": "task_1" }
// 3. read a paginated slice of the full transcript (TODO checklist + every action)
kimi_tasks { "action": "output", "task_id": "task_1", "mode": "full", "offset": 0, "limit": 100 }
// 4. quick non-blocking check — list all, or pass task_id; metadata only
kimi_tasks { "action": "status" }
// 5. stop early (kills the Kimi child process)
kimi_tasks { "action": "cancel", "task_id": "task_1" }

The task log keeps the full transcript — every progress event and each TODO snapshot as Kimi maintains its plan. The status action returns only metadata; the body is opt-in via output. On server shutdown all running background tasks are cancelled so no kimi acp child processes are orphaned.

Dev cycle (coder ↔ reviewer)

agent_cycle automates the "one agent codes, another reviews" loop inside a single tool call:

  1. The coder session implements the task (edit: true).

  2. The reviewer — a separate, always read-only session — inspects git diff plus the coder's report and must end with VERDICT: APPROVED or VERDICT: REVISE + a numbered fix list.

  3. On REVISE the feedback goes back into the same coder session; the loop repeats until approval or max_iterations (set by the caller, 1–10).

Both roles default to one provider (different sessions/dialogues); override either role with coder_provider / reviewer_provider for cross-provider review. For MiniMax codegen this cycle is the recommended mode — it compensates for the single-shot quality gap without burning a second provider's quota by default.

agent_cycle {
  "prompt": "Add input validation to the /users endpoint",
  "work_dir": "C:\\repo",
  "provider": "minimax",
  "max_iterations": 3
}
// or in the background:
agent_cycle { ...same..., "background": true }
agent_tasks { "action": "wait", "task_id": "task_1" }

The result includes per-iteration verdicts, the final review, and both session ids (agent_code + session_id continues the coder session manually).

Configuration

Environment variables

Variable

Effect

LADDER_EXPERIMENTAL=1

Register the 4 experimental tools.

KIMI_API_KEY

API key used by kimi_ask (alternatively set api_key in ~/.kimi-code/config.toml). KIMICODE_API_KEY is also accepted as a legacy name.

Timeouts

Every tool that drives Kimi accepts a timeout_ms override. Defaults: ACP kimi_code 30 min (1 800 000 ms) floor — smaller values are raised to the floor; kimi_ask 2 min (5 min in verify mode); API 5 min; CLI admin calls 30 s.

Safety boundaries

  • edit defaults to false (analysis-only intent). Read-only is enforced at the ACP proxy since 1.2.0: fs/write_text_file requests are rejected with a JSON-RPC error before touching disk, and mutating permission requests are denied (reads stay allowed), in addition to the read-only prompt guard. This is best-effort hardening within the protocol — an airtight guarantee would require OS-level sandboxing of the Kimi process.

  • kimi_export_session requires an explicit output_path, stays within the working directory, and excludes the global diagnostic log by default.

  • Desktop Work tools are experimental and read-only: they do not read the desktop token store, replay web auth, or submit desktop Work tasks.

  • The vendored kimi-code-mcp/ is a read-only reference and is never edited or written to by the tools.

Build from source (contributors)

npm install
npm run build      # compiles src/ -> dist/ (tests excluded)

Quick checks:

npm test           # vitest
npm run typecheck  # tsc --noEmit (incl. tests)
npm run dev        # run the server from source via tsx

Troubleshooting

  • ladder-mcp not connected / tools missing — run kimi_status. It reports whether the binary, catalog, credentials, and config are found and whether the API is configured.

  • npx ladder-mcp seems to hang — expected; it is the stdio server waiting for a client. It is meant to be launched by your MCP client, not by hand.

  • kimi_ask errors about a missing key — set KIMI_API_KEY (legacy KIMICODE_API_KEY is also accepted) or add api_key to ~/.kimi-code/config.toml. kimi_code does not need this key.

  • kimi_code timed out — the Kimi process is stopped on timeout, but Kimi persists session state on disk and the response includes a session_id. Call kimi_code again with that session_id to continue the same Kimi session. Resume is best-effort and not guaranteed; do not start a new task or perform the work yourself.

Project layout

  • src/ — the Ladder_mcp application (package ladder-mcp)

  • kimi-code-mcp/ — upstream reference (read-only, MIT)

License

MIT. Ports logic from the MIT-licensed kimi-code-mcp reference.

Available Tools

6 tools
kimi_askC

Stateless question or independent review. Text only, no repo, no edits.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleNoReviewer persona override for verify mode.
promptYesThe question to ask or the focus for verification.
contextNoMaterial to examine (switches to verify mode).
timeout_msNo
include_thinkingNo
max_output_tokensNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description must fully disclose behavior. It states stateless and text-only, but does not clarify authentication requirements, rate limits, side effects, or how the tool behaves when parameters like context are used (e.g., switching to verify mode). The description is insufficient for understanding the tool's full behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) and front-loads key traits, but it omits necessary detail. While there is no redundancy, the brevity comes at the cost of completeness, making it minimally adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the purpose of several parameters (e.g., timeout_ms, include_thinking, max_output_tokens) or what the tool returns. This leaves the agent with insufficient context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50%, and the tool's description adds no information about any parameters. Three parameters (timeout_ms, include_thinking, max_output_tokens) lack schema descriptions and are not addressed in the description. The description does not compensate for the low coverage.

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?

Description clearly states it is for 'stateless question or independent review' and emphasizes 'text only, no repo, no edits', which strongly distinguishes it from sibling tools like kimi_code (code-related) and kimi_sessions (session management). The purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives is provided. While it implies it is for stateless text queries, there is no mention of scenarios where other tools like kimi_code or kimi_tasks would be more appropriate.

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

kimi_codeA

Agentic work in a repository: analyze and edit files. Defaults to in-process CLI transport.

ParametersJSON Schema
NameRequiredDescriptionDefault
editNoAllow file modifications. Default: false (analysis-only intent). On Kimi 0.20.1 this is prompt-enforced (advisory): when false/omitted the prompt is prefixed with a read-only guard, but the CLI itself provides no hard read-only flag for -p mode.
promptYesThe analysis or coding prompt for Kimi.
work_dirYesAbsolute path to the codebase root directory.
transportNoHow the server drives Kimi. Both edit files and resume sessions; they differ in robustness and live-progress detail. 'cli' (default): one-shot process, most robust on Windows, but live progress is coarse — only streaming-output volume, no per-action lines. 'acp': persistent JSON-RPC session that emits granular live progress (tool calls, plan steps) and supports interactive permission prompts, but is heavier and more fragile. Prefer 'cli' for plain codegen/analysis; choose 'acp' when you need to watch each action live or handle mid-run prompts.
backgroundNoTrack as a long-running background task. Every progress event (including each action) is appended to the task log, readable via kimi_tasks — the full accumulating transcript, unlike the single overwriting live-progress line of a foreground call.
session_idNoExplicit Kimi session id to resume.
timeout_msNo
new_sessionNoStart fresh instead of continuing the last session. Default: false.
detail_levelNo
session_modeNoACP session mode when transport='acp'. Default: inferred from session_id/new_session.
include_thinkingNo
max_output_tokensNo

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, so the description must cover behavior. It mentions the default read-only guard for edit=false and transport differences, but does not disclose potential risks of editing files, required permissions, or error conditions. Moderate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, front-loading the core purpose. The extensive parameter descriptions are placed in the schema, keeping the main description clean. Minor reduction for not exemplifying structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters and no output schema, the description omits crucial details like return values, error handling, and session lifecycle. The parameter descriptions are helpful but do not compensate for the lack of overall context.

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 67%, and the description adds meaningful context beyond the schema, such as the read-only guard behavior for 'edit' and the detailed transport comparison. Some parameters like 'detail_level' lack descriptions, but overall the description enhances understanding.

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 description clearly states the tool's purpose: 'Agentic work in a repository: analyze and edit files.' This is a specific verb+resource pair and distinguishes it from siblings like kimi_ask (likely Q&A) and kimi_setup (setup).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description briefly mentions defaults but lacks explicit guidance on when to use versus alternatives. However, the transport parameter description provides some context on preferring cli vs acp, but the main description does not offer clear when-to-use or when-not-to-use instructions.

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

kimi_sessionsB

List/inspect Kimi sessions from the CLI catalog, ACP, or both.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax sessions to return. Default: 20.
sourceNoSource: 'cli', 'acp', or 'all'. Default: 'all'.
work_dirNoFilter sessions by working directory path.

TDQS

B3.4/5.0
Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits. It only states 'list/inspect' without clarifying if it modifies data, required permissions, rate limits, or what 'inspect' entails. The read-only nature is assumed but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the core purpose. It is concise but could be slightly more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with 3 optional parameters and no output schema, the description covers the basic purpose and source options. However, it lacks details on output format, default behavior, or error handling, which a moderately complete description would include.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already described. The description adds no new meaning beyond the schema summary (e.g., does not explain how 'limit' interacts with pagination or how 'work_dir' filtering works). Baseline 3 is appropriate.

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 description explicitly states the verb 'List/inspect' and the resource 'Kimi sessions', and distinguishes among sources ('CLI catalog, ACP, or both'), making the purpose clear and distinct from siblings like 'kimi_ask' or 'kimi_code'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing sessions from specific sources but provides no guidance on when to use this tool versus siblings (e.g., 'kimi_ask') or when to avoid it. No exclusions or alternatives are mentioned.

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

kimi_setupC

Generate the Kimi-hosted MCP config entry for Ladder_mcp.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNo
scopeNo
writeNoWhen false/omitted, only preview the merged config.
commandNo
project_dirNo
server_nameNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Generate... config entry,' which implies a write operation, but does not mention side effects, permissions, or the dual preview/write mode hinted by the 'write' parameter. The 'write' parameter schema description adds some context, but the description itself is silent on behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very brief (one sentence), but it is under-specified rather than concise. Important details about the tool's function and parameters are omitted, so the brevity does not serve the agent effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given six parameters (none required), no output schema, and no annotations, the description is critically incomplete. It does not explain what a 'Kimi-hosted MCP config entry' is, how the parameters affect the output, or what the tool returns. The agent lacks adequate information to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is only 17% (one parameter documented), and the tool description adds no additional meaning or context for the six parameters. The description does not explain any of the parameters, leaving the agent to infer from parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Generate the Kimi-hosted MCP config entry for Ladder_mcp,' which provides a specific verb and resource, distinguishing it from sibling tools like kimi_ask or kimi_code that focus on queries or code. However, the term 'Ladder_mcp' is ambiguous and the phrase 'MCP config entry' is not elaborated, slightly reducing clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives, nor are there any prerequisites or usage contexts mentioned. The description lacks any 'when to use' or 'when not to use' information.

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

kimi_statusC

Installation, auth, and diagnostics.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailNoDetail level: 'basic' or 'full'. Default: 'basic'.
doctor_pathNoOptional config/tui path for the doctor subcall when detail='full'.
doctor_targetNoTarget for the doctor subcall when detail='full'. Default: 'config'.

TDQS

C2.5/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. 'Installation, auth, and diagnostics' does not disclose whether tool is read-only, destructive, or what side effects occur. Behavioral traits are not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise (3 words) but lacks detail. While brevity is positive, it compromises informational value. Front-loads key terms but not fully earned.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no annotations, no output schema, the description is incomplete. Does not explain return values, the nature of diagnostics, or how auth/installation are checked. Insufficient for complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage with descriptions for all 3 parameters. The description adds minimal extra meaning beyond the schema (e.g., mentions 'diagnostics' relating to doctor subcall). Baseline score applicable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Installation, auth, and diagnostics' – a general purpose but not specific verb+resource. The name 'kimi_status' implies status checking, but description is broader. Does not clearly distinguish from siblings like kimi_setup (installation) or kimi_tasks (diagnostics?). Adequate but not precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. No context on prerequisites or scenarios. Agent has to infer usage from sibling tool names.

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

kimi_tasksC

Manage background work: status, output, or cancel.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction: 'status', 'output', or 'cancel'.
task_idNoOmit for status to list all tasks. Required for output.
session_idNoCancel an ACP session instead of a task (action=cancel).

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only mentions actions without disclosing side effects (e.g., cancellation being irreversible), permission requirements, or whether operations are read-only. The description is too minimal.

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?

Extremely concise: single sentence front-loads the core idea. No unnecessary words. Perfectly structured for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description lacks context about what tasks are (e.g., from kimi_ask) and return format. Without output schema, it should at least hint at response structure. Incomplete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds no additional semantic information beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear purpose: managing background work with specific actions (status, output, cancel). It differentiates from siblings like kimi_status (which likely handles a different type of status) but does not specify what kind of tasks, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like kimi_status or kimi_sessions. The description only lists actions without context for appropriate usage scenarios.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: ask handles questions, code does repository edits, sessions lists/inspects, setup generates config, status provides diagnostics, tasks manages background work – no overlap.

Naming Consistency5/5

All tools follow a consistent 'kimi_<noun/verb>' pattern with lowercase and underscores. The naming is uniform and predictable.

Tool Count5/5

Six tools is well-scoped for a management MCP server covering core functionality without being excessive or sparse.

Completeness4/5

The set covers primary use cases (ask, code, sessions, setup, status, tasks). Minor gaps like a dedicated help or search tool exist but do not hinder core workflows.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Arhimage/ladder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server