mne_plot_sensorsGenerate a PNG image of sensor/electrode positions as a 2D topomap or 3D layout, helping verify channel placement in neurophysiology data.
Plot the sensor/electrode layout (kind='topomap' 2D or '3d'). Returns a PNG path.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | topomap | |
| name | No | raw | |
| show_names | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose an important output behavior by stating 'Returns a PNG path' and lists the two layout kinds. However, it does not mention whether the tool modifies session state, writes a file to disk, requires existing data, or behaves differently between the 2D and 3D modes.
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 remarkably concise: one sentence for the core action and modes, plus one sentence for the return format. Every word earns its place, and the most identifying information is front-loaded.
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 three parameters, no annotations, and no schema-level parameter descriptions, the description is incomplete. An agent would not know what 'name' refers to, whether a raw object must already be loaded, or how the returned PNG path should be used. The presence of an output schema does not compensate for missing parameter semantics and usage context.
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 description coverage is 0%, so the description must compensate for all three parameters. It gives partial meaning for 'kind' ('topomap' 2D or '3d'), but it does not explain 'name' or 'show_names' at all, even though defaults and no enums leave important ambiguity.
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 a specific action ('Plot') and resource ('sensor/electrode layout'), and distinguishes the two display modes ('topomap' 2D or '3d'). It is understandable on its own, though it does not explicitly differentiate itself from the sibling mne_plot_topomap, which could be confused for a similar plotting tool.
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 about when to use this tool versus alternatives such as mne_plot_topomap, mne_plot_evoked, or mne_plot_raw. There is no mention of prerequisites, session/data requirements, or conditions that would make this tool the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.