Reads the GIC interrupt controller in STM32CubeMX projects, returning interrupt lists, per-IP interrupts, enable states, and triggering modes for STM32MP1/MP2 configuration checks.
Read the GIC interrupt controller (STM32MP1/MP2) through CubeMX: interrupt list, per-IP interrupts, enable state and triggering mode.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | GIC query | |
| target | No | IRQ name / index or IP name | |
| project_id | Yes | Project id |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It communicates that operations are reads and names the four result categories, which is useful, but it does not state whether a project must be open first, what the response shape is, or how an invalid target is handled.
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?
A single front-loaded sentence with no filler; the verb and resource lead. The trailing enumeration is dense but every clause maps to a real action value.
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 tool with no annotations and no output schema, the description covers what can be queried but omits return format, precondition on project state, and target semantics. Adequate to select the tool, thin for invoking it precisely.
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%, so the schema already documents project_id, action enum values, and target. The description adds a little context by mapping the query categories to the action enum and implying target is an IRQ/IP name, but adds no syntax or format detail beyond the schema.
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?
States a specific verb ("Read") and resource (GIC interrupt controller for STM32MP1/MP2) and enumerates the four retrievable data sets, which lets an agent distinguish it from the write-side sibling gic_mutate. It does not explicitly name gic_mutate or nvic_read, so differentiation is implicit rather than stated.
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 verb "Read" and the four query modes imply read-only usage versus gic_mutate, but the description never states when to choose this tool over gic_mutate or nvic_read. No prerequisites (e.g. project must be open) or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.