Skip to main content
Glama
ryanameier

kimi-swarm-bridge

by ryanameier
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Kimi Swarm Models

kimi_model_settings
Idempotent

View or update the AI model used by Kimi's coordinator and AgentSwarm workers. List models with prices, switch coordinator or worker models, or reset to defaults.

Instructions

Show or change which ai& models Kimi uses. The coordinator plans the task, delegates to AgentSwarm workers and writes the result; the workers do the parallel work, and most of a swarm's tokens are theirs, so a cheaper worker model cuts cost the most. Call with no arguments to list the available models with prices (USD per million tokens) and the current choice. Call with coordinatorModel and/or workerModel (model ids from the list) when the user asks to switch models; use "default" to return the coordinator to the deployment default and "same" to make workers use the coordinator model. Changes apply to tasks started afterwards; the setting is per user and persists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workerModelNoai& model id for AgentSwarm workers, or "same" (use the coordinator model).
coordinatorModelNoai& model id for the coordinator, or "default".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare idempotent and non-destructive hints, so the description carries the burden of explaining mutability. It does so thoroughly: changes are per-user, persistent, and only apply to tasks started afterwards. It also explains the cost implications of worker vs coordinator model choice, adding real behavioral context beyond the annotations.

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 front-loaded with the core purpose and then builds logically: role explanation, cost rationale, read behavior, write behavior, and persistence semantics. Every sentence earns its place, and the length is justified by the need to explain a stateful setting with special values.

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

Completeness5/5

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

For a tool with two optional parameters and no output schema, the description covers all essential aspects: how to list, how to switch, what special values mean, when changes take effect, and scope. An agent has everything needed to invoke it correctly without additional inference.

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

Parameters5/5

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

Schema coverage is 100%, but the description goes further by explaining that parameter values come from the listed model ids and by defining the two special values 'default' and 'same.' It also ties each parameter to the coordinator/worker role, giving agents the conceptual model needed to pick the right 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 description opens with a specific verb+resource pairing: 'Show or change which ai& models Kimi uses.' It clearly distinguishes between the coordinator and worker roles and states that calling with no arguments lists models, while calling with parameters changes settings. This is unambiguous and easily separable from sibling 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 gives explicit call patterns: no arguments for listing, coordinatorModel/workerModel for switching, and special values 'default' and 'same' with their meanings. It does not name sibling tools or state when not to use this tool, but the context is clear enough for an agent to decide correctly.

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