Skip to main content
Glama
ryanameier

kimi-swarm-bridge

by ryanameier
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Continue Kimi Session

kimi_continue_task
Destructive

Resume a Kimi session with follow-up instructions while preserving its context, enabling corrections, further work, or recovery after interruptions without creating duplicate sessions.

Instructions

Submit follow-up instructions to an existing Kimi session while preserving its prior context. Use for corrections, additional work, or recovery after a failed/aborted task instead of creating an unnecessary duplicate session. The continuation may run commands and modify files, and optional model, thinking, and swarm settings are applied before prompt submission.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planNoOptional ordered steps for the follow-up work.
taskYesFollow-up instruction, correction, or additional work to perform in the existing session.
modelNoConfigured Kimi model alias. In the managed ai& deployment omit this field to keep the centrally configured model binding.
thinkingNoOptional Kimi thinking setting. Omit to keep the bridge default.
sessionIdYesExisting Kimi session ID whose context should be preserved for the follow-up task.
swarmModeNoOptional swarm-mode setting to verify before the continuation prompt. Set true only when the follow-up should allow native AgentSwarm.
acceptanceCriteriaNoOptional verifiable conditions for the follow-up work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.2
    • addedInput schema / properties / acceptanceCriteria / description
      Added value: +"Optional verifiable conditions for the follow-up work."
    • addedInput schema / properties / model / description
      Added value: +"Configured Kimi model alias. In the managed ai& deployment omit this field to keep the centrally configured model binding."
    • addedInput schema / properties / plan / description
      Added value: +"Optional ordered steps for the follow-up work."
    • addedInput schema / properties / sessionId / description
      Added value: +"Existing Kimi session ID whose context should be preserved for the follow-up task."
    • addedInput schema / properties / swarmMode / description
      Added value: +"Optional swarm-mode setting to verify before the continuation prompt. Set true only when the follow-up should allow native AgentSwarm."
    • addedInput schema / properties / task / description
      Added value: +"Follow-up instruction, correction, or additional work to perform in the existing session."
    • addedInput schema / properties / thinking / description
      Added value: +"Optional Kimi thinking setting. Omit to keep the bridge default."
  2. First observedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already mark the tool as destructive, and the description goes beyond this by disclosing the concrete effects: 'may run commands and modify files.' It also clarifies that model, thinking, and swarm settings are applied before prompt submission, adding timing context not present in the schema.

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?

The description is two dense sentences with no filler, front-loading the purpose and use cases before the behavioral note. Every sentence adds value, and the optional-settings detail is packed efficiently at the end.

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?

The essential calling conditions are covered: required parameters, use cases, destructive behavior, and settings timing. It stops short of stating whether the call blocks until completion or what it returns, but the sibling wait tools and full schema make this gap minor.

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 the schema already documents every parameter, including sessionId and task. The description adds little per-parameter semantics beyond confirming the optional model/thinking/swarm settings and their timing, which keeps it at the baseline.

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 opens with a specific verb and object ('Submit follow-up instructions to an existing Kimi session') and adds the key distinguishing feature of preserving prior context. It further differentiates from new-session work by saying to use it 'instead of creating an unnecessary duplicate session,' which separates it from sibling delegation tools.

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?

The description explicitly gives concrete use cases: corrections, additional work, and recovery after a failed/aborted task. It also warns against duplicate sessions, but it does not name sibling tools or state when to choose kimi_delegate_task over this tool, so the routing guidance is clear but not exhaustive.

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