Allows querying a MySQL database of metallurgical material specifications (alloys, grades, chemical elements, standards, mechanical properties) via read-only tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mysql-materials-mcp list all alloy types"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Projet personnel autour d'une base de données de fiches techniques métallurgiques (alliages, nuances, éléments chimiques, normes, propriétés mécaniques). L'ensemble explore la modélisation relationnelle (MySQL) et son exposition via trois points d'accès distincts. Projet local, à visée exploratoire et technique.
Le projet se compose de trois dépôts complémentaires :
mysql-materials-server — Back-end Node.js / MySQL. Gère la base de données et expose une API REST (CRUD).
mysql-materials-front — Front React / React Admin. Interface d'administration CRUD des fiches techniques.
mysql-materials-mcp — Serveur MCP (Node.js). Expose l'accès à la base pour interrogation via un LLM.
Serveur MCP (Model Context Protocol) qui expose la base MySQL du projet à un LLM (Claude Desktop). Claude peut ainsi interroger la base en langage naturel : lister les types d'alliage, filtrer les nuances par type, et récupérer le détail complet d'une nuance avec toutes ses relations.
Le serveur communique avec Claude Desktop via stdio (pas d'API HTTP, pas de port réseau). Il est actuellement en lecture seule.
Related MCP server: MySQL MCP Server
Node.js (ESM, "type": "module")
@modelcontextprotocol/sdk — SDK officiel MCP
mysql2 — accès à la base MySQL (pool de connexions)
zod — validation des paramètres des tools
Node.js (version récente recommandée)
Claude Desktop installé
La base MySQL materials_db doit exister et être accessible. Elle est créée et alimentée par le dépôt mysql-materials-server (voir son README) ; ce serveur MCP ne fait que la lire.
npm installContrairement à un projet Node classique, un serveur MCP est lancé comme sous-processus par Claude Desktop, depuis un répertoire de travail qui n'est pas celui du projet. Un fichier .env local ne serait donc pas trouvé de façon fiable. Les variables d'environnement sont donc injectées directement par Claude Desktop, via le bloc env de sa configuration.
Un modèle est fourni : claude_desktop_config.example.json.
Il faut reporter son contenu dans le fichier de configuration de Claude Desktop, situé à :
Windows : %APPDATA%\Claude\claude_desktop_config.json
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Exemple de configuration à adapter :
{
"mcpServers": {
"mysql-materials-mcp": {
"command": "node",
"args": ["CHEMIN_ABSOLU/mysql-materials-mcp/server.js"],
"env": {
"DB_HOST": "localhost",
"DB_PORT": "...",
"DB_USER": "USER_READ_ONLY",
"DB_PASSWORD": "...",
"DB_NAME": "materials_db"
}
}
}
}Points importants :
args : chemin absolu vers server.js. Sous Windows, doubler les backslashes (C:\\...).
Après toute modification, redémarrer complètement Claude Desktop (le quitter réellement, pas seulement fermer la fenêtre) pour qu'il relance le serveur avec les nouvelles variables.
Le fichier claude_desktop_config.json contient les identifiants en clair : il vit hors du dépôt et ne doit jamais être committé. Seul le modèle claude_desktop_config.example.json (valeurs factices) est versionné.
Le serveur étant en lecture seule, il est recommandé de lui dédier un utilisateur MySQL avec le seul droit SELECT.
Le serveur est lancé automatiquement par Claude Desktop dès que celui-ci démarre (via la configuration ci-dessus). Une fois Claude Desktop redémarré, les trois tools apparaissent et sont utilisables dans une conversation.
Pour un test manuel en dehors de Claude Desktop :
npm start
# ou en développement avec rechargement auto :
npm run dev.
├── server.js # Point d'entrée MCP : création du serveur, enregistrement des tools, transport stdio
├── db/
│ └── configDb.js # Pool de connexions MySQL (lecture seule)
├── tools/ # Un fichier par tool exposé à Claude
│ ├── getAlloyTypes.tool.js # Liste des types d'alliage
│ ├── getAlloyNuances.tool.js # Nuances filtrées par type d'alliage
│ └── getAlloyNuanceById.tool.js # Détail complet d'une nuance
└── claude_desktop_config.example.json # Modèle de configuration Claude DesktopLe serveur expose trois tools, pensés pour une navigation progressive : d'abord les types, puis les nuances d'un type, puis le détail d'une nuance.
Tool | Paramètre | Rôle |
| aucun | Liste tous les types d'alliage (id, nom, description). |
|
| Liste les nuances (id, nom, description) d'un type donné. |
|
| Détail complet d'une nuance : type, mesures, composition chimique, états métallurgiques, usages, normes. |
Le tool de détail effectue des JOIN pour renvoyer des noms lisibles (ex. « Carbon ») plutôt que des ids bruts, afin que le LLM exploite directement les données.
Les paramètres sont validés par Zod : Claude doit fournir le bon type (un nombre pour un id), sinon l'appel est rejeté avant d'atteindre la base.
ESM : le SDK MCP est distribué en ESM, donc tout le projet est en import/export ("type": "module" dans package.json).
console.error et jamais console.log : sur le transport stdio, la sortie standard (stdout) est réservée au protocole MCP. Tout message de log doit passer par stderr, sinon il corromprait la communication avec Claude Desktop.
Pool à faible limite (connectionLimit: 3) : un MCP branché sur Claude Desktop dessert un seul utilisateur, pas du trafic web.
multipleStatements: false : une seule requête par appel, plus sûr pour un serveur exposé à un LLM.
Requêtes préparées (? + paramètres) : protection contre les injections SQL.
Lecture seule : le serveur n'expose que des SELECT. Un utilisateur MySQL dédié avec le seul droit SELECT est recommandé pour garantir cette limite au niveau de la base.
Identifiants hors du dépôt : ils vivent dans la configuration locale de Claude Desktop, jamais dans le code ni dans un fichier versionné.
Un serveur MCP tourne comme un sous-processus avec les droits de l'utilisateur : n'exposer que le strict nécessaire.
Lecture seule uniquement ; l'écriture via MCP est une piste en cours d'exploration.
Trois tools de consultation ; d'autres pourraient être ajoutés (recherche par nom, filtres croisés, etc.).
Projet local uniquement, non déployé.
Récupère le détail complet d'une nuance d'alliage par son id (composition, mesures, états, usages, normes)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | L'id de la nuance d'alliage à récupérer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool retrieves detailed info, implying a read-only operation, but does not explicitly state behavioral traits such as safety, idempotency, or error conditions. The verb 'récupère' hints at read-only, but more explicit disclosure would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and provides essential details about the output without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return content (composition, mesures, états, usages, normes). The single parameter is documented. However, it lacks mention of error handling, authentication, or any limitations, which would make it more complete for a simple get-by-id operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter 'id' described as 'L'id de la nuance d'alliage à récupérer'. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'récupère' (retrieve), the resource 'détail complet d'une nuance d'alliage', and the key identifier 'par son id'. It lists the included aspects (composition, mesures, états, usages, normes), distinguishing it from sibling tools like get_alloy_nuances (list) and get_alloy_types (types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or contrast with sibling tools (get_alloy_nuances, get_alloy_types).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère la liste des nuances d'alliage (id, nom, description) pour un type d'alliage donné
| Name | Required | Description | Default |
|---|---|---|---|
| id_alloy_type | Yes | id du type d'alliage à filtrer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only states it retrieves a list with id, name, description. It does not mention pagination, ordering, authentication, rate limits, or any side effects. For a read operation this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no superfluous words. Clearly structured with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema), the description is minimally complete. It lacks usage guidelines and behavioral details beyond the basics, but for a simple list retrieval it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the single parameter. The description adds slight reinforcement by mentioning the filter condition, but does not provide meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'récupère' and resource 'liste des nuances d'alliage' with a filter condition. It implicitly distinguishes from siblings like get_alloy_nuance_by_id and get_alloy_types by indicating it returns multiple nuances per alloy type, but no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The sibling tools are listed but no criteria for selection are provided, leaving the agent to infer based on names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère tous les types d'alliage avec leur description.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states that the tool retrieves all alloy types with descriptions, implying a read-only, non-destructive operation. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless retrieval tool, the description is complete. It specifies what is returned (all alloy types with descriptions) and requires no additional context from output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so schema description coverage is 100%. The description adds value beyond the schema by specifying that it retrieves all types with descriptions, which is the baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Récupère' (retrieves) and clearly states the object 'tous les types d'alliage avec leur description' (all alloy types with their description). This distinguishes it from sibling tools like 'get_alloy_nuance_by_id' and 'get_alloy_nuances', which likely focus on specific nuances or nuance lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all alloy types, but does not provide explicit guidance on when to use this tool versus its siblings, nor does it mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0get_alloy_nuance_by_idget_alloy_nuancesget_alloy_typesEach tool targets a distinct resource: alloy types, list of nuances for a type, and detailed nuance by ID. No overlap in purpose.
All tools use consistent 'get_' prefix followed by noun phrases in snake_case, e.g., get_alloy_types, get_alloy_nuances, get_alloy_nuance_by_id.
Three tools is on the low end but still acceptable for a focused read-only query server. The count is appropriate for the narrow scope.
The tool set covers read-only browsing of alloy types and nuances, but lacks write operations (create, update, delete) and more advanced queries. Notable gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Ask questions in plain language, get answers from your business database. No SQL required.
Explore and query your data warehouse through Myriade's AI data analyst agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/p-pouget/mysql-materials-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
