What can you do with this server?

mistral-mcp is a self-hosted MCP server that exposes Mistral AI's full API as tools, resources, and prompts across chat, vision, OCR, audio, code, and durable workflows. * Chat & Vision: mistral_chat for text generation (including Magistral reasoning models, structured JSON output, temperature control); mistral_vision for multimodal chat with images (URL or base64) via Pixtral. * OCR / Document AI: mistral_ocr extracts structured markdown, bounding boxes, tables, hyperlinks, and JSON annotations from PDFs and images. * Audio Transcription: voxtral_transcribe converts audio to text with optional speaker diarization, language hints, and timestamp granularity. * Code Completion: codestral_fim performs fill-in-the-middle inline code completion using Codestral. * Durable Workflows: workflow_execute (launch Temporal-backed workflows sync or async), workflow_status (poll state/result), workflow_interact (send signals, queries, or updates for human-in-the-loop scenarios). * Admin Tools (via profile): embeddings, streaming, agents, moderation, classification, TTS, file management, and batch operations. * Resources: Live catalogs at mistral://models, mistral://voices, mistral://workflows. * Prompts: Curated French-language prompts for meeting minutes, email replies, commit messages, legal summaries, and invoice reminders. * Integration: Compatible with Claude Code, Cursor, and Zed; supports configurable profiles (core, admin, workflows, metier-docs) for tailored tool exposure, with GDPR-conscious self-hosted deployment.

Which integrations are available for this server?

Enables durable workflow execution with Temporal, supporting starting, querying, and signaling long-running Mistral Workflows, including human-in-the-loop checkpoints.

de en es ja ko ru zh

mistral-mcp

by Swih

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mistral-mcp

Mistral, wherever you run it. MCP server for the full Mistral AI API — chat, OCR, audio (Voxtral), code (Codestral), vision, agents, batch, durable workflows — against Mistral Cloud or your own infrastructure. Plug into Claude Code, Cursor, Zed, Windsurf, or Claude Desktop in one command.
Version française : README.fr.md

npm version Glama MCP score license MCP spec

What this is

mistral-mcp exposes the full Mistral AI API as a set of MCP tools, resources, and prompts. An MCP client (Claude Code, Cursor, etc.) can call mistral_ocr to extract text from a PDF, voxtral_transcribe to transcribe a meeting recording, or workflow_execute to start a durable multi-step process — all without leaving the agent loop.

Unique to Mistral and not available from other MCP servers:

mistral_ocr — Mistral Document AI: structured text + bbox annotations from any PDF or image
voxtral_transcribe — Voxtral: transcription with optional speaker diarization
codestral_fim — Codestral fill-in-the-middle (FIM) for inline code completion
workflow_* (6 tools) — Temporal-backed durable execution: what is deployed and runnable, what is running, human-in-the-loop signals, and graceful or forced stop
French-optimized models (mistral-large-latest, mistral-medium-latest) and curated French prompts

What this server does not expose: fine-tuning, user management, non-FR/EN prompts.

Related MCP server: MCP Server TypeScript

Why this matters for European teams

mistral-mcp is designed for teams that want to use Mistral capabilities inside MCP clients (Claude Code, Cursor, Zed, Windsurf, Claude Desktop) while keeping control over deployment, API keys, cache behavior, and tool exposure.

This can be useful for European organisations evaluating AI stacks under GDPR, DORA, sector-specific constraints (HDS, EBA), or internal sovereignty requirements.

What this project provides:

self-hosted MCP server, no mandatory SaaS proxy
bring-your-own Mistral API key (BYOK) — Mistral states API data is not used to train its models
MISTRAL_BASE_URL routes every call to your own OpenAI-compatible endpoint (vLLM, TGI, LiteLLM, an internal gateway) — no traffic to api.mistral.ai
lean core profile and focused metier-docs profile to limit tool exposure
process_document cache configurable per-call and via MISTRAL_MCP_CACHE_DIR, with a retention window (MISTRAL_MCP_CACHE_TTL_HOURS, default 7 days, 0 to disable) after which entries are deleted, not merely bypassed
ID document cache bypass enabled by default, even when kind:"auto" resolves to id_document
Streamable HTTP + bearer auth path for controlled / on-prem deployments
French-first prompts and skills (meeting minutes, legal summary, invoice reminder, commit message, email reply)
free Experiment tier on the Mistral side covers most evaluation needs (~1B tokens/month)

