mistral-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.2
Disambiguation4/5
Most tools have distinct purposes (code completion, chat, OCR, vision, audio, workflow). However, mistral_chat and mistral_vision both handle chat, which could cause confusion despite descriptions clarifying modality differences. This minor overlap prevents a perfect score.
Naming Consistency5/5
All tool names follow a consistent pattern: lowercase snake_case with a product/domain prefix (codestral_, mistral_, voxtral_, workflow_) followed by an action (fim, chat, ocr, vision, transcribe, execute, interact, status). This is highly predictable and uniform.
Tool Count5/5
With 8 tools, the server covers multiple AI capabilities (code, chat, vision, OCR, audio) and workflow management without being bloated. Each tool earns its place, and the count aligns well with the server's stated purpose.
Completeness4/5
The tool surface is comprehensive for the advertised features: generation, vision, OCR, audio, and workflow lifecycle. Minor gaps exist (e.g., no model listing or file management), but they don't hinder core workflows. The set feels complete for its scope.
Average 4.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, etc. The description adds behavioral details like input types, pagination options, and return fields (markdown, hyperlinks, annotations) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence followed by bullet options and return fields. It is moderately concise but each sentence adds value. Slightly more brevity could be achieved.
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 description covers essential aspects: input types, all options, return values. It fails to mention default values for optional parameters (e.g., model, tableFormat) which is a minor gap, but overall complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 8% schema coverage, the description adds significant meaning to parameters: explains document format variants, pages syntax, tableFormat, extractHeader/Footer, includeImageBase64, annotation formats, and confidence scores. A few parameters like imageLimit and document_annotation_prompt are unaddressed, but overall compensates well.
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 clearly states the tool performs OCR on PDFs/images and returns structured markdown per page. It uses specific verbs and resources, distinguishing it from siblings like mistral_vision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for OCR) and lists options, but does not explicitly guide when not to use it or compare to sibling tools like mistral_vision or workflow tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by explaining the default stop behavior and the ability to override it. No contradictions. Additional context on the completion mechanism ('writes the middle') is provided.
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?
Four sentences with no redundancy. Information is front-loaded: purpose first, then usage, then behavioral tweak. Every sentence adds value.
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?
Given the presence of an output schema and annotations, the description covers the core concept and key behavior of stop tokens. It does not detail all 8 parameters, but the essential ones for operation are explained. The description is sufficient for an AI agent to use the tool effectively.
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 description coverage is only 38%, but the description explains the key parameters prompt and suffix clearly. It also mentions stop default and override. However, common parameters like temperature, max_tokens, top_p are left to the schema, which lacks descriptions. The description does not fully compensate for the low coverage.
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?
Explicitly states 'Fill-in-the-middle code completion' with clear verb-resource pairing. It describes the input structure (prompt/suffix) and output (writes the middle) clearly distinguishing it from sibling tools like chat, OCR, vision.
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?
Lists specific use cases (editor autocomplete, code-patching agents, structured refactors) but does not provide explicit when-not-to-use guidance or compare to siblings. However, the sibling tools are very distinct, making the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds return details (text, language, segments, token usage) but does not disclose additional behavioral traits beyond what annotations cover.
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 well-structured with bullet points for models, audio sources, options, and returns. It is concise, front-loaded, and every sentence adds value.
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 description covers purpose, all parameters, and return data. It lacks mention of file size limits or supported formats beyond the schema, but overall it is thorough for a transcription tool.
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?
With only 43% schema description coverage, the description compensates by explaining audio source structure, language hint, diarize, timestampGranularities, and contextBias. This adds significant meaning beyond the schema.
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 clearly states 'Transcribe an audio file to text using Mistral Voxtral,' providing a specific verb and resource. It distinguishes from sibling tools (e.g., codestral_fim, mistral_chat) which serve different purposes.
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 provides clear usage context: accepted models, two audio source options, and explanation of optional parameters. However, it lacks explicit guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds significant behavioral context: immediate return with execution_id and RUNNING status for async mode, blocking for sync mode, and timeoutSeconds cap. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for modes and parameters. It is appropriately sized and front-loaded with key functionality. Could be slightly more concise, but no unnecessary verbosity.
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?
Given the tool's complexity (6 parameters, output schema exists), the description adequately covers execution modes, polling, timeout, and deployment targeting. It explains the return behavior for both modes, though it could mention error handling or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema: workflowIdentifier is visible in mistral://workflows, input is free-form JSON matching workflow input schema, waitForResult modes explained, timeoutSeconds default and cap, deploymentName for targeting a slot.
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 clearly states it starts a Mistral Workflow execution, using specific verb and resource. It distinguishes itself from sibling tools like workflow_status and workflow_interact by describing execution modes and polling.
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 explains when to use waitForResult=false (async) vs true (blocking), mentions polling with workflow_status for async mode, and deploymentName for multiple slots. It provides clear context but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, idempotentHint, and openWorldHint. The description adds behavioral context beyond annotations: polling behavior, terminal statuses, and that `result` is populated at terminal state. No contradictions.
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 concise: two sentences plus a bullet list of statuses. It is front-loaded with the purpose, followed by usage guidance and statuses. No superfluous words.
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 simple polling tool with one parameter and an existing output schema, the description covers all essential aspects: purpose, polling behavior, statuses, and result availability. It is complete given the tool's simplicity and the presence of annotations.
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?
The single parameter executionId is fully described in the input schema with 'Execution ID from workflow_execute' (schema coverage 100%). The description does not add further parameter details, but baseline is 3 given high coverage. The description references waitForResult context, which is about the previous call, not the parameter itself.
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 clearly states 'Get the current state and result of a workflow execution', specifying the action (get) and resource (workflow execution). It also lists valid statuses, distinguishing it from sibling tools like workflow_execute (which starts execution) and workflow_interact (which may modify execution).
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 provides explicit polling guidance: 'Poll until status is COMPLETED (or terminal) when waitForResult was false.' This tells agents when to use the tool (after workflow_execute with waitForResult=false) and implies not needed if waitForResult=true. It does not explicitly mention alternatives or when not to use, but context from sibling tools is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by stating 'Returns the assistant text + token usage', clarifying the output structure. No contradictions; the description is consistent with 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 concise (~150 words), front-loaded with purpose, uses bullet points for models, and clearly formats content structure. Every sentence earns its place with no redundancy.
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?
Given the presence of an output schema, the description appropriately focuses on input format, model selection, and usage context. It covers the tool's role, multimodal capability, and the when-to-use alternative. A mild gap is no mention of role alternation or conversation flow, but not critical.
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 description coverage is 50% (3 of 6 parameters have descriptions). The description adds meaning for the messages parameter (explaining content format as string or array with text/image_url/document_url parts) and model list, but does not compensate for undocumented parameters like temperature, max_tokens, top_p. Baseline 3 with marginal improvement.
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 clearly states 'Chat completion with multimodal input: text + image_url parts', specifying the verb (chat), resource (multimodal input), and scope (text+image). It also lists compatible models and explicitly distinguishes from mistral_chat for non-visual requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Requires a vision-capable model' and lists accepted models. It provides clear guidance: 'For non-visual requests, prefer mistral_chat', directly telling when to use this tool versus its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it clarifies that the tool returns structured content with assistant text and token usage, and explicitly states it does not stream. Although no mention of side effects or permissions, the annotations already cover safety profile. The contradiction check is false (readOnlyHint true aligns with non-streaming read operation).
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 concise with a clear structure: main purpose, bullet points for when to use, and a separate line about streaming. Every sentence adds value, and the information is front-loaded.
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?
Given the complexity of a chat completion tool and the presence of an output schema (as indicated by context signals), the description covers purpose, usage guidance, alternatives, and streaming behavior. It is complete enough for an agent to correctly select and invoke the tool.
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 description coverage is 63%; the description does not add detailed parameter semantics beyond the schema. However, the usage guidelines indirectly help with model selection. The schema already describes most parameters adequately, so a baseline of 3 is appropriate.
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 clearly states 'Generate a chat completion using a Mistral model', specifying the verb (generate) and resource (chat completion). It also distinguishes from sibling tools by mentioning Codestral for code, Ministral for classification, and mistral_chat_stream for streaming, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (e.g., drafting French content, Code/classification alternatives) and when-not-to-use ('Does NOT stream — use mistral_chat_stream'). It also gives clear alternatives, offering strong guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only basic hints (readOnlyHint=false, etc.), but the description adds critical behavioral details: signal is fire-and-forget, query returns inline results, update modifies state synchronously. No contradictions with 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?
Description is well-structured with a concise overview followed by bullet points for each action. Every sentence adds value, no repetition or fluff. Front-loaded with the core purpose.
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?
Covers all three action types and their effects. Mentions return values for query and update. Could mention that the workflow must be running, but overall sufficiently complete for the tool's complexity.
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?
Input schema has 100% description coverage, but the description adds context per action: explains how 'name' and 'input' are used differently for signal, query, and update, and notes that query/update return results inline. This goes beyond the schema.
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?
Description clearly states the tool sends signals, queries, or updates a running workflow execution. It distinguishes three actions (signal, query, update) with specific verbs and the resource (running workflow), setting it apart from siblings like workflow_execute and workflow_status.
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?
Description explains when to use each action (e.g., signal is fire-and-forget, query is synchronous read). It does not explicitly state when not to use the tool or compare with alternatives, but the action-specific guidance provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mistral-mcp MCP server](https://glama.ai/mcp/servers/Swih/mistral-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Swih/mistral-mcp)

Score Badge

Copy to your README.md:

[![mistral-mcp MCP server](https://glama.ai/mcp/servers/Swih/mistral-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Swih/mistral-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Swih/mistral-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server