Kimi K3
Runs MCP toolsReasoning
Moonshot AI’s 2.8-trillion-parameter model, released July 2026 with open weights. Moonshot aims it at long agent workflows, and it has one requirement that MCP clients commonly get wrong.
What Kimi K3 is
Kimi K3 is a mixture-of-experts model with 2.8T parameters in total and 104B active per token: 16 of 896 experts. It uses Kimi Delta Attention with gated MLA, ships MXFP4 weights, and has a 1M-token window with image and video input. The weights are on Hugging Face under Moonshot’s own Kimi K3 licence. Moonshot says it is strong at navigating large repositories, using tools, debugging, and iterating against logs, tests and runtime feedback.
What Moonshot AI says
- Terminal-Bench 2.1: 88.3.
- BrowseComp: 91.2.
- DeepSWE: 67.5. GPQA Diamond: 93.5.
- Moonshot says K3 still trails Claude Fable 5 and GPT-5.6 Sol overall but beats Claude Opus 4.8 and GPT-5.5 on its coding and agent evaluations.
These are the vendor’s own claims, not measurements of ours. Run the model against your own server to find out whether they hold for your tools.
How it reaches MCP
- Moonshot’s OpenAI-compatible API as kimi-k3, so most MCP client libraries point at it with a base-URL change
- The open weights, served with vLLM, SGLang or TokenSpeed, behind any MCP client
- MCP Playground’s Agent Studio: paste your server URL above and run K3 against it in the browser, with no Moonshot key
What to watch for
- Thinking is always on and has to survive the tool loop. Moonshot requires the full assistant message, including reasoning_content and tool_calls, to be sent back on the next request. A client that keeps only content can destabilise later turns. This is the first thing to check if K3 does well on one call and drifts on the third.
- reasoning_effort takes low, high or max and defaults to max. Long tool chains at max are slow. Try high before deciding the model is too slow for your server.
- OpenRouter lists parallel_tool_calls for Kimi K2.7 Code but not for K3. A client that fans out several calls in one turn may see them come back one at a time.
Run K3 on a four-step task against the complex-schema mock: create_user_profile, process_order, analyze_data, then configure_workflow. Each step needs the result of the one before, which is exactly where dropped reasoning_content would show. All the mock servers →
Available here
| Model | Model ID |
|---|
| Kimi K3 | moonshotai/kimi-k3 |
Frequently asked questions
Does Kimi K3 support tool calling?
Yes. OpenRouter lists tools and tool_choice for it, and Moonshot’s API is OpenAI-compatible, so MCP servers work through any client that translates MCP tools into function calls, provided the client passes reasoning_content back between turns.
Why does Kimi K3 need reasoning_content passed back?
K3 was built around preserved thinking: within one tool-call loop it expects to see its own earlier reasoning. Moonshot’s docs say sending back only the content can destabilise later turns, so clients should return the whole assistant message.
Can I run Kimi K3 locally?
The weights are public, but at 2.8T parameters the raw MXFP4 weights alone are around 1.4TB, and Northflank recommends 64 or more accelerators. To try it against an MCP server without that, use it here.
Kimi K3 or Kimi K2.7 Code for MCP?
K3 is the larger general model with a 1M window. K2.7 Code is coding-focused with a 262K window and lists parallel tool calls on OpenRouter. Both are available here, so run the same prompt on each against your server.