stm32cubemx-mcp

by Wafleem

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct resource and action: creating, listing, inspecting, planning, applying, validating, and generating. The plan/apply split is clear, and inspection vs. validation are unambiguous. No two tools appear to do the same thing.
Naming Consistency4/5
All tools share the cubemx_ prefix and use snake_case. Most follow a verb_noun pattern (create_ioc, list_ioc, plan_ioc_changes), with only 'environment' deviating as a pure noun. This is a minor inconsistency in an otherwise predictable scheme.
Tool Count5/5
With 9 tools, the set is well-scoped for managing STM32CubeMX projects and IOC files. Each tool covers a distinct step in the workflow without redundancy or bloat. The count is appropriate for the domain.
Completeness3/5
The set covers discovery, creation, inspection, validation, change planning/application, and project generation. However, plan_regeneration has no corresponding apply tool, leaving a dead end for regenerating existing projects. Missing delete/remove functionality is a minor gap, but the lack of regeneration application is more significant.
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 29 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. It only mentions 'new output directory' but does not state whether existing contents are overwritten, whether the .ioc file is modified, or what happens if the project already exists.
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 a single sentence, directly stateful and free of fluff. It is appropriately brief, though it could add a little more context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is under-described for its role in a generation workflow. It lacks mention of required inputs (ioc_path), dependencies on prior steps, behavior with existing output directories, and any side effects on the .ioc file. The output schema exists but the description does not integrate it into the overall process.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It gives a hint that output_directory should be a new directory, but ioc_path and project_name are not explained beyond the schema's basic type/constraint information. The nested request object is not clarified either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (generate a project) and the target (STM32CubeIDE), with a qualifier about the output directory. However, it does not mention that it operates on an existing .ioc file, so it could be conflated with creating a .ioc from scratch (cubemx_create_ioc).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like cubemx_create_ioc, cubemx_apply_ioc_changes, or cubemx_plan_regeneration. It does not state prerequisite steps such as having an .ioc file already prepared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does state 'Do not change the source file,' which is useful, but it omits other important behaviors such as whether temporary files are created, whether CubeMX must be installed, and what the output represents. The safety profile is only partially disclosed.
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 very concise, with only two short sentences and no filler. However, the extreme brevity contributes to ambiguity; it earns points for being front-loaded and efficient but loses some for sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has a simple schema and an output schema exists, the description does not provide enough context for an agent to know when to use it or what to expect. The purpose is vague ('load and save'), usage guidance is absent, and parameter semantics are unclear, making it incomplete for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'path' parameter with no description, and schema coverage is 0%. The description mentions 'an IOC copy' but does not clarify whether 'path' refers to the source file to copy or to an existing copy. This ambiguity leaves the parameter's meaning inadequately explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (load and save an IOC copy) and adds a safety constraint ('Do not change the source file'). It distinguishes from siblings by focusing on a copy, but it does not explicitly mention validation, which is the tool's apparent purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the sibling tools (e.g., inspect, plan changes, apply changes). The only usage hint is the safety constraint about not modifying the source file, but no context or alternative comparisons are provided.
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?
With no annotations, the description carries the full burden of disclosing side effects. It mentions creating a backup and replacing the source file, which are key behavioral details. However, it does not elaborate on permanence, reversibility, or any validation behavior, so it is present but not rich.
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 concise with two sentences that each add value: the first states the action, the second describes the mechanism. It is appropriately sized for the limited content, though it could be expanded with more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested input schema, backup process, source file replacement) and the presence of an output schema, the description is incomplete. It does not explain success/failure behavior, backup location, or what 'approved' entails, leaving significant context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the top-level parameter, and the description does not compensate by explaining any parameters. The nested schema fields have some descriptions, but the description itself adds no meaning to the 'request' parameter or its contents. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Apply an approved IOC plan' and describes its primary action of creating a backup and replacing the source file. This provides a specific verb and resource, though it does not explicitly distinguish itself from sibling tools like cubemx_plan_ioc_changes or cubemx_validate_ioc.
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 indicates the tool should be used to apply an approved plan, implying it follows the planning step. It provides clear context for when to use it (with an approved plan) but does not explicitly state when not to use it or mention alternatives, fitting the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'create and validate' and 'new directory', but gives no detail on validation semantics, side effects (e.g., overwriting, directory creation behavior), error handling, or required environment setup. The description provides minimal insight beyond the tool's name, leaving significant behavioral ambiguity.
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 a single sentence with no wasted words. It front-loads the action ('Create and validate') and follows with the resource and location. Every word adds meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no annotations, the description is too brief to be complete. It does not mention dependencies (e.g., cubemx_environment), validation behavior, potential errors, or idempotency. Although an output schema exists, it is not shown here, and the description still lacks the behavioral context needed to use the tool confidently. The tool has multiple parameters and side effects, but the description covers only a fraction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does add some meaning by indicating 'board or microcontroller' (relevant to target_kind and target) and 'in a new directory' (relevant to output_directory), but it leaves out project_name, toolchain, and board_mode. These parameters are not explained in the description or fully in the schema, leaving gaps in how to correctly populate the request.
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's function: create and validate one IOC file for a board or microcontroller, placed in a new directory. This differentiates it from sibling tools like cubemx_list_ioc, cubemx_inspect_ioc, and cubemx_apply_ioc_changes, which handle different actions. The verb+resource+scope is specific and unambiguous.
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 implies use for creating a new IOC file, but it doesn't explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. There is no mention of prerequisites or exclusion criteria. The context of sibling tools provides some guidance, but the description itself lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Discover...' which implies a non-destructive read operation. It does not specify what exact runtime state is checked, whether it validates versions/paths, or what the output contains. The phrase 'related runtime state' is vague and doesn't clarify side effects or assumptions.
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 a single, concise sentence with no redundant or vague filler. Every word contributes to the meaning, and it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool with no parameters and an output schema, the description is mostly sufficient but leaves 'related runtime state' ambiguous. It could be clearer about whether it checks versions, installation paths, environment variables, or toolchain dependencies. The output schema may compensate, but it's not visible here.
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?
The tool has zero parameters, so the schema is empty and the baseline is 4. The description adds useful tool-level context by naming the discovery targets (STM32CubeMX, STM32CubeIDE, CMake), which helps the agent understand the tool's scope even though no parameters exist.
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 uses the specific verb 'Discover' with a clear resource (local STM32CubeMX, STM32CubeIDE, CMake, and related runtime state). It clearly distinguishes itself from sibling tools that create, inspect, plan, or apply changes to .ioc files and generated projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any context about prerequisites or whether to run it before other actions. There is no mention of when-not-to-use or recommended workflow placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The verb 'inspect' implies read-only operation, but the description does not explicitly state that the file is not modified, nor does it mention behavior on invalid paths or permission requirements. It focuses on return data rather than the operational semantics, which is a significant gap given the lack of 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 a single sentence that immediately states the verb and object. It is free of filler and communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, so the description does not need to detail return values. However, without annotations and explicit usage guidance, the description is only partially complete for an agent deciding between this and sibling tools. It provides basic purpose but lacks behavioral and selection context.
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 schema has only one parameter 'path' with no description (0% coverage). The description's 'Inspect one IOC file' implies that 'path' identifies the file to inspect, adding some meaning. However, it does not explicitly describe the parameter's format, requirements (e.g., absolute vs. relative path), or constraints, leaving the agent to infer the connection.
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 uses a specific verb 'Inspect' with a specific resource 'one IOC file' and lists the data categories returned (project, microcontroller, pin, clock). This clearly distinguishes it from sibling tools like 'list' (enumerates files) and 'validate' (checks correctness).
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?
Usage context is implied through the phrase 'Inspect one IOC file', but there is no explicit guidance on when to use this tool versus alternatives such as 'list' or 'validate'. No exclusions or alternative mentions are provided, so the agent must infer usage from the name and description.
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?
With no annotations, the description carries the full disclosure burden. It explicitly states 'without modifying them', which reveals the non-destructive safety profile—a critical behavioral trait. It also hints at an access boundary ('allowed project directory'), adding context beyond the schema.
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?
A single, front-loaded sentence conveys the core purpose and a safety qualifier with zero redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation, especially with an output schema present, but it lacks critical parameter semantics and usage guidelines. The claimed output schema means return values need not be described, yet the missing context on limit/recursive and sibling differentiation leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only implies the 'root' parameter via 'below an allowed project directory'. The 'limit' and 'recursive' parameters are entirely unexplained in both schema and description, leaving their semantics unclear.
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 action ('List'), the target ('IOC files'), the scope ('below an allowed project directory'), and a key behavioral constraint ('without modifying them'). This strongly distinguishes it from sibling tools like create, inspect, or apply, which imply different operations.
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?
Usage context is implied: it lists IOC files before other operations. However, there is no explicit guidance on when to choose this over siblings like cubemx_inspect_ioc or cubemx_plan_ioc_changes, nor any mention of exclusions.
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?
With no annotations provided, the description carries the full burden. It discloses that the operation creates a temporary copy (implying the original is untouched) and that the returned plan is read-only. This gives essential safety context beyond a bare 'plan regeneration' statement, though it does not mention cleanup or side effects.
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?
Two short sentences with no filler. The key actions—regenerating a temporary copy and returning a read-only plan—are front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return value details are covered elsewhere. However, the lack of parameter semantics and weak usage guidance leave noticeable gaps for a tool with one required parameter and an optional one. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters at all. It fails to explain that project_directory is required or what ioc_path is for. The description adds no meaning beyond the raw schema fields, leaving the agent to guess parameter purposes.
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 regenerates a temporary project copy and returns a read-only file change plan. This specific verb+resource pairing distinguishes it from siblings like cubemx_apply_ioc_changes (which applies changes) and cubemx_generate_project (which generates the project outright).
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 implies a planning/preview use case (temporary copy, read-only plan) but does not explicitly mention when to use it versus alternatives like cubemx_plan_ioc_changes or cubemx_generate_project. No exclusions or alternative tool names are given, leaving the choice somewhat implicit.
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?
With no annotations present, the description carries the full burden of behavioral disclosure. It clearly states 'Do not write a file,' which is a key non-mutating behavior that an agent must know. However, it does not mention other behaviors such as whether an existing .ioc file is required or the nature of the plan output, so it is not fully transparent.
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 two short sentences, front-loaded with the verb and resource scope, followed by the crucial safety note. Every word contributes meaning, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and non-writing behavior, and an output schema exists to document return values. However, it does not differentiate from the sibling cubemx_plan_regeneration tool or mention prerequisites like an existing .ioc file, leaving gaps for a tool with such a rich request schema.
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 description lists the categories of changes ('pin, peripheral, parameter, and project changes'), which map meaningfully to the request fields (pin_assignments, parameter_updates, enabled_peripherals, project_name/toolchain). This adds value beyond the schema, which lacks descriptions for the top-level request property. However, it does not detail individual parameters, and the schema's nested descriptions are sparse.
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 uses a specific verb ('Plan') and names the resources ('pin, peripheral, parameter, and project changes'). The explicit note 'Do not write a file' distinguishes it from sibling tools that create, apply, or generate, making the purpose clear.
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 phrase 'Do not write a file' implies usage for planning before applying changes, but it does not explicitly state when to use this tool over alternatives like cubemx_apply_ioc_changes or cubemx_plan_regeneration. There is no direct mention of alternatives, making the guidance only implied.
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:

[![stm32cubemx_mcp MCP server](https://glama.ai/mcp/servers/Wafleem/stm32cubemx_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Wafleem/stm32cubemx_mcp)

Score Badge

Copy to your README.md:

[![stm32cubemx_mcp MCP server](https://glama.ai/mcp/servers/Wafleem/stm32cubemx_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Wafleem/stm32cubemx_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/Wafleem/stm32cubemx_mcp'

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