What this project does NOT claim:

it is not a GDPR, DORA, HDS, or ISO certification, and it does not replace a DPIA, vendor review, security audit, or legal assessment
Mistral provider terms, data residency, subprocessor list, retention settings, and incident handling must be reviewed separately at mistral.ai/terms and legal.mistral.ai
this repo is community-maintained, not an official Mistral integration; nothing here modifies Mistral's contractual data terms with you

In practice, mistral-mcp reduces the integration surface you have to assess. It does not replace the legal/compliance work itself.

Quick start

Claude Code (recommended — auto-installs, prompts for API key, ships 11 skills):

/plugin install mistral-mcp@swih-plugins

Cursor / Zed / Windsurf / Claude Desktop — add to your MCP settings JSON:

{
  "mcpServers": {
    "mistral": {
      "command": "npx",
      "args": ["-y", "mistral-mcp@latest"],
      "env": { "MISTRAL_API_KEY": "your_key_here" }
    }
  }
}

Manual Claude Code registration:

claude mcp add mistral -- npx -y mistral-mcp@latest

Profiles

MISTRAL_MCP_PROFILE controls how many tools are exposed (default: core).

Profile	Tools	Use when
`core` (default)	13	Daily agentic use — lean context footprint
`admin`	41	Full Mistral API surface — embeddings, streaming, batch, classify, files, agents, TTS, document extraction, stateful conversations, RAG libraries. Best for debug, CI, scripts.
`workflows`	8	Pipeline orchestration + connectors only
`metier-docs`	14	Documents vertical — core + `process_document` macro-tool
`self-hosted`	5	Inference on your own OpenAI-compatible endpoint — inferred from `MISTRAL_BASE_URL`

full is accepted as a deprecated alias of admin for backward compatibility.

MISTRAL_MCP_PROFILE=admin npx mistral-mcp

Read mistral://capabilities from any client to see which tool families are on, which are off, and why — no need to diff this table against your deployment.

Tools

Core profile (16 tools — always available)

Tool	What it does
`mistral_chat`	Chat completion. Supports all Mistral models, `response_format`, `reasoning_effort` for Magistral.
`mistral_vision`	Multimodal chat with images (URL or base64).
`mistral_ocr`	Document AI — extract text, bbox, and JSON annotations from PDFs/images. Pass `includeBlocks: true` for OCR 4 paragraph-level blocks (text/title/table/image/equation/... with bounding boxes).
`codestral_fim`	Fill-in-the-middle code completion (Codestral model).
`voxtral_transcribe`	Audio → text. Pass `diarize: true` for speaker separation.
`workflow_execute`	Start a Mistral Workflow (Temporal-backed durable execution).
`workflow_status`	Poll a running workflow — returns `RUNNING \| COMPLETED \| FAILED \| ...`.
`workflow_interact`	Signal / query a running workflow. Used for human-in-the-loop checkpoints.
`workflow_deployments_list`	List workflow deployments and whether each has a live worker. Call it before `workflow_execute` — a listed workflow with no active deployment answers 404.
`workflow_runs_list`	List workflow executions, filtered by workflow, status or deployment.
`workflow_stop`	Stop an execution — `cancel` (graceful, runs cleanup handlers) or `terminate` (immediate).
`connectors_list`	Discover Mistral Connectors (MCP/HTTP integrations) visible to the caller.
`connectors_get`	Fetch one connector's public metadata (never credentials).
`connectors_list_tools`	List the MCP tools a connector exposes, with their input schema.
`connectors_call_tool`	Invoke a connector's tool — real MCP `CallToolResult` passthrough.
`rag_indexes_list`	List the search-index deployments on your account, with backend and document counts.

Documents vertical (`MISTRAL_MCP_PROFILE=metier-docs`)

Tool	What it does
`process_document`	Single-call macro-tool: OCR → classify (kind=auto) → typed extraction → validation → cache. Kinds: `contract` / `invoice` / `id_document` / `generic`. Returns a discriminated union. PII-safe cache (id_document auto-bypass). Configurable `minOcrConfidence`.

Admin profile only (+28 tools, set `MISTRAL_MCP_PROFILE=admin`)

