Activity

1. creatiVision

   added

   bugSomething isn't workingSomething isn't working

   on Jun 15, 2026
2. josephkehan-prog commented on Jul 25, 2026

   

   josephkehan-prog

   on Jul 25, 2026

   More actions

   Still reproducible on 0.23.5, with a second variant of this bug class — the current TS kosong normalizer doesn't cover it.

   Error

   [provider.api_error] 400 tools.function.parameters is not a valid moonshot flavored json schema,
   details: <At path 'root': when using anyOf, type should be defined in anyOf items instead of the parent schema>
   

   Root cause

   normalizeKimiToolSchema in packages/kosong (dist: kimi-*.mjs) fills in missing type fields, but:

   1. The root schema object is explicitly skipped — ensureKimiPropertyTypes only calls recurseSchema(normalized), which visits children but never normalizes the root node itself.
   2. Neither root nor nested nodes handle the MFJS rule above: a node declaring both type and a combinator (anyOf / oneOf / allOf) is passed through unchanged, so walle rejects it. Any tool whose parameter root is { "type": "object", ..., "anyOf": [...] } (or nests that shape under properties / not / if/then/else) triggers the 400.

   Tested fix

   Distribute the parent type into combinator items that lack one, then drop it from the parent — applied to the root and to every visited node:

   function fixCombinatorParentType(node) {
   	if (!isRecord(node) || !hasOwn(node, "type")) return;
   	for (const key of ["anyOf", "oneOf", "allOf"]) {
   		const items = node[key];
   		if (!Array.isArray(items) || items.length === 0) continue;
   		for (const item of items)
   			if (isRecord(item) && !hasOwn(item, "type")) item["type"] = node["type"];
   		delete node["type"];
   	}
   }
   
   function ensureKimiPropertyTypes(schema) {
   	const normalized = cloneJsonValue(schema);
   	if (!isRecord(normalized)) throw new Error("JSON Schema root must normalize to an object.");
   	fixCombinatorParentType(normalized); // was missing: root never normalized
   	recurseSchema(normalized);
   	return normalized;
   }
   
   function normalizeProperty(node) {
   	if (!isRecord(node)) return;
   	fixCombinatorParentType(node); // was missing: nested type+combinator nodes passed through
   	// ... existing logic unchanged
   }

   Verification — ran the patched module against three failing shapes:

   • {type:"object", anyOf:[{required:["input"]},{required:["runInput"]}]} → {anyOf:[{required:["input"],type:"object"},{required:["runInput"],type:"object"}]} ✓
   • nested combinator under properties.<name> → fixed recursively ✓
   • items that already declare their own type → preserved; only the parent type is dropped ✓

   The existing TYPE_COMPLETION_SKIP_KEYS already includes anyOf/oneOf/allOf, so the type-inference logic doesn't re-add a parent type afterwards.
3. creatiVision commented on Aug 24, 2026

   

   creatiVision

   on Aug 24, 2026

   Author

   More actions

   Just a quick update for anyone following this: this issue is still fully viable and currently blocking the use of many standard MCP servers (like mcp-pdf, n8n, or the Xcode MCP) on kimi-code when using Moonshot models.

   The root cause remains the missing pre-flight schema adapter for Moonshot Flavored JSON Schema (MFJS), which was present in the legacy python CLI but got dropped in the TS rewrite.

   This is fully addressed by the open pull request #830, which introduces sanitizeMcpSchema during MCP tool discovery. It automatically intercepts, unpacks $ref pointers, and repairs anyOf / items structures into valid MFJS before the network call is ever made.

   Hopefully it gets merged soon!
4. crycrywhy commented on Sep 9, 2026

   

   crycrywhy

   on Sep 9, 2026

   More actions

   Another shape of this bug — root cause pinned + minimal repro (OpenAI-compatible gateway fronting Vertex AI / Gemini)

   kimi-code 0.7.5 (VS Code extension), 11 MCP servers ≈ 280 tools. Every subagent spawn fails with the gateway wrapping a 400 into a 503:

   Invalid value at 'request.tools[0].function_declarations[89].parameters.properties[2].value' (type.googleapis.com/google.cloud.aiplatform.master.Schema), "object"
   

   (plus indices 98, 99, 110)

   Root cause. Mapping the rejected indices against the session's tool snapshot, then running a feature matrix over all 280 tool schemas: the 4 rejected tools are exactly the only 4 tools that have a parameter literally named properties — all from the official Notion MCP server (API-create-a-data-source, API-patch-page, API-post-page, API-update-a-data-source).

   Minimal repro (direct call, single tool):

   • {"type":"object","properties":{"foo":{"type":"string"}}} → accepted
   • {"type":"object","properties":{"properties":<anything>}} → same INVALID_ARGUMENT, value "object" — regardless of the value (anyOf, {"type":"object"}, {"type":"string"}, even {}). The converter appears to mistranslate a properties-map entry named properties into the bare string "object".

   Full-payload verification. Replaying the real 280-tool request: raw → exactly the 4 production violations; after dropping only the properties-named entries (and their required mentions) → accepted.

   Relation to the open PRs. Neither #808 nor #830 covers this shape — both dereference $ref and fill missing type but leave combinator-carrying properties untouched and never special-case a properties-map entry named properties. Suggest adding this case (drop/escape such entries client-side, or fix the properties key-name collision in the converter) so Vertex-fronted backends are covered too.

   Local workaround that unblocked me: wrapped toolToOpenAI in bundled dist/extension.js with a sanitizer that deletes properties-named entries from properties maps; node --check passes and the gateway replay succeeds.
5. escott-

   added a commit that references this issue on Sep 27, 2026

   feat(tools): advertise provider-portable tool schemas and descriptions (

   ...

   d9a5254
6. genesiscode2026 commented on Sep 27, 2026

   

   genesiscode2026

   on Sep 27, 2026

   More actions

   Confirming this normalization breakdown with standard MCP server schemas.

   The underlying disconnect is that the MCP specification allows full JSON Schema (draft 2020-12), whereas Moonshot / OpenAI-compatible function calling endpoints enforce strict structural constraints:

   1. type: "object" must be explicitly declared at the root of parameters.
   2. Meta-schema keywords like $schema, $defs, and definitions are rejected by the API parameter validator.
   3. Root-level oneOf / anyOf constructs that are not encapsulated within an object wrapper trigger the 400 tools.function.parameters is not a valid schema error.

   A lightweight sanitizer function applied before submitting tool manifests to the API resolves the rejection:

   export function sanitizeMcpToolParameters(schema: Record<string, any>): Record<string, any> {
     const clean = { ...schema };
     delete clean.$schema;
     delete clean.$defs;
     delete clean.definitions;
   
     if (!clean.type || clean.type !== "object") {
       clean.type = "object";
     }
     if (!clean.properties && !clean.additionalProperties) {
       clean.properties = {};
     }
     return clean;
   }

   In our Agent Assurance test suite, we evaluate MCP server tool definitions against diverse LLM gateway validation rules to prevent runtime dispatch crashes. If helpful, I can provide a comprehensive parameter normalizer handling recursive union properties.