Mistral Provider: All tool execution fails with HTTP 400 (streaming generation)

[edo-dzell]

Mistral Provider: All tool execution fails with HTTP 400 (streaming generation)

Environment

• OS: Windows 11
• Obsidian Version: 1.12.7
• Nexus Version: v5.6.8
• Provider: Mistral (API key via La Plateforme)
• Model: Mistral Large Latest
• Node.js: v18+

Summary

Simple chat with Mistral works correctly. However, every tool execution (storageManager.list, file read, etc.) fails with HTTP 400. This makes vault access completely non-functional with the Mistral provider.

Steps to Reproduce

1. Install Nexus v5.6.8 in Obsidian (Windows)
2. Configure Mistral as provider with valid API key
3. Select "Mistral Large Latest" as model
4. Verify simple chat works (e.g. "What is 2+2?" → responds correctly ✅)
5. Set up a workspace with vault root or subfolder
6. Ask: "List all files in my vault" or "Read file XYZ.md"
7. Tool execution fails with HTTP 400

Expected Behavior

Nexus should call Mistral's tool/function-calling API in the correct format and successfully execute vault operations (list, read, write).

Actual Behavior

Every tool call returns:

❌ Tool execution failed: streaming generation failed with HTTP 400

Console Errors

[MistralAdapter] Streaming error: ProviderHttpError: streaming generation failed with HTTP 400
    at IncomingMessage.eval (plugin:nexus:7696:25)
    at IncomingMessage.emit (node:events:531:35)
    at endReadableNT (node:internal/streams/readable:1698:12)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21)
 
Streaming tool execution error: Object

What Works vs. What Doesn't

Feature	Status
Simple chat (no tools)	✅ Works
Model detection & listing	✅ Works
Workspace context loading	✅ Works
Provider connection / API key	✅ Works
Any tool execution (list, read, write)	❌ HTTP 400

Probable Root Cause

Based on cross-project research, Mistral's API has strict validation requirements for tool-calling that differ from Anthropic/OpenAI:

1. Tool Call ID Format

Mistral requires tool call IDs to be exactly 9 alphanumeric characters (a-z, A-Z, 0-9). Other providers accept longer or differently formatted IDs. If Nexus generates IDs in a different format (e.g. timestamp-based), Mistral rejects with HTTP 400.

• Reference: openclaw/openclaw#57672

2. Extra Fields in Tool Definitions

Mistral strictly rejects any non-standard fields in tool function definitions (e.g. requires_confirmation, external_execution). OpenAI and Anthropic silently ignore these. The MistralAdapter may need to strip Nexus-internal parameters before sending.

• Reference: agno-agi/agno#5521

3. Tool Schema Restrictions

Mistral may reject oneOf, allOf, anyOf at the top level of tool input schemas. This was previously an issue with Claude Code as well (Nexus issue #6, now closed).

4. Message Role Ordering

Mistral rejects "user" role messages immediately after "tool" role messages. The conversation must include an "assistant" message between tool results and user messages.

• Reference: BerriAI/litellm#6323

Suggested Fix

The MistralAdapter in ProviderHttpClient likely needs:

1. Tool call ID sanitization — generate 9-char alphanumeric IDs for Mistral
2. Tool schema cleanup — strip non-standard fields before API call
3. Message role validation — ensure correct role ordering per Mistral's requirements

Additional Context

• Prior issue (fixed in v5.6.8): Earlier BRAT versions had a CORS error where node:https was dynamically imported, blocked by Obsidian's Electron environment. Resolved in v5.6.8 via ProviderHttpClient.
• Mistral's function calling docs: https://docs.mistral.ai/capabilities/function_calling/
• This likely affects all Mistral models, not just Mistral Large.

Workaround

Currently none for tool-calling. Simple chat without vault access works as expected.

[ProfSynapse]

Thanks for this! I literally never use mistral so had no clue this was happening I will look into it.

[ProfSynapse]

Hi @edo-dzell — thanks for the detailed report! We've pushed a fix in PR #101 that addresses all four of the root causes you identified:

1. Tool call ID sanitization — prepareMessages() now generates Mistral-compatible 9-char alphanumeric IDs
2. Message role ordering — conversation history is normalized to ensure correct role sequencing per Mistral's API requirements
3. Tool schema cleanup — non-standard fields are stripped before API calls
4. ProviderHttpClient streaming — improved node:http/https fallback with proper timeout handling

We also updated the Mistral model catalog to April 2026 (Mistral Large now 256K context, added Devstral, Codestral, Pixtral, Magistral models).

A new release is out 5.6.10. Could you update and let us know if tool calling works for you?