Group	Tools
Generation	`mistral_chat_stream`, `mistral_embed`, `mistral_tool_call`
Agents	`mistral_agent`, `mistral_moderate`, `mistral_classify`
Audio	`voxtral_speak` (TTS)
Files	`files_upload`, `files_list`, `files_get`, `files_delete`, `files_signed_url`
Batch	`batch_create`, `batch_get`, `batch_list`, `batch_cancel`
Conversations	`conversation_start`, `conversation_append`, `conversation_get`, `conversation_list`, `conversation_history`, `conversation_delete` — stateful multi-turn agent loops with Mistral's built-in tools (web_search, code_interpreter, image_generation, document_library)
Libraries (RAG)	`libraries_list`, `libraries_get`, `libraries_documents_list`, `libraries_documents_upload`, `libraries_documents_status` — discover and feed already-created Mistral Libraries; pair with `conversation_start`'s `documentLibraryIds` to search them

Resources

URI	What it returns
`mistral://capabilities`	Which tool families are registered, which are not, and why — plus the active profile and endpoint
`mistral://models`	Live model catalog, read from the endpoint actually in use
`mistral://voices`	Live Voxtral TTS voice catalog — registered only when the `tts` family is on (`admin`)
`mistral://workflows`	Live list of deployed workflows (use `name` as `workflowIdentifier`) — not registered under `self-hosted`

Prompts

Curated prompts with structured arguments and MCP completion support:

Prompt	Input	Output
`french_meeting_minutes`	transcript text	Structured French meeting minutes
`french_email_reply`	received email + context	Polished French reply
`french_commit_message`	git diff	Conventional Commits message in French
`french_legal_summary`	legal document text	Plain-French summary + key clauses
`french_invoice_reminder`	debtor, amount, days overdue, tone	B2B dunning letter in French
`codestral_review`	git diff	Focused code review (security / logic / style)

Claude Code skills (11)

Install via the swih-plugins marketplace to get these namespaced skills:

Routing

/mistral-mcp:mistral-router — picks the right Mistral model + tool for any task

Code

/mistral-mcp:codestral-review — fetches the current diff, runs a focused review

French workflows

/mistral-mcp:french-commit-message — Conventional Commits message in French
/mistral-mcp:french-meeting-minutes — audio or text → structured French minutes
/mistral-mcp:french-invoice-reminder — B2B dunning letter with controlled tone

Document & audio processing

/mistral-mcp:contract-analyzer — OCR → risk-rated clause extraction (JSON)
/mistral-mcp:pdf-invoice-extractor — OCR → structured invoice fields for reconciliation
/mistral-mcp:audio-dispatch — transcribe + diarize → per-speaker action plan

Human-in-the-loop workflows

/mistral-mcp:contract-review-workflow — durable contract review with approval gates
/mistral-mcp:compliance-audit-workflow — multi-step audit with mid-run findings + decisions
/mistral-mcp:research-pipeline-workflow — hypothesis-driven research with amendment injection

Install

# Run directly (no global install)
npx mistral-mcp

# Global install
npm install -g mistral-mcp && mistral-mcp

# Docker
docker build -t mistral-mcp .
docker run -i --rm -e MISTRAL_API_KEY=your_key mistral-mcp

# From source
git clone https://github.com/Swih/mistral-mcp.git
cd mistral-mcp && npm install && npm run build
node dist/index.js

Document ingestion, evaluated

process_document ships with a corpus and a harness, because "handles heterogeneous PDFs" is a claim, and a claim without a measurement is marketing.

npm run fixtures:generate   # rebuild the corpus from source (no key needed)
npm run eval:docs           # score it against real OCR (needs MISTRAL_API_KEY)

The corpus is eight synthetic documents chosen for the cases that actually break ingestion pipelines, not for the ones that flatter them: a rotated landscape scan (/Rotate 90), ruled line-item tables, side-by-side address columns, a blank page in the middle of a document, mixed FR/EN, French accents and the euro sign, and one near-empty page. Ground truth for each document — expected kind, page count, and the strings that must survive OCR — lives in test/fixtures/corpus.json.

Everything in it is invented: fictional companies, fictional people, fictional identifiers. No real PII is in this repo, and none should be added — the corpus is only useful if it can be published.

npm run eval:docs reports, per document, whether kind: "auto" classified it correctly, whether the required fields survived, and the OCR confidence. It then derives a minOcrConfidence from the run: the midpoint between the worst document that extracted cleanly and the best document marked low-signal. When those two overlap, it says no threshold is defensible rather than inventing one.

