MNE-MCP

by Exekiel179

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.1.0
Disambiguation5/5
Each tool targets a distinct stage in the MNE pipeline, from data loading (mne_load_raw) to preprocessing (mne_filter, mne_set_montage) to analysis and plotting (mne_fit_ica, mne_plot_evoked). Even the many plot_* tools are differentiated by the object type and visualization style, with descriptions clearly specifying inputs and outputs, so an agent can reliably select the correct tool.
Naming Consistency4/5
All tools share the consistent mne_ prefix and most use a verb_noun pattern (e.g., mne_plot_psd, mne_load_raw, mne_set_reference). A few exceptions like mne_connectivity, mne_tfr_morlet, and mne_events_from_annotations break from this pattern, but they remain readable and clearly tied to their function, so the overall convention is still predictable.
Tool Count2/5
With 39 tools, the server is heavily over-scoped, well beyond the typical 3-15 well-chosen tools. Many plot_* tools could be consolidated into a single parameterized plot tool, and the overlapping info tools (mne_get_info, mne_describe, mne_session_info) add redundancy. The presence of mne_run_code as a catch-all further reduces the need for such a large structured surface.
Completeness5/5
The tool set covers the full EEG/MEG analysis workflow end-to-end: load, preprocess, filter, epoch, average, visualize, compute connectivity/decoding, and perform source localization, with a save tool for output. It also includes backend installation, configuration, and session inspection, ensuring no dead ends. mne_run_code fills any remaining niche operations, making the surface effectively complete.
Average 3.9/5 across 39 of 39 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on June 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
No annotations are provided, so the description carries the full burden. It discloses the method and prerequisite but omits critical behaviors such as whether the operation mutates data in-place, the effect of the 'reset_bads' parameter, and whether the operation is reversible. This is a significant gap for a data-altering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler. However, it is under-specified given the tool's parameters and dependencies, so while concise, it lacks necessary detail for effective use.
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 has moderate complexity with 2 parameters and a prerequisite (montage), but the description provides no workflow context with sibling tools (e.g., marking bad channels first), no mention of data types or return values, and the output schema is not described. The description is not complete enough for safe autonomous use.
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?
The schema has 2 parameters with 0% description coverage, and the description does not mention either parameter. The agent must infer that 'name' refers to the data object and 'reset_bads' controls bad channel clearing. The description completely fails to compensate for the schema gap.
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 'Interpolate' with a clear resource 'currently-marked bad channels' and method 'spherical splines'. This clearly distinguishes it from siblings like mne_mark_bad_channels (which marks bads) and mne_set_montage (which sets montage).
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 mentions a prerequisite ('requires a montage'), which gives some usage context, but it does not explicitly state when to use this tool versus alternatives or provide a workflow (e.g., mark bads first, then set montage). No exclusions or alternatives are named.
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?
The description discloses the return value (PNG path) and accepted input types (Raw/Epochs/Evoked), which is valuable. However, with no annotations, it lacks details on whether the operation is read-only, whether the PNG file is persisted, or any potential 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?
The description is a single, efficient sentence that front-loads the core purpose and return type. Every word earns its place with no fluff or repetition.
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 tool with four optional parameters and no annotations, the description is too sparse to support correct invocation. It leaves ambiguous what 'name' refers to and how 'picks' should be specified, though the output schema partially compensates for understanding the return value.
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?
The schema has 0% description coverage, and the description does not explain any of the four parameters (fmax, fmin, name, picks). The agent is left to infer meaning from parameter names and defaults, which is inadequate for reliable invocation.
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 plots the power spectral density of Raw/Epochs/Evoked objects and returns a PNG path. This specific verb and resource distinguish it from sibling plotting tools like mne_plot_raw or mne_plot_evoked.
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 the many alternative plot tools. It does not mention any prerequisites, exclusions, or scenarios where another plotting tool would be more appropriate.
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 provided, the description carries the full burden of behavioral disclosure. It does state that the tool 'Returns a PNG path', which is a useful behavioral detail about the output format. However, it does not disclose potential side effects (e.g., file creation location), performance implications, or how the raw object might be affected, though as a plotting tool it is likely non-mutating.
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, front-loaded sentence that clearly states the action and the return value. There is no verbiage, and every word contributes to understanding the tool's core purpose.
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 there are four parameters with zero schema descriptions and no annotations, the description should provide more context about how to customize the plot. It only says 'a window of channels over time' and mentions the PNG path, but leaves the parameter semantics completely unexplained. The output schema may exist, but the description's lack of parameter detail makes the tool difficult to invoke correctly without additional knowledge.
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%, and the description does not mention any of the four parameters (name, start, duration, n_channels). The phrase 'window of channels over time' vaguely hints at start/duration/n_channels, but it does not explain their meanings, defaults, or how they interact. The description fails to compensate for the lack of schema documentation.
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 opens with 'Plot raw signal traces', providing a specific verb and resource. It further clarifies the tool's scope with '(a window of channels over time)' and distinguishes it from sibling plotting tools like mne_plot_psd or mne_plot_sensors.
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 other plotting tools in the sibling list. It does not mention alternatives, prerequisites, or typical use cases beyond the basic action of plotting raw traces.
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 carries the full burden. It only states the conversion function, omitting side effects, safety, prerequisites (e.g., raw must have annotations), or whether the input is mutated. This is a significant gap for a tool with zero annotation coverage.
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, well-structured sentence with a clear subject-action-object pattern. It conveys the core purpose without any wasted words, achieving high conciseness.
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?
While the tool is simple and an output schema exists, the description leaves out essential context such as parameter meanings, prerequisites (annotations must be present), and differentiation from mne_find_events. This makes it incomplete for an agent to use correctly without additional inference.
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%, and the description does not mention raw_name or events_name at all. The description completely fails to compensate for the lack of parameter documentation, leaving the agent guessing about the purpose and usage of these optional parameters.
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 specific verb 'Convert' with the resource 'Raw object's annotations' and the outputs 'events array + event_id map'. It also mentions the intended data formats (EDF/BrainVision/EEGLAB), which distinguishes it from sibling tool mne_find_events that likely extracts events from triggers.
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 gives clear context by specifying applicable data types (EDF/BrainVision/EEGLAB), implying when to use it. However, it does not explicitly compare with mne_find_events or state when not to use it, so it stops short of a full guideline with exclusions.
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 discloses that it plots and returns PNG paths, indicating a read-only, file-producing operation. However, it does not mention display behavior, backend requirements, or whether it modifies the Epochs object, leaving some 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?
A single sentence with no wasted words. It front-loads the core purpose and includes the return type, making it highly efficient.
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 output schema covers return values, so that part is accounted for. But the tool is underspecified for invocation: parameter semantics are missing, usage guidance is thin, and no annotation context compensates. An agent would struggle to use it correctly.
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% and the description mentions neither 'picks' nor 'name'. The property names give a weak hint, but no actual semantics are provided, so an agent cannot know what values to pass.
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 ('Plot'), the specific resource ('an ERP image (epochs × time heatmap) for an Epochs object'), and the output ('Returns PNG path(s)'). This distinguishes it from sibling plotting tools like mne_plot_evoked or mne_plot_psd.
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 it should be used on an Epochs object, but provides no explicit alternative handling or when-to-use versus other plotting tools. It gives a prerequisite but no exclusions or comparisons.
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. It discloses a key behavioral detail: the tool returns a PNG path. It also hints at the kind parameter options. However, it does not mention side effects, temporary file creation, or whether it requires a specific backend. This is minimal but not misleading.
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 succinct sentences with front-loaded purpose. It avoids redundancy, clearly states the return value, and earns every word. 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?
Although an output schema exists, the description remains incomplete for a 3-parameter tool with no annotations. It omits semantics for 'name' and 'show_names', does not give exact valid values for 'kind', and fails to contextualize usage among many sibling tools. These gaps could prevent correct 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?
Schema description coverage is 0%, so the description must compensate. It only partially explains 'kind' via the parenthetical, but leaves 'name' and 'show_names' completely undefined. The agent cannot infer what 'name' refers to (likely a data variable in the session) or what 'show_names' controls, making parameter usage ambiguous.
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 with the specific verb 'Plot' and resource 'sensor/electrode layout', distinguishing it from sibling tools like mne_plot_raw or mne_plot_topomap. The parenthetical mentioning kind='topomap' 2D or '3d' adds scope. This is a clear, non-tautological 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?
The description provides no guidance on when to use this tool versus alternatives such as mne_plot_topomap or mne_plot_raw. It does not mention prerequisites (e.g., loaded data with sensor positions) or contrast with other plotting tools, leaving usage entirely inferred from the verb and resource.
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 full burden for behavioral disclosure. It mentions the return output and dependency, but does not state whether it modifies existing data, how it references epochs (via epochs_name), or any side effects. The default parameters like epochs_name suggest it operates on existing session objects, but this is not explicitly disclosed, leaving the agent guessing about invocation context.
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 and front-loaded, with the purpose in the first sentence. It lists methods, return value, and dependency in a structured way. Every sentence contributes useful information, though it could be slightly more organized.
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 has 5 optional parameters and no schema descriptions, the description is incomplete. It fails to explain key parameters like con_name and epochs_name, and does not clarify how the epochs object is accessed or whether the tool is read-only. The output schema exists but is not described in the text, so the agent lacks enough context to invoke this tool correctly without additional assumptions.
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 must explain parameters. It lists method options, which helps, and implies fmin/fmax as the frequency band, but it does not explain con_name or epochs_name at all. These are left undefined, making it hard to know what values to provide. The description adds minimal value beyond the schema's defaults.
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 computes spectral connectivity between channels over Epochs in a frequency band, listing specific methods. This is a specific verb+resource that distinguishes it from all sibling MNE tools, none of which perform connectivity analysis.
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 implies usage: when you have Epochs and want connectivity in a frequency band. It gives clear context by specifying the method options and return format, but does not explicitly exclude alternatives or mention when not to use it. No alternative tools are named, but the intended scenario is clear.
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 burden. It discloses an important behavioral trait ('in place') and the default exclude-list behavior. However, it does not mention required preconditions (e.g., fitted ICA object) or what happens to the input instrument, leaving gaps in transparency.
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 sentences, front-loaded with the core purpose, and includes a concise parameter explanation. Every word contributes, with no redundancy or unnecessary detail.
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 a mutation with no annotations and minimal schema info. The description explains the exclude parameter but leaves out essential context about how to specify the ICA and instrument objects, and doesn't clarify the expected pipeline state (e.g., ICA must be fitted). Incomplete for a 3-parameter tool.
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 coverage is 0%, so the description must compensate. It explains the 'exclude' parameter well, but completely omits 'ica_name' and 'inst_name', leaving two of three parameters undocumented. This is a significant gap for a tool with no schema descriptions.
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 a specific action ('Remove') and resource ('ICA components from an instrument'), and 'in place' signals mutation. This distinguishes it from sibling tools like mne_fit_ica (fitting) and mne_plot_ica_sources (plotting).
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 usage after ICA fitting by focusing on component removal, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites. The exclude parameter guidance is useful but does not substitute for direct usage context.
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 provided, the description carries the full burden of behavioral disclosure. It contributes the important fact that resampling happens 'in place,' implying mutation rather than returning a new object. However, it does not mention side effects, prerequisites, or whether Raw and Epochs objects are handled identically, leaving gaps.
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, front-loaded sentence with no redundant words. Every phrase adds value: the object type, the target frequency, and the in-place behavior. It is a model of concise, scannable tool documentation.
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 no annotations, 0% parameter coverage, and a two-parameter tool, the one-sentence description leaves critical context unexplained: the meaning and usage of the 'name' parameter, any constraints on 'sfreq' (e.g., must be <= original rate), and what 'in place' means for return values. While an output schema may exist, it does not compensate for the ambiguity around selecting the target object.
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 must compensate. It clarifies that 'sfreq' is the new sampling frequency in Hz, but it never explains the 'name' parameter, which is likely the session identifier for the object to resample (defaulting to 'raw'). This incomplete parameter explanation makes correct invocation harder for an agent.
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 'Resample' and clearly identifies the resource ('a Raw/Epochs object') and the action's target ('a new sampling frequency (Hz)'). This distinguishes it from sibling tools like mne_filter and mne_crop, and the addition of 'in place' further clarifies the operation's nature.
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 the tool is used when a different sampling rate is needed for a Raw or Epochs object, but it provides no explicit guidance on when to use this versus alternatives or any exclusions. The context is clear enough to infer usage, but it does not meet the bar for explicit usage framing.
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?
No annotations are provided, so the description must disclose behavior. 'Show' indicates a read-only operation, and it specifies the output as 'full channel list and measurement info.' However, it does not mention prerequisites (e.g., a loaded session), side effects, or error conditions. The output schema covers return structure, so this is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the verb, and contains no redundant information. Every word earns its place.
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?
For a simple one-parameter read tool with an output schema, the description covers what it does and what the parameter refers to. It doesn't need to explain return values due to the output schema. It could mention session prerequisites, but 'for a named session object' adequately implies an existing object. Overall, it is complete for the tool's simplicity.
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 'name' parameter is only described as 'a named session object' in the description. This gives semantic meaning (identifies the session), but it doesn't elaborate on the naming format or how to obtain the session name. Schema coverage is 0%, so the description partially compensates but not fully.
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 'Show' with a specific resource: 'the full channel list and measurement info'. It scopes to 'a named session object,' which distinguishes it from sibling tools like mne_session_info and mne_check_status. However, it doesn't explicitly compare with alternatives, so it's not a 5.
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?
There is no explicit when-to-use or when-not-to-use guidance. The purpose is clear enough that a user can infer to use it when needing channel list or measurement info, but no alternatives or exclusions are mentioned. This is implied usage, not explicit guidance.
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 provided, the description carries the full burden. It discloses the action (plot) and the output (PNG path), but does not detail any required state (e.g., ICA must be fitted), whether it saves files, or how multiple components are rendered. This leaves some 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 concise sentence that conveys the core purpose, accepted input type, and output. No extraneous words or repetition, making it fully front-loaded and efficient.
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 relatively simple and the output schema covers the return value, but the description is missing parameter explanations and usage context. It is adequate for a straightforward plotting tool but leaves some gaps for an agent unfamiliar with MNE conventions.
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 must explain the parameters. It only partially addresses inst_name by mentioning 'raw/epochs', but ica_name is not described at all. The defaults and names give some hint, but the description adds minimal value.
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 plots ICA component time courses for raw or epochs, and explicitly notes it returns a PNG path. This verb+resource+output combination distinguishes it from the sibling mne_plot_ica_components, which likely plots topographies.
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 usage is implied by the purpose: one would use this tool to visualize ICA component time courses. However, there is no explicit mention of when to choose this over the sibling mne_plot_ica_components, nor any prerequisites like needing a fitted ICA.
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 burden of behavioral disclosure. It mentions 'Stores the source estimate (stc)' and 'reports the peak activation time,' which are useful, but it does not disclose side effects like overwriting existing variables, required session state, or failure conditions.
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 three concise sentences with no filler. It front-loads the purpose, then method options and side effects, making it easy to scan.
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 complex, and the output schema exists but the description lacks full context. It does not explain parameter semantics, preconditions (e.g., that fwd and noise_cov must exist), or state changes beyond storing stc. The pipeline hint helps but is insufficient for a tool with no annotations and 0% schema coverage.
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 must compensate. It explains the 'method' parameter with options, but leaves snr, cov_name, fwd_name, stc_name, and evoked_name undefined. These names are partially self-explanatory, but the description does not confirm their roles.
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: 'Estimate cortical sources from an Evoked using a forward model and noise covariance.' It specifies the resource (cortical sources from an Evoked) and the method options, distinguishing it from sibling tools like mne_make_forward and mne_compute_noise_cov.
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 gives explicit pipeline guidance with 'Pair with mne_make_forward + mne_compute_noise_cov.' This indicates prerequisites and intended usage context, though it does not explicitly name alternatives or exclusion scenarios.
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?
The description discloses that the operation is performed 'in place,' which is a key behavioral trait. However, it does not mention return values, side effects on the object, error conditions, or the meaning of default values.
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 entire description is a single, focused sentence without redundant information.
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 tool, the description covers the core action and important in-place behavior. However, it lacks alternatives context and parameter details, making it somewhat incomplete.
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 defines the time window [tmin, tmax] in seconds, which clarifies the two time parameters. However, the 'name' parameter is unexplained, and the description does not compensate for the complete lack of schema-level parameter descriptions.
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 a specific action ('Crop') on specific resource types ('Raw/Epochs/Evoked object') with the time window scope, distinguishing it from siblings like filtering or resampling.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The intended use is implied by the action, but no guidance is provided for selection.
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 provided, the description must carry the full burden of behavioral disclosure. It explains that the tool finds events and stores them under events_name, which is a core behavioral trait. However, it does not disclose prerequisites (e.g., that the Raw object must already be loaded in the session), whether the Raw object is modified, or what happens if no events are found. This partial transparency warrants a mid-range score.
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 concise sentences that are front-loaded with the primary action and resource. Every word contributes to understanding the tool's purpose and output storage, with no unnecessary filler or repetition.
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?
Given that an output schema exists, return values are likely documented, so the description can focus on other context. However, it omits important prerequisites such as the requirement that the Raw object must be loaded or that stim_channel may be auto-detected if not specified. While the tool is relatively simple, these missing contextual details prevent a higher score.
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 no parameter descriptions (0% coverage), so the description must compensate. It does provide context for events_name ('Stores them under events_name') and stim_channel ('on a stim channel'), but it does not explain raw_name, which is left ambiguous. Since it partially clarifies the parameters but not fully, a score 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 the tool's purpose: to find stimulus/trigger events on a stim channel of a Raw object. It uses a specific verb ('find') and resource ('stim channel'), and the mention of 'stim channel' differentiates it from the sibling tool mne_events_from_annotations, which deals with annotations rather than stim channels.
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 when to use this tool (for finding events on a stim channel), but it provides no explicit guidance on alternatives or exclusions. For example, it does not mention that mne_events_from_annotations should be used when events are in annotations rather than a stim channel. Thus, the usage context is only implied, not explicitly stated.
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 provided, the description carries the full burden. It discloses key behavioral traits: appending to existing bads by default and the replace option to overwrite, plus the comma-separated input format. However, it does not explain side effects (e.g., whether the raw object is modified in place), error conditions, or the purpose of the 'name' parameter.
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 sentences, front-loaded with the action, and every word adds value. The example format and the append/replace distinction are efficiently communicated with no redundancy.
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 utility with an output schema, the description covers the core action and the main behavioral nuance. However, it misses context around the 'name' parameter, prerequisites (e.g., loaded raw object), and return behavior, leaving some gaps for a tool with no 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'bads' (comma-separated names, example) and 'replace' (append vs. overwrite), but it does not clarify the 'name' parameter, which remains undocumented in both the schema and description. Partial compensation.
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: "Mark channels as bad" with an example format. This is a specific verb+resource (mark channels), and the sibling list shows this is distinct from other MNE tools like mne_interpolate_bads or mne_plot_raw.
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 provides clear operational context (append vs. replace behavior) but does not explicitly state when to use this tool versus alternatives or mention exclusions. The usage is implied by the name and description, but there is no direct alternative comparison.
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. It explains accepted reference formats but does not mention that setting a reference modifies the raw data in place, any prerequisites, or side effects. This is a significant gap for a mutation tool.
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 sentences: first states the action, second provides concrete value options with an example. No filler or repetition of schema defaults.
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 an output schema exists, so return values are covered. However, without annotations, the description does not state that this mutates the raw object, and it omits the name parameter entirely. The combination of schema plus description is adequate but leaves notable gaps for a new agent.
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 provides meaningful guidance for the ref_channels parameter (average, REST, or channel list), which the schema simply types as string. However, the name parameter is completely unmentioned, and with 0% schema coverage the description should compensate for both parameters.
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 opens with a specific verb+resource ('Set the EEG reference') and immediately distinguishes the tool from siblings by listing acceptable references. No sibling tool targets reference setting, so the purpose is unambiguous.
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 context for when to use the tool: whenever the user needs to set the EEG reference. It does not explicitly mention alternatives or exclusions, but the specific action and reference options make the use case evident.
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 burden. It discloses the return value (PNG path), which is useful, and indicates the default style. However, it does not address side effects such as file creation, data immutability, or whether plots are displayed interactively.
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 that immediately convey the tool's purpose and key parameter. No filler or redundant information.
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?
For a simple plotting tool, the description is mostly complete: it specifies return type and style options. The missing explanation of the 'name' parameter and lack of usage context slightly reduce completeness, but the tool is straightforward.
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 no descriptions for parameters, and the description compensates for 'style' by explaining valid values and default. However, the 'name' parameter is not explained, leaving ambiguity about its purpose.
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 plots an Evoked response, with a specific verb ('Plot') and resource ('Evoked response'). It also lists three style options, distinguishing it from sibling plotting tools like mne_plot_raw or mne_plot_topomap.
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 usage for plotting Evoked data and provides style selection guidance, but does not explicitly state when to prefer this over alternative tools like mne_plot_topomap or mne_plot_epochs_image. No exclusions or use cases are given.
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 provided, the description carries the full burden of behavioral disclosure. It states that the tool 'Returns PNG path(s)', which reveals the output type, but it does not disclose any side effects, prerequisites (e.g., requiring a fitted ICA object), or whether the operation is read-only. For a plotting tool, this is minimal but not complete disclosure.
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 extremely concise, consisting of two short clauses that state the action and output. It is front-loaded with the verb 'Plot', contains no redundant or filler text, and 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?
Given the tool's simplicity—one optional parameter and an output schema—the description provides adequate context for what it does and returns. However, the complete omission of the parameter from the description leaves a clear gap, especially with zero schema coverage. The description is not fully complete for an agent to invoke the tool correctly without additional inference.
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 does not mention the single parameter ica_name at all. While the parameter name is mildly self-explanatory, the description adds no meaning about what the ICA name refers to or how it should be specified. The description fails to compensate for the lack of schema documentation.
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 plots ICA component scalp topographies, with the stated purpose of identifying eye/heart/muscle artifacts. It uses a specific verb and resource, and differentiates from the sibling tool mne_plot_ica_sources by specifying 'scalp topographies', which implies the alternative plots time-series sources.
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 context for when to use the tool: after ICA fitting, to identify artifacts via topographic maps. However, it does not explicitly mention alternatives or situations when this tool should not be used, such as when time-series inspection is needed (for which mne_plot_ica_sources would be appropriate).
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 behavioral disclosure. It does reveal disk-writing behavior and naming rules, but it fails to mention overwrite semantics (especially since 'overwrite' defaults to true) or potential errors from unsupported .save() formats. This is a moderate level of transparency.
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 three sentences, front-loaded with the core action, and contains no filler. Each sentence contributes meaningful information: the action, the naming conventions, and the fallback behavior.
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 save tool with an output schema, the description is reasonably complete but leaves gaps around parameter meanings and overwrite/error behavior. The naming rules add useful context, yet the overall picture is not fully self-contained.
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 does not explicitly define 'name', 'path', or 'overwrite'. The MNE naming rules give indirect hints about how file names are derived, but they do not clarify the required path construction or the effect of the overwrite flag, leaving significant ambiguity.
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 saves a session object to disk and gives specific MNE naming conventions. This distinguishes it from sibling tools, which are primarily analysis/plotting operations, making the purpose unmistakable.
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 contextual guidance by explaining the expected file naming patterns for different session object types, which helps the agent know how to invoke the tool correctly. It does not explicitly mention alternatives or when not to use it, but no sibling tool serves the same save purpose.
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 discloses some behavioral traits: results are stored under tfr_name and a PNG path is returned. Yet it does not mention whether existing TFR objects are overwritten, session state changes, or any other side effects, leaving room for 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 two sentences long, front-loaded with the main purpose, and every clause provides useful information without redundancy.
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 complex time-frequency analysis tool, the description lacks important context: it does not mention that epochs must already exist, that the TFR result is added to the session, or details about the plot. While an output schema exists, the absence of these operational details makes the tool harder to use safely.
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 0% description coverage, so the description must compensate. It explains fmin/fmax, n_freqs, and tfr_name, but completely omits epochs_name, leaving part of the parameter list undocumented.
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 computes Morlet-wavelet time-frequency power on Epochs and plots it. It uses a specific verb and resource, distinguishing it from sibling tools like mne_plot_psd or mne_make_epochs.
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?
It clearly indicates the tool operates on Epochs data, providing context for when to use it. However, it does not explicitly mention alternatives or exclusion cases, so it misses the top score.
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?
No annotations are provided, so the description carries the burden. It clarifies the computation uses baseline data up to tmax seconds (default 0), which is useful behavioral detail. However, it doesn't disclose return behavior, whether input is modified, or any error conditions, leaving some transparency gaps.
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 sentences with no redundancy. The first states what it does, the second gives pipeline context. Every word earns its place.
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 tool is simple (3 optional params) and has an output schema, so return values don't need explanation. The description gives the essential purpose, context, and tmax behavior. The only omission is explicit semantics for name and cov_name, but defaults and output schema partially cover this, making it adequately complete for a typical user.
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 only explains tmax ('data up to tmax seconds, default 0'). It does not explain what 'name' (the epochs object) or 'cov_name' (the output variable) mean, despite these being key parameters. The description adds some meaning for one of three params but not enough to compensate for the lack of schema descriptions.
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 ('Compute') and identifies the resource ('noise covariance matrix from the Epochs baseline'), clearly distinguishing it from sibling tools like mne_make_forward or mne_apply_inverse. It leaves no ambiguity about the tool's function.
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?
It states when this is needed ('before building an inverse operator for source localization'), situating it within the analysis pipeline. It doesn't mention explicit alternatives or when not to use it, but the contextual cue is strong.
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 full burden. It discloses that the tool sets channel positions and mentions the default montage behavior via config. However, it does not explicitly state that the operation overwrites existing montage positions or whether the 'raw' object is modified in place, which are relevant behavioral traits for a mutation tool.
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 three sentences, front-loaded with the core action, and includes useful examples without fluff. Every sentence adds value: action, use case, and default behavior.
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 tool is simple (2 params, no required params) and has an output schema, so the description need not detail return values. It provides the essential context (when needed, default behavior). However, the missing semantics for the 'name' parameter and lack of mention of side effects leave minor 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?
Schema description coverage is 0%, so the description must compensate. It explains the 'montage' parameter with examples and the default behavior, but it does not explain the 'name' parameter (default 'raw'), leaving its meaning ambiguous (likely a reference to the data object in the session). This leaves one of two parameters semantically undocumented.
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 a specific action: 'Apply a standard electrode montage' and specifies the resource ('channel positions'). It also provides concrete examples of montages and distinguishes itself from sibling tools by mentioning its role in topographic plots and interpolation, which is unique among the siblings.
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 explicitly states 'Needed before topographic plots and interpolation', giving clear context for when to use this tool. However, it does not mention when not to use it or alternative tools, so it stops short of a perfect 5.
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. It discloses that the tool aggregates data, is condition-selectable, and stores the result under evoked_name. However, it does not mention potential side effects like overwriting an existing evoked object, prerequisites (e.g., loaded epochs), or failure modes.
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 concise sentences front-load the primary purpose and then provide the most important parameter behavior. Every word earns its place; no fluff or repetition of the schema.
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 is reasonably complete for a straightforward averaging operation, especially given an output schema exists. It covers the core action, condition handling, and storage location. Missing details like overwrite behavior are not critical for basic use but would improve completeness.
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 0%, so the description must compensate. It convincingly explains the 'condition' parameter and indicates the role of 'evoked_name' via 'Stored under evoked_name.' However, 'epochs_name' is not explicitly described, leaving its purpose to be inferred from its name.
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 ('Average') and resource ('Epochs' into an 'Evoked (ERP/ERF) response'), clearly distinguishing this from sibling tools like mne_make_epochs or mne_plot_evoked. The purpose is unambiguous.
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 context for when to use the tool: averaging epochs into an evoked response. It also explains the condition parameter with an explicit 'else averages all' fallback. However, it does not explicitly mention when to avoid this tool or name alternatives.
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 behavioral disclosure burden. It states what the tool does (trains classifiers, cross-validation), what it returns (mean/peak score and plot), and its dependency (scikit-learn). It does not mention side effects, but for an analysis tool that returns results, this is adequately 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 sentences, front-loaded with the core purpose, then briefly covers key parameters, return values, and dependency. Every sentence adds value with no filler.
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?
Given 6 parameters and 0% schema description coverage, the description gives only partial guidance. It explains the core behavior and return plot, but not how to set up the epochs object, what 'epochs_name' refers to, or how scoring/cv affect results. The output schema exists, but the description still leaves notable usage 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?
Schema description coverage is 0%, so the description must compensate. It explains cond_a/cond_b as event_id names, but leaves cv, scoring, name, and epochs_name unexplained. Many parameters have defaults, but their roles (e.g., scoring metric, source epochs object) are not clarified, leaving the agent guessing.
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 time-resolved decoding (MVPA) by training classifiers at each time point to discriminate two conditions. It names cond_a/cond_b specifically and mentions cross-validation, which makes the tool's purpose distinct from sibling tools like plotting or preprocessing.
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 gives clear context: use this tool for discriminating two conditions via time-resolved decoding. It says cond_a/cond_b are event_id names and requires scikit-learn, which are practical prerequisites. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for a single-purpose tool.
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?
There are no annotations, so the description carries the burden. The verb 'Show' implies a read-only operation, but the description does not explicitly state that it does not modify the session, handle errors, or require a loaded session object. Some behavioral context is provided, but not comprehensive.
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, well-structured sentence that front-loads the action and includes concrete examples. Every word contributes value; no redundancy or fluff.
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?
For a simple one-parameter tool with an output schema, the description is mostly complete. It covers the main purpose and parameter semantics, though it lacks explicit notes on error conditions or prerequisites. Given the output schema, it does not need to explain return values.
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 coverage is 0%, and the description provides the only context for the 'name' parameter by calling it 'one named session object'. This clarifies that 'name' is an identifier for a session object, but it does not specify the expected format or how to obtain valid names.
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 ('Show') and resource ('one named session object'), and lists example contents (channels, sfreq, montage, bads). This clearly distinguishes it from session-level tools like mne_session_info and other siblings.
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 context for when to use the tool: when you need a detailed summary of a specific session object identified by name. It does not mention alternatives or exclusions, but the purpose is clear enough to infer appropriate usage.
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. It discloses the critical trait 'in place,' indicating the object is modified. However, it does not state what happens when both l_freq and h_freq are null, whether the function returns a value, or potential side effects. These gaps leave some behavioral aspects unclear.
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 sentences, front-loaded with purpose and the key 'in place' behavior, followed by concise parameter explanations. Every word adds value with no repetition or fluff.
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?
Despite no annotations, the description covers the main purpose, key parameters, and the in-place mutation. It is adequate for a moderate-complexity tool, though it omits edge cases (e.g., both frequency edges null) and the use of the 'name' parameter. The presence of an output schema means return-value details need not be repeated.
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 description explains four of five parameters: l_freq, h_freq, notch, and picks, including allowed values for picks. Since schema coverage is 0%, this is essential. However, the 'name' parameter (likely identifying the object) is not explained, leaving a minor gap.
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: 'Band-pass / high-pass / low-pass and/or notch filter a Raw/Epochs/Evoked object in place.' This is specific with a verb and resource, and it distinguishes from sibling tools like mne_resample or mne_plot_psd by focusing on filtering.
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 when to use the tool (when filtering is needed) but does not explicitly mention alternatives or exclusions. It provides parameter details but no guidance on choosing this over other MNE tools, such as 'use this to remove line noise instead of mne_resample.' The usage context is only indirectly conveyed.
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 burden of behavioral disclosure. It goes beyond a simple definition by explaining the baseline default, event_id format, reject threshold in volts, and that the output is stored under epochs_name. This gives meaningful insight into the tool's behavior, though it doesn't state whether the Raw object is mutated or if specific permissions are needed.
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, slightly run-on sentence, but it is front-loaded with the core purpose and efficiently packs parameter semantics into a compact form. Each clause adds valuable information, and it avoids unnecessary detail. It earns its place, though a cleaner structure (e.g., separate sentences) would improve readability.
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?
Given the tool's complexity (8 parameters, 0 required) and no annotations, the description covers the most important parameters and gives a clear overview. However, it omits any explanation of events_name and does not mention workflow context such as needing to find events first or that this step precedes plotting/averaging. It is adequate but not fully complete.
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 input schema has 0% description coverage, so the description must compensate. It effectively explains tmin/tmax (seconds relative to event), baseline (default value), event_id (format and purpose), and reject_eeg (threshold in volts with example). It also indicates the output variable via epochs_name. However, events_name and raw_name are not explicitly described, leaving a small gap.
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 opens with a specific verb and resource: 'Segment a Raw object into Epochs around events.' This clearly identifies the tool's primary function and differentiates it from siblings like mne_plot_epochs_image or mne_average_evoked, which operate on already-created epochs.
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 usage: to create epochs from raw data, you use this tool. It provides detailed parameter usage (e.g., tmin/tmax, baseline, reject_eeg) but does not explicitly state when to use it over alternatives, nor does it mention exclusions or prerequisites. The 'Segment' verb implies the primary context, but no explicit when/when-not guidance is given.
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. It discloses the output behavior ('Returns PNG path') and the accepted values for 'times', adding value beyond the bare schema. However, it does not mention potential side effects, prerequisites (e.g., an existing Evoked object in the session), or any limitations. This partial disclosure is adequate but not rich, meriting a 3.
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 sentences long, front-loaded with the main action, and contains no filler. Every sentence adds essential information: the function and the parameter format. It is appropriately concise and well structured.
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 simplicity and the presence of an output schema, the description is fairly complete. It explains the main parameter, notes the return type, and implies the required input type. The only missing piece is elaboration on the 'name' parameter and prerequisites, but for a straightforward plotting tool this is not a major gap.
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 0%, so the description must compensate. It explains the 'times' parameter in detail (auto, peaks, or comma-separated seconds), but it does not explain the 'name' parameter, which presumably references the Evoked object. Since it fully covers one of two parameters and partially compensates, a score 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 the function: 'Plot scalp topographies of an Evoked at given times.' The verb 'Plot' plus the specific resource 'scalp topographies of an Evoked' distinguishes it from sibling tools like mne_plot_evoked (time series) or mne_plot_sensors (sensor layouts). It also specifies the key parameter 'times' and its accepted formats, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when visualizing topographical scalp maps from Evoked data. It details the 'times' parameter options, which guides usage. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list and the uniqueness of topomap plotting imply exclusion. Since it offers clear context but no exclusions, it earns a 4.
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 transparency burden. It discloses the rendering dependency, that the estimate is still computed if rendering fails, and suggests mne_run_code for inspection. It doesn't mention side effects like whether the PNG is saved to a file, but it adds meaningful behavioral context beyond the name and 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?
The description is two sentences, front-loaded with the main action, followed by parameter hints and a prerequisite. Every sentence adds value, with no filler or redundancy.
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?
Given the tool's complexity (requires 3D rendering, has 3 parameters), the description covers purpose, a key parameter, and a failure fallback. But it omits details about the output PNG (where it goes), the meaning of 'stc_name', and any side effects, so for an agent to invoke it correctly, additional assumptions may be needed.
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 no property descriptions (0% coverage), so the description must compensate. It explains the allowed values for 'hemi' ('both'/'lh'/'rh') and clarifies that 'time' defaults to peak time when null. However, 'stc_name' is not explained, leaving it ambiguous.
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 states the tool renders a source estimate as a cortical activation map (PNG) at peak time or given time, which is a specific verb+resource+output. It clearly distinguishes from sibling plotting tools (e.g., mne_plot_raw, mne_plot_evoked) by focusing on stc source estimates.
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?
It provides context for when to use: it requires PyVista off-screen rendering and offers a fallback to mne_run_code when 3D rendering is unavailable. However, it doesn't explicitly name alternative plotting tools or state when not to use it, so it falls short of a full when/when-not guide.
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 provided, the description carries the full burden of behavioral disclosure. It usefully mentions that the result is stored under ica_name, that scikit-learn is required, and that it operates on Raw/Epochs objects. However, it does not disclose whether repeated calls overwrite an existing ICA, whether the original data is mutated, or what the session-state side effects are.
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 compact and front-loaded: the first sentence states the core purpose, and the subsequent sentences deliver essential parameter semantics and dependency information. Every sentence contributes value without repetition or fluff.
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 the moderate complexity of the tool, the description covers the essential context: purpose, prerequisite filtering, parameter choices, storage location, and dependency. It does not outline the typical workflow pipeline (e.g., fitting before apply_ica), but this is not strictly required for correct invocation.
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 description coverage is 0%, so the description must compensate. It does so well for n_components (int, float variance fraction, or null) and method (fastica default, infomax, picard), and clarifies the ica_name default. It does not explain random_state or explicitly define the 'name' parameter, which are minor gaps given the schema's bare structure.
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 is specific and action-oriented: 'Fit Independent Component Analysis on a Raw/Epochs object for artifact removal' clearly identifies the tool's purpose and distinguishes it from siblings like mne_apply_ica (which applies ICA) and mne_plot_ica_components (which visualizes ICA results). It names the exact resource and the intended outcome.
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 context by noting that data should preferably be 1 Hz high-pass filtered and that the tool is meant for artifact removal. It does not mention explicit alternatives or exclusion scenarios, but the context is sufficient for an experienced MNE user to infer when to use it.
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 burden. It describes the read-only nature ('List'), the directory fallback, and optional pattern filtering. It does not disclose recursion behavior or return format, but the output schema likely covers return details, and the described behavior is sufficient for a listing tool.
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 sentences, front-loaded with the core action. It efficiently lists supported file extensions inline without being verbose, and every sentence adds value. No redundant or filler wording.
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?
For a simple file-listing tool, the description covers what files are listed, where it looks by default, and the optional filtering. It could mention recursion or absolute paths, but the presence of an output schema likely covers return structure, making this complete enough for typical use.
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 description coverage is 0%, so the description must explain parameters. It explicitly mentions the glob pattern and defaults for directory, giving meaning to both parameters beyond their bare schema definitions. It does not detail glob syntax, but the mention of 'pattern' is enough context.
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+resource: 'List neurophysiology data files' and enumerates common formats, clearly distinguishing this tool from processing/plotting siblings. It states the directory scope and optional glob pattern, leaving no ambiguity about its function.
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 gives context by mentioning the default directory (MNE_MCP_DATA_DIR / current dir) and optional glob pattern, implying use cases like discovering available data files. However, it does not explicitly state when to use this tool versus alternatives, nor when not to use it.
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?
No annotations are provided, so the description carries the transparency burden. It discloses auto-detection of format by extension and the preload behavior for large files, giving some insight into functionality, but it omits potential error cases, unsupported formats, or detailed memory usage consequences beyond the preload hint.
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 three sentences, front-loaded with the primary purpose, followed by format detection and parameter guidance. Every sentence adds value without redundancy, making it appropriately concise and well-structured.
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 simplicity with only three parameters and the existence of an output schema, the description covers the main use case and key parameters effectively. It lacks some edge-case context (e.g., what happens if a format is unsupported or file missing), but for a straightforward load tool, it is sufficiently complete.
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 schema has zero description coverage, so the description compensates by explaining the `name` parameter (storage variable with default) and `preload` parameter (for very large files). The `path` parameter is self-evident from context, and the auto-detection detail adds meaning to the extension handling. No additional details on path validation are given, but core parameters are covered.
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's function: loading a raw recording from disk into the session. It uses a specific verb ('Load') and resource ('raw recording'), and differentiates from sibling tools by focusing on data acquisition rather than processing or saving.
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?
Provides clear context for when to use the tool: when needing to load raw data into the session. It includes practical guidance on using preload=False for large files, but does not explicitly contrast with alternative tools or state when not to use it, though no direct alternative exists among siblings.
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. It clarifies that the tool returns a one-line summary of each object, and the verb 'List' implies read-only behavior. However, it does not explicitly state that the operation makes no modifications to the session, nor does it describe any potential performance implications. Adequate for a simple inspection tool but not exhaustive.
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 sentences, front-loaded with the action verb, no redundant phrasing. The second sentence adds practical usage guidance without fluff. Every word earns its place.
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 the tool's purpose, the content it reports, and the recommended usage context. An output schema exists, so return format details are not required. It could mention that the session persists across tool calls, but that is implied by 'persistent analysis session'. Sufficiently complete for a zero-parameter inspection 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?
The tool has zero parameters, so the baseline is 4. The description enumerates the object categories in the session, which indirectly informs expected results, but there are no parameter details to add. No further compensation needed.
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 opens with 'List every object currently held in the persistent analysis session' – a specific verb and clear resource scope. The parenthetical enumeration of object types (raw recordings, epochs, evoked, ICA, events, arrays) further clarifies what the session contains. This distinguishes it from sibling tools like mne_list_files or mne_get_info.
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?
Explicitly states the intended use case: 'Use this to see what is loaded before operating on it.' This gives clear contextual guidance. It does not name alternative tools or exclusion criteria, but the tool's unique role as a session-wide listing makes ambiguity low.
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. It lists the specifics checked and notes scikit-learn as an ICA dependency, which is useful behavioral context. However, it doesn't disclose whether the tool has side effects, permissions, or error behavior, leaving some transparency gap.
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 sentences, front-loaded with the action, and each sentence adds value. Extremely concise.
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?
The tool is simple with no parameters and an output schema, so the description covers the essential: what is checked and when to call. It's complete for a status check 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?
The tool has zero parameters, so the baseline of 4 applies. The description doesn't need to add param semantics because there are none.
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 checks MNE MCP capabilities, listing specific versions and directories, and instructs to call it first, distinguishing it from the many processing sibling tools.
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 instruction 'Call this first' provides explicit when-to-use guidance. It also mentions scikit-learn needed for ICA, giving context for why to check dependencies. However, it doesn't explicitly state when not to use alternative tools, so I deduct slightly.
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 fully carries the transparency burden. It discloses the persistent namespace, pre-bound variables, return value of final expression, stdout capture, and PNG saving for matplotlib figures. This gives a solid behavioral model, though it could additionally mention mutation of session state or error handling.
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?
Three sentences, front-loaded with the main action, and each sentence adds distinct value. No redundancy or fluff. The notebook-cell analogy is a concise way to convey behavior.
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 execution context, input, behavior, and outputs (return value, stdout, figure paths). It is complete for a generic code execution tool, though the output schema is not detailed in the description (but is provided separately).
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 0%, so the description must clarify the 'code' parameter. It does so thoroughly by explaining what the code should contain, the execution environment, and expected outputs. While lacking explicit syntax examples, it effectively compensates for the missing schema description.
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 executes arbitrary Python/MNE code in a persistent session namespace, with specific pre-bound names and loaded objects. It distinguishes itself from sibling structured tools by framing itself as a catch-all for anything the structured tools do not cover.
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?
Explicitly says 'Use this for anything the structured tools do not cover,' providing a clear when-to-use directive. It implies structured tools should be preferred for their specific purposes, though it does not name individual alternatives.
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 burden of conveying safety. The verb 'Show' clearly indicates a read-only operation. It adds context beyond the schema by explaining that the config values are fallback defaults used by other tools, and that they are modified through a terminal command, which helps the agent understand the tool's role without trying to mutate state.
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 starts with the action 'Show' and immediately lists the config contents, then provides related usage context. Every clause adds value; there is no wasted text or repetition of schema information.
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 getter with no parameters and an output schema available, the description is fully sufficient. It explains what the tool returns, why those values matter (fallback defaults), and how they are changed. Nothing essential is missing for an agent to select and invoke the tool correctly.
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, and the input schema is empty, so the baseline is 4. The description adds no parameter details (none exist), but it does list the fields the config covers (line frequency, montage, etc.), which enriches the output semantics even though no input is needed.
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 'Show' with a clear resource ('configured default analysis parameters') and enumerates the contents (line frequency, montage, etc.), making the tool's function unambiguous. It is clearly distinct from siblings like mne_get_info (raw data info) and mne_session_info (session state), as it targets the default configuration used as fallback.
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 that these parameters are the fallback for structured tools when a parameter is omitted, which implies when to use this tool (to inspect defaults before calling other tools). It also mentions how users can change them via `mne-mcp configure`, adding practical usage context. However, it does not explicitly state 'use this when you need to know defaults' or list 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 behavioral disclosure burden and does disclose important side effects: 'Downloads the fsaverage template once (~ tens of MB)' and 'Stored under fwd_name'. It does not detail prerequisites (like a montage being set) or potential overwriting behavior, but the disclosed download and storage behavior is valuable.
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 four succinct sentences, each adding distinct value: purpose, download behavior, use case, and output storage. It is front-loaded with the core action and avoids redundancy or filler.
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?
For a tool with no annotations and zero parameter schema coverage, the description covers the essential aspects: what it does, when to use it, and key side effects. The existence of an output schema covers return values. However, it does not explicitly state prerequisites (e.g., that the object must already have a montage), which would improve completeness for an agent.
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?
Schema description coverage is 0%, so the description must explain parameters. It does: 'named object's montage' clarifies that the 'name' parameter refers to the source object, and 'Stored under fwd_name' specifies the destination parameter. Both parameters gain meaningful semantics beyond the raw 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 opens with a specific verb 'Build' and resource 'template-head (fsaverage) EEG forward model', clearly distinguishing it from sibling tools like mne_apply_inverse or mne_compute_noise_cov. It also adds use-case context ('for EEG source localization without an individual MRI'), further clarifying its unique role.
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 an explicit use case ('Use for EEG source localization without an individual MRI') and notes a practical consideration (downloads template). However, it does not name an alternative tool for when an MRI is available or explicitly state when not to use this tool, leaving the exclusion inferred.
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 explicitly discloses that the operation is 'Irreversible' and specifies the scope ('all loaded objects and figures'). This effectively communicates the destructive nature and what is cleared, though it could mention side effects like unsaved state, but the coverage is solid for a reset action.
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 compact sentences, front-loaded with the action 'Clear all loaded objects and figures' and followed by the impact 'Irreversible.' Every word earns its place with no fluff.
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 tool with no parameters and an output schema that presumably defines return values, the description covers the essential facts: action, scope, and irreversibility. Nothing critical is missing for an agent to select and invoke this tool correctly.
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 there is nothing to explain beyond what the schema already conveys (an empty object). The baseline for 0 params is 4, and the description adds no irrelevant param details.
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 'Clear' with a clear resource: 'all loaded objects and figures from the session'. It states the outcome ('starting fresh') and is distinct from all sibling tools, which focus on analysis or loading operations. This unambiguously identifies the tool's function.
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 phrase 'starting fresh' clearly implies the intended use case: when the user wants to reset the session state. It does not explicitly mention alternatives or when not to use it, but for a simple reset tool, this is sufficient context. The tool's uniqueness among siblings (no other reset tool) further clarifies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that this is an installation into the server's Python environment, mentions the large download and multi-minute duration, and explains profile differences. This gives the agent a realistic picture of the operation's impact.
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 compact yet comprehensive. Every sentence serves a purpose: what it does, when to use it, the profile options, and expected duration. Information is front-loaded, with the core purpose in the first clause.
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 tool's moderate complexity (installation with profile choices) and lack of annotations, the description covers all essential aspects: purpose, trigger condition, parameters, side effects, and time. An output schema likely handles return values, so those need not be described. There are no notable gaps for an agent to invoke this correctly.
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?
The schema has only one parameter (profile) with no description (0% schema coverage). The description adds full semantics by listing the three valid values and their meanings: 'ica' (default), 'analysis' (no scikit-learn), and 'full' (adds source localization, connectivity, etc.). This is exactly the kind of value the description should add.
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: provisioning the MNE-Python backend into the server's environment. It uses a specific verb ('Provision') and resource ('analysis backend'), and is distinct from sibling analysis tools like mne_filter or mne_plot_raw.
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?
Explicit usage guidance is provided: 'Call this once when mne_check_status reports the backend is not installed'. It also clarifies that after calling, every mne_* tool works without client restart, setting a clear condition for use.
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:

[![MNE-MCP MCP server](https://glama.ai/mcp/servers/Exekiel179/MNE-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Exekiel179/MNE-MCP)

Score Badge

Copy to your README.md:

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

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