The shipped default of 0.3 is a conservative starting point, not a measured value. Run the harness on your own documents and set the number that run justifies.

Observability

Every tool call emits one JSON line on stderr, and the caller's W3C trace context follows the request all the way to the inference endpoint.

{"ts":"2026-08-28T09:14:02.117Z","kind":"tool_call","tool":"mistral_ocr","outcome":"ok","duration_ms":1840,"trace_id":"4bf92f3577b34da6a3ce929d0e0e4736","span_id":"00f067aa0ba902b7"}

Trace continuity. traceparent, tracestate and baggage arrive in the MCP request's _meta and are stamped onto the outgoing HTTP call, so your collector joins the MCP span to the Mistral (or vLLM) span it caused instead of showing two unrelated traces. A malformed header is ignored, never fatal.
No payloads, ever. A line says what ran, how long it took and whether it failed. Prompts, documents, transcripts, arguments and model output never appear — those are your records, and this process has no business copying them into a log it does not own. test/stdio/observability.test.ts asserts that negative directly against the built binary.
Nothing to enable, and one thing to disable. It is on by default because an audit trail you have to discover is one you will not have when you need it. MISTRAL_MCP_AUDIT=off silences it. stderr is used because stdout carries JSON-RPC, and because MCP's own logging capability is deprecated in 2026-07-28 in favour of stderr and OpenTelemetry.

The instrumentation wraps registerTool rather than each handler, so a tool cannot be left out of the trail without being left out of the server.

Self-hosted inference

Point MISTRAL_BASE_URL at any OpenAI-compatible endpoint — vLLM, TGI, LiteLLM, an internal token factory — and every request goes there instead of api.mistral.ai:

MISTRAL_BASE_URL=http://vllm.internal:8000/v1 MISTRAL_DEFAULT_MODEL=my-org/mistral-small-3.2 npx mistral-mcp

Two things change when the endpoint is not Mistral's:

The profile becomes self-hosted. Only the five tools such an endpoint can actually serve stay registered — mistral_chat, mistral_chat_stream, mistral_embed, mistral_tool_call, mistral_vision. OCR, Voxtral, Files, Batch and Workflows are Mistral-platform endpoints; advertising them against vLLM would only produce 404s the calling model has to guess its way out of. Set MISTRAL_MCP_PROFILE explicitly if your gateway does proxy the full API.
Model ids are no longer checked against a list. Any non-empty string is forwarded as-is, because your endpoint's identifiers are yours.

mistral://capabilities reports the active endpoint, the profile, whether it was inferred, and the reason each unavailable family is off.

Compose and Kubernetes manifests, plus the full environment reference, are in deploy/README.md.

Protocol

The server speaks MCP 2026-07-28 and the 2025-era handshake, from the same tool registrations, on the same endpoint. That matters because practically every client shipping today still opens with the 2025 handshake: upgrading the server does not ask anyone to upgrade their client.

	2025-era client	2026-07-28 client
Handshake	`initialize`	`server/discover`
Tools, resources, prompts	identical set	identical set
`structuredContent` + `outputSchema`	yes	yes
Cache hints (`ttlMs`/`cacheScope`)	not in the revision	yes

test/stdio/protocol-eras.test.ts drives the built binary with a real 1.30.x client and a real 2026-07-28 client and asserts both see the same tools — the compatibility claim above is a test, not a promise.

Built on @modelcontextprotocol/server 2.x. Sampling and elicitation tools are not exposed: sampling is deprecated in 2026-07-28, and the multi-round-trip replacement is a client capability this server has no use for.

Transport

Mode	How to enable	Default
stdio	Default	`node dist/index.js`
Streamable HTTP	`MCP_TRANSPORT=http` or `--http` flag	`127.0.0.1:3333/mcp`

HTTP env vars: MCP_HTTP_HOST, MCP_HTTP_PORT, MCP_HTTP_PATH, MCP_HTTP_TOKEN (bearer auth), MCP_HTTP_ALLOWED_ORIGINS.

HTTP serving is stateless per request in both protocol eras, so MCP_HTTP_STATELESS no longer does anything and was removed in 0.10.0. Setting it is harmless.

/healthz is public and does not touch the MCP server.

Use as a Mistral Connector (beta)

mistral-mcp ships the Streamable HTTP transport and bearer auth that Mistral Connectors require. Deployment guides for Cloudflare Tunnel, Fly.io, and Cloud Run are in deploy/connector-public.md.

Surface	Status
Local MCP clients (Claude Code, Cursor, Zed, Windsurf, Claude Desktop)	Stable
Streamable HTTP transport + bearer auth	Tested locally (handshake + 401 + initialize verified)
Mistral Connector registration via `POST /v1/connectors`	Setup guide provided — Connectors are a beta feature, the API may change
Connector tool calls in Conversations/Agents	Untested end-to-end (requires public HTTPS deployment)
OAuth 2.1 Connector auth	Pending — bearer-only today

curl -X POST https://api.mistral.ai/v1/connectors \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  -d '{"name":"mistral_self","server":"https://your-deploy/mcp","visibility":"private"}'

Mistral Connectors expose tools only today. Resources and prompts remain available via local clients.

Comparison with other Mistral MCP servers

Project	Scope	Best for
mistral-mcp	Full Mistral API + Workflows + 11 Claude Code skills	All-in-one self-hosted
`mcp-mistral-ocr` (community)	OCR only	Lightweight OCR-only setup
Speakeasy `mistral-mcp-server-example`	Generated demo	Reference / SDK template
Composio `mistral_ai` toolkit	SaaS-routed Mistral tools	Hosted, no infra

mistral-mcp differentiates by combining OCR, Voxtral diarization, Codestral FIM, and Temporal-backed Workflows in one server, with French-first prompts and a Claude Code plugin marketplace.

Development

npm run dev      # tsx watch
npm run build    # tsc → dist/
npm run lint     # tsc --noEmit
npm test         # 190+ tests (unit + contract + stdio e2e + live API)
npm run inspector

Test pyramid: unit → contract → stdio e2e → live API (requires MISTRAL_API_KEY).

License

MIT — Copyright Dayan Decamp

Available Tools

8 tools

codestral_fimCodestral fill-in-the-middle completionA

Read-only

Fill-in-the-middle code completion with Codestral.

Given prompt (code preceding the cursor) and suffix (code after the cursor), Codestral writes the middle. Use for editor autocomplete scenarios, code-patching agents, or structured refactors where you know the target boundaries.

Default stop tokens: [] — let the model decide. Override with stop if needed.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	Code preceding the cursor.
`suffix`	Yes	Code after the cursor. Can be empty string.
`model`	No
`stop`	No
`temperature`	No
`max_tokens`	No
`top_p`	No
`seed`	No	Random seed for deterministic sampling. Maps to Mistral's `random_seed`.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`model`	Yes
`finish_reason`	No
`usage`	No

TDQS

A4.2/5.0

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.

mistral_chatMistral chat completionA

Read-only

Generate a chat completion using a Mistral model.

When to use:

Drafting French (or any European-language) content where Mistral shines.
Codestral for code-specific generation/review.
Ministral for cheap / low-latency classification.

Returns structured content with the assistant text and token usage. Does NOT stream — use mistral_chat_stream for long outputs with progress updates.

ParametersJSON Schema

Name	Required	Description
`messages`	Yes	Chat messages in role/content form.
`model`	No	Mistral chat model alias. Allowed: mistral-large-latest, mistral-medium-latest, mistral-small-latest, ministral-3b-latest, ministral-8b-latest, ministral-14b-latest, magistral-medium-latest, magistral-small-latest, devstral-latest, devstral-small-latest, codestral-latest, voxtral-small-latest. Default: mistral-medium-latest.
`response_format`	No	Force a structured output: `{type:"json_object"}` for JSON mode, `{type:"json_schema", json_schema:{...}}` for strict schema mode.
`reasoning_effort`	No	Controls reasoning depth for Magistral models. 'high' enables full chain-of-thought; 'none' disables it. Ignored on non-reasoning models.
`temperature`	No
`max_tokens`	No
`top_p`	No
`seed`	No	Random seed for deterministic sampling. Maps to Mistral's `random_seed`.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`model`	Yes
`usage`	No
`finish_reason`	No
`reasoning_content`	No	Reasoning trace returned by Magistral models. Absent for non-reasoning models.

TDQS

A4.5/5.0

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.

mistral_ocrMistral OCR (document to markdown)A

Read-onlyIdempotent

Run Mistral OCR on a PDF or image, returning structured markdown per page.

Input document is one of:

{ type: "document_url", documentUrl: "https://...pdf" }
{ type: "image_url", imageUrl: "https://..." | "data:image/..." }
{ type: "file", fileId: "" }

Options:

pages: array of 0-indexed page numbers or string like "0-5,7".
tableFormat: 'markdown' (default) or 'html'.
extractHeader / extractFooter: include page header/footer when present.
includeImageBase64: embed extracted image bytes as base64 in the response.
document_annotation_format: JSON schema for whole-document structured extraction.
bbox_annotation_format: JSON schema for extracted image / bbox annotations.
confidence_scores_granularity: 'page' or 'word'.

Returns pages[].markdown plus optional pages[].hyperlinks, header, footer, images bounding boxes, annotations, confidence scores, and dimensions.

ParametersJSON Schema

Name	Required	Description
`document`	Yes
`model`	No	OCR model. Default: mistral-ocr-latest.
`pages`	No
`tableFormat`	No
`extractHeader`	No
`extractFooter`	No
`includeImageBase64`	No
`imageLimit`	No
`imageMinSize`	No
`bbox_annotation_format`	No
`document_annotation_format`	No
`document_annotation_prompt`	No
`confidence_scores_granularity`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`pages`	Yes
`model`	Yes
`pages_count`	Yes
`document_annotation`	No
`annotations`	No
`usage`	No

TDQS

A4.1/5.0

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.

mistral_visionMistral multimodal chat (vision)A

Read-only

Chat completion with multimodal input: text + image_url parts.

Requires a vision-capable model. Accepted:

pixtral-large-latest
pixtral-12b-latest
mistral-large-latest
mistral-medium-latest
mistral-small-latest

Each message's content is either a plain string (pure text) or an array of parts { type: 'text', text } / { type: 'image_url', imageUrl }. The image URL can be an https URL or a data: URI base64 payload.

Returns the assistant text + token usage. For non-visual requests, prefer mistral_chat.

ParametersJSON Schema

Name	Required	Description
`messages`	Yes	Chat messages. Pure-text requests are accepted, but this tool is intended primarily for multimodal prompts containing image parts.
`model`	No	Vision-capable Mistral model. Default: pixtral-large-latest.
`temperature`	No
`max_tokens`	No
`top_p`	No
`seed`	No	Random seed for deterministic sampling. Maps to Mistral's `random_seed`.

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`model`	Yes
`usage`	No
`finish_reason`	No

TDQS

A4.4/5.0

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.

voxtral_transcribeVoxtral speech-to-textA

Read-onlyIdempotent

Transcribe an audio file to text using Mistral Voxtral.

Accepted models:

voxtral-mini-latest
voxtral-small-latest

Audio source is one of:

{ type: "file_url", fileUrl: "https://..." } (public URL)
{ type: "file", fileId: "" }

Options:

language: ISO-639-1 hint (e.g. 'fr', 'en'). Boosts accuracy when known.
temperature: sampling temperature.
diarize: return per-speaker segments (default false).
timestampGranularities: ['segment'] to return per-segment timestamps.
contextBias: list of phrases/terms that should bias the decoder.

Returns plain text, detected language, optional segments[], and token usage.

ParametersJSON Schema

Name	Required	Description
`audio`	Yes
`model`	No	STT model. Default: voxtral-mini-latest.
`language`	No	ISO-639-1 language hint (e.g. 'fr', 'en').
`temperature`	No
`diarize`	No
`timestampGranularities`	No	Only 'segment' is currently supported.
`contextBias`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`text`	Yes
`model`	Yes
`language`	Yes
`segments`	No
`usage`	No

TDQS

A4.3/5.0

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.

workflow_executeExecute a Mistral workflowA

Start a Mistral Workflow execution.

workflowIdentifier is the workflow name or ID (visible in mistral://workflows). input is a free-form JSON object matching the workflow's input schema.

Modes:

waitForResult=false (default): returns immediately with execution_id and RUNNING status. Poll workflow_status to track completion.
waitForResult=true: blocks until the workflow finishes and returns the result inline. Use timeoutSeconds (default 30) to cap the wait.

Use deploymentName to target a specific deployment slot when multiple are configured.

ParametersJSON Schema

Name	Required	Description
`workflowIdentifier`	Yes	Workflow name or ID.
`input`	No	Input payload matching the workflow input schema.
`executionId`	No	Optional custom execution ID. Auto-generated if omitted.
`waitForResult`	No	Block until completion and return result inline. Default: false.
`timeoutSeconds`	No	Max wait time when waitForResult=true. Default: 30.
`deploymentName`	No	Target a specific deployment slot.

Output Schema

ParametersJSON Schema

Name	Required	Description
`workflow_name`	Yes
`execution_id`	Yes
`sync`	Yes	true when waitForResult=true (result is inline).
`status`	No
`result`	No
`root_execution_id`	No
`start_time`	No
`end_time`	No
`total_duration_ms`	No

TDQS

A4.3/5.0

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.

workflow_interactSignal, query, or update a running workflowA

Send a signal to or run a query against a running workflow execution.

action=signal: fire-and-forget event; the workflow reacts asynchronously.

name: signal name defined in the workflow.
input: optional payload matching the signal's schema.

action=query: synchronous read of internal workflow state.

name: query handler name defined in the workflow.
input: optional parameters for the query.
Returns query_name + result inline.

action=update: synchronous request to modify workflow state mid-execution.

name: update handler name defined in the workflow.
input: optional payload for the update.
Returns update_name + result inline.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Interaction type.
`executionId`	Yes	Target execution ID.
`name`	Yes	Signal or query handler name.
`input`	No	Optional payload for the signal or query.

Output Schema

ParametersJSON Schema

Name	Required	Description
`action`	Yes
`execution_id`	Yes
`message`	No	Confirmation message for signal actions.
`query_name`	No
`update_name`	No
`result`	No	Query or update result payload.

TDQS

A4.7/5.0

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.

workflow_statusGet workflow execution statusA

Read-onlyIdempotent

Get the current state and result of a workflow execution.

Poll until status is COMPLETED (or terminal) when waitForResult was false. result is populated once the workflow reaches a terminal state.

ParametersJSON Schema

Name	Required	Description	Default
`executionId`	Yes	Execution ID from workflow_execute.

Output Schema

ParametersJSON Schema

Name	Required	Description
`workflow_name`	Yes
`execution_id`	Yes
`root_execution_id`	Yes
`status`	Yes
`result`	No
`start_time`	Yes
`end_time`	Yes
`total_duration_ms`	No

TDQS

A4.3/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

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.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

MCP (Model Context Protocol)
HarishGangula
-
license
Not graded
quality
D
maintenance
A TypeScript implementation of a Model Context Protocol server and client that enables interaction with language models (specifically Mistral running on Ollama).
Updated a year ago (2025-05-05 05:27 UTC)
MCP Server TypeScript
Developer Tools Text Summarization
ichetanmittal
-
license
Not graded
quality
Not graded
maintenance
A production-ready TypeScript MCP server providing basic tools (add, echo, timestamp), resources (server info, greetings, data access), and prompt templates (analyze, code-review, summarize). Serves as a foundation for building custom MCP servers with extensible architecture.
Updated a year ago (2025-10-03 01:02 UTC)
225
Codex Gemini MCP
Code Execution Developer Tools Command Line
donghae0414
A
license
B
quality
C
maintenance
A TypeScript-based MCP server that provides tools to interact with local Codex and Gemini CLIs via stdio transport. It enables users to execute prompts through the ask_codex and ask_gemini tools, supporting custom models and timeout configurations.
Updated 6 months ago (2026-02-26 00:36 UTC)
1
15
5
MIT
template-mcp
Developer Tools Code Execution Command Line
Freddymhs
F
license
A
quality
D
maintenance
A TypeScript MCP server template with Zod validation, dual transport (stdio/HTTP), and modular architecture for building MCP-compatible tools, resources, and prompts.
Updated 4 months ago (2026-04-24 04:07 UTC)
1
1

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

mistral-mcp

What this is

Why this matters for European teams

Quick start

Profiles

Tools

Core profile (16 tools — always available)

Documents vertical (MISTRAL_MCP_PROFILE=metier-docs)

Admin profile only (+28 tools, set MISTRAL_MCP_PROFILE=admin)

Resources

Prompts

Claude Code skills (11)

Install

Document ingestion, evaluated

Observability

Self-hosted inference

Protocol

Transport

Use as a Mistral Connector (beta)

Comparison with other Mistral MCP servers

Development

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Documents vertical (`MISTRAL_MCP_PROFILE=metier-docs`)

Admin profile only (+28 tools, set `MISTRAL_MCP_PROFILE=admin`)