eeg-mcp

by AImplifier

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
Every tool targets a distinct resource and action, with nuanced distinctions clearly explained (e.g., get_events vs list_recording_events, start_stream vs start_replay). No two tools appear to do the same thing, even in dense areas like stimulation and processor management.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern (list_, get_, start_, stop_, attach_, detach_, set_, clear_) with a predictable 'status' suffix for health-check tools (stream_status, processor_status). No mixing of conventions or vague verbs.
Tool Count2/5
At 47 tools, the surface is far above the 'heavy' threshold of 25. While the broad scope of a full EEG platform justifies many operations, the sheer number is overwhelming for an agent to navigate efficiently and risks tool-selection errors in practice.
Completeness5/5
The tool set covers the entire EEG workflow: acquisition, filtering, analysis, recording, replay, stimulation, monitoring, events, and processors. Lifecycle actions have counterparts (start/stop, attach/detach, arm/disarm), and there are no obvious dead ends or missing core operations.
Average 4/5 across 47 of 47 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under BSD 3-Clause.
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 of behavioral disclosure. It doesn't mention what 'recent outputs' entails (e.g., is it buffered?, does reading clear the buffer?, what happens when no outputs exist?), nor does it note that a streaming processor's outputs are transient. The description 'recent outputs' implies non-persistence but this isn't explicit.
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?
A single sentence that's efficient and front-loaded with the core purpose. The brevity is appropriate given good schema coverage, with zero wasted words. Slight deduction because it could have used the space for sibling differentiation or behavioral context.
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?
Despite an output schema and full parameter coverage, the tool is a 'reading' operation on a streaming processor — a domain where buffer semantics, whether data is consumed, and ordering guarantees matter. The description doesn't clarify these. For a tool with roughly 30 sibling tools and no annotations, more context is needed for correct selection and use.
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 100%, so the schema documents all three parameters. The description adds no additional parameter-level meaning beyond the schema, but the schema itself is adequate (limit default of 20 with direction 'newest last' is documented). Baseline 3 is appropriate given full coverage with no extra description value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read a streaming processor's recent outputs' identifies a specific verb (read) and resource (streaming processor outputs). However, it doesn't differentiate from siblings like stream_status, get_channels, or read_window — multiple sibling tools relate to reading data from streams/processors. The purpose is clear in isolation but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this vs alternatives like stream_status, run_processor, or read_window. There's no mention of prerequisites (e.g., the processor must be running, session must be attached). The description provides no context for choosing this tool over its many siblings in the stream/processor family.
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 of behavioral disclosure. It states the tool closes and removes a backend but doesn't disclose what happens to ongoing stimulation (e.g., whether it forces disarm), error conditions, whether the session must be stopped first, or idempotency behavior if called on an already-detached backend. For a state-mutating tool with zero annotation coverage, this is a meaningful 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?
A single, complete sentence with zero waste. Both the action and scope are conveyed efficiently. There is no redundant framing such as 'This tool is used for...' or repetition of information already in the schema/title.
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 exists but the description doesn't explain what it returns. More critically, for a state-mutating tool (detaching a backend) with no annotations, the description should cover behavioral aspects like prerequisites (attached backend exists), side effects (stimulation halted), and error behavior. The pairing with attach_stim_backend and related stim tools (arm_stim, disarm_stim, send_stim_train) suggests a lifecycle that the description fails to contextualize.
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 100%, so the schema documents both parameters (session_id and backend) well. The description adds the word 'attached' to clarify that backend refers to a previously attached backend, adding some meaning beyond the schema. However, it doesn't specify the backend name format, whether it must match exactly, or what happens if the backend name is invalid. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Close and remove a stimulation backend from a session' clearly identifies the verb (detach/close/remove), the resource (stimulation backend), and the scope (from a session). It distinguishes from the sibling detach_processor and attach_stim_backend tools by using consistent terminology (backend, session). Clear but could specify the state change more explicitly.
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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., backend must be attached first, stream stopped), nor does it name counterpart attach_stim_backend or contrast with disarm_stim for the parent-child relationship of operations. Context is implied by the 'detach' name but no explicit usage conditions 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 does note that the action takes effect immediately, which is useful behavioral context. However, it doesn't explain what happens to in-progress stimulation, whether this is reversible via arm_stim, or whether specific backend/permission state is required.
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 extremely concise at two short sentences with zero waste. It front-loads the core action and adds a single behavioral note about immediacy. Efficient and to the point, though slightly terse.
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 (2 params, 1 required) and has a full output schema, so the burden is moderate. For a state-changing operation on stimulation with no annotations, the description could reasonably explain what disarming means for ongoing operations and how it relates to the arm/send/stim lifecycle, but it is adequate for a straightforward revocation action.
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 100%, with both parameters (session_id and backend) having descriptions in the schema. The description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 applies. The term 'disarm' clearly implies reversible revocation related to arm_stim, which is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Revoke permission to stimulate. Takes effect immediately,' which clearly indicates a permission-revocation action for stimulation. However, it doesn't explicitly reference the session context or distinguish it from the sibling 'arm_stim' among many stim-related tools, and the domain-specific term 'stimulate' may not be universally understood.
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. Among siblings like arm_stim, send_stim_train, and stim_status, there is no mention of prerequisites (e.g., a backend must be attached/armed first) or what circumstances warrant disarming. 'Takes effect immediately' hints at immediacy but gives no context about sequencing with other operations.
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 states the output (standalone HTML file) which is useful, but doesn't disclose whether the file is saved to disk, written to a temp location, returned as a path, or how it relates to session state. For a rendering tool with zero annotation support, this is a meaningful gap.
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, tight sentence with meaningful content (power spectrum, band composition, standalone HTML). It's front-loaded and wastes no words, though it could have used space for usage guidance the description lacks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (context signal 'Has output schema: true'), which covers return-value explanation. With modest complexity (5 params, all schema-documented) and no annotations, the description plus schema is adequate but not rich. The description doesn't clarify the HTML-file disposition or relationship to plot_stream, leaving room for improvement.
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 100%, so the schema already documents all five parameters including defaults and the 'filtered' boolean semantic. The description adds marginal value beyond this — the 'longer gives finer frequency resolution' note on seconds is in the schema already. The description itself lists no parameter details, making baseline 3 appropriate.
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 'Render the power spectrum and band composition as a standalone HTML file' uses a specific verb (render) and clear resource (power spectrum and band composition) with a notable output detail (standalone HTML). It's clear but doesn't explicitly differentiate from the sibling 'plot_stream' or 'get_psd'/'get_band_power' tools, though the HTML output format distinguishes it from the data-returning siblings.
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 on when to use this vs alternatives. Sibling tools like get_psd, get_band_power, and plot_stream serve related purposes but the description provides no when-to-use or when-not-to-use direction. The HTML output implies a visualization-on-disk use case that distinguishes it, but this is only implicit.
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 disclosure burden but only mentions that channels are listed with their buffer index. It does not disclose whether this is a read-only operation, whether sessions must be active, or what happens for invalid session IDs. The buffer index detail adds some useful context, but behavioral expectations remain minimal.
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 informative sentence that states the action, the resource, and a useful detail (buffer index). No filler or redundant wording. It is efficiently structured, though it could arguably fit more guidance in the same space.
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?
This is a simple tool with one parameter and 100% schema coverage, so a fairly minimal description is reasonable. However, no annotations exist and the tool sits among ~45 siblings, so naming when/why to use this inspection tool would meaningfully improve completeness. The return structure is documented via the output schema, which offsets some of the 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 100%—the sole parameter session_id is described as 'The session to inspect.' The description adds no detail beyond 'a session,' matching the schema's meaning. Since schema fully documents the parameter, baseline 3 is appropriate; the description doesn't add format constraints or edge-case behavior.
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 uses a specific verb ('List') with a clear resource ('channels a session is producing') and adds the detail about buffer index. It has a clear, identifiable purpose that distinguishes it from sibling tools like get_band_power or get_psd, which are about signal metrics rather than channel enumeration.
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 gives no guidance on when to use this tool versus alternatives. Among siblings there are related inspection tools (stream_status, get_band_power, get_psd), but nothing explains why the agent should choose get_channels over them, or whether it applies to active vs recorded sessions.
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 full burden for behavioral disclosure. It explains the store ownership model (who reads/writes it) which is genuinely useful context, but doesn't disclose return format, ordering guarantee details beyond 'newest first', pagination behavior, or what happens with the limit parameter when recordings exceed it.
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?
Two focused paragraphs, no redundancy. The second paragraph adds valuable architectural context about store ownership that earns its place. Could arguably shave some prose but it's tight overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and 100% parameter coverage, which reduces the burden on the description. However, for a listing tool in a system with many siblings, some guidance on how it relates to list_sessions/list_boards or when to use inspect_recording would improve completeness. The store-ownership context partially compensates.
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 100%, so both parameters (limit and subject) are documented in the schema. The description doesn't add much parameter-specific meaning beyond what the schema provides, so baseline 3 is appropriate.
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 uses a specific verb+resource ('List recordings... newest first') and clearly states the scope (eeg-mcp's own metadata store). It distinguishes from siblings partly by clarifying this is a metadata store listing, though it doesn't name specific sibling alternatives like list_sessions or inspect_recording.
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 first sentence establishes clear usage context (list metadata, newest first), but there's no explicit when-to-use vs alternatives guidance. The second paragraph adds useful context about store ownership and compatibility but doesn't name alternative tools for different listing needs.
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 zero annotations, the description carries the full burden of behavioral disclosure. 'Remove... and release its state' hints at state destruction, but it doesn't state whether state is recoverable, whether re-attachment reinstates it, or whether the processor continues running. For a state-releasing operation, this is a notable gap.
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, tight sentence with zero waste. Front-loads the action clearly. Could arguably add a touch more behavioral detail, but the structure itself is 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?
For a state-mutating operation with no annotations and no parameter enum constraints, the description handles the basics but underspecifies state effects. There is an output schema which helps with return understanding, but the behavioral ambiguity around 'release its state' and reversibility leaves room for improvement.
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 100% so both parameters are documented in the schema itself. The description's phrases 'Remove from a session' (maps to session_id) and 'a processor' (maps to processor) reinforce parameter roles but add no new formatting/syntax details beyond the schema. Baseline 4 for high coverage with basic reinforcement is reasonable.
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 uses a specific verb-resource pair ('Remove a processor from a session') and adds behavioral scope ('and release its state'). This clearly distinguishes it from siblings like attach_processor and reset_processors, though it doesn't name the alternative explicitly.
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 context (detaching an attached processor) and the sibling list suggests this pairs with attach_processor, but there's no explicit when/when-not guidance or mention of alternatives like reset_processors vs detach.
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 full behavioral disclosure burden. It does state the key consequences: the monitor is closed and the port is freed — which is meaningful lifecycle context. However, it doesn't disclose idempotency (what happens if called with a stopped/invalid session), error behavior, or whether this affects streaming/recording. Moderate disclosure but not complete.
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 clear sentence that captures purpose and side effect with zero waste. 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?
This is a simple one-parameter tool with full schema coverage and an output schema present. The description covers the core behavior adequately. However, with a mutating action (freeing a port), it would help to note idempotency or behavior on non-existent sessions, especially since no annotations provide a safety profile. Basic completeness but lifecycle edge cases are left undocumented.
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 100% with the session_id parameter fully described. The description adds the notion that this closes a 'live' monitor and frees its 'port,' adding slight context about what 'stop' means operationally. However, it doesn't add meaning about valid session states (must the session exist? must it be currently monitored?). Schema already handles the base case, so a baseline 3 is appropriate.
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 'Close a session's live monitor and free its port' uses a specific verb (close/free), names the resource (session's live monitor), and clearly states the side effect (freeing its port). It distinguishes from the sibling start_monitor/list_monitors reasonably well, though it doesn't explicitly contrast with them.
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 on when to use this tool vs alternatives. There are related monitor tools (start_monitor, list_monitors) and stream tools (stop_stream), but the description doesn't clarify when to stop a monitor vs stop a stream, or whether stopping a monitor is a prerequisite for disarming/releasing resources. Context is implied (when you need to end a monitor) but no explicit 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.
Behavior2/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 it reports recording state and written amount, but doesn't disclose what 'written' means (bytes? samples? chunks?), whether this is a safe read operation, whether it returns raw data, or any side effects. Given the absence of annotations, this is a meaningful gap 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?
One concise sentence, zero wasted words. It efficiently states both what it reports (recording on/off) and the additional detail (amount written). Appropriately sized for a single-parameter read-style tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich sibling context (start_recording, stop_recording, list_recordings, inspect_recording), an output schema, and only one fully-documented parameter. The description covers the essence adequately. For a status-check tool, this is mostly complete, but it falls slightly short on explaining what 'amount written' means and how it relates to the recording lifecycle—details the output schema might clarify but the description doesn't contextually frame.
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 100%, so the single parameter (session_id) is fully described in the schema as 'The session to check.' The description tool-level explains the purpose of the check (recording status and written amount), which adds context beyond the schema's minimal 'session to check' phrasing. With full schema coverage at the baseline of 3, the description's clarification of what will be reported adds modest value.
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 what the tool does: reports whether a session is recording and how much has been written. The verb 'Report' plus the resource 'session' and the outcome (recording status + written amount) is specific. It doesn't explicitly distinguish from siblings like stream_status or inspect_recording, but it does name its specific function clearly.
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 conveys when to use it (when you need to know whether a session is recording and how much was written). However, it doesn't explicitly mention alternatives or when not to use it, such as distinguishing from stream_status (which likely relates to streaming rather than recording) or inspect_recording (which might provide deeper detail). The context is clear but no exclusions or alternative 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?
No annotations are provided, so the description carries the burden. It discloses that reads are scoped to recent token groups, that it depends on an attached processor exposing token_history, and describes the return contents. It does not describe error behavior when no such processor is attached, limit semantics details, or ordering guarantees.
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?
Description is compact and well-organized, with a clear opening sentence, a purpose paragraph, and an integration note. Zero waste — every sentence adds value. Could arguably be slightly trimmed but is appropriately sized.
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?
An output schema exists, so return values are documented elsewhere. The description covers the use case, prerequisites (attached processor with token_history), built-in default, and extensibility for custom tokenizers. For a read tool with good schema coverage and output schema, this is reasonably complete.
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 100%, so all three parameters are documented in the schema itself. The description adds context about the return structure but doesn't add meaning to individual parameters beyond the schema. Baseline of 3 is appropriate since the schema handles parameter documentation well.
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?
Description clearly states it reads discrete tokens from a tokenizing processor and explains the output (grouped tokens, flat sequence, vocab size, channel/band layout). It distinguishes from siblings like get_processor_output by specifying the token-specific nature and structured return. However, it doesn't explicitly contrast against get_processor_output or read_window as alternatives.
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?
Description states the use case ('For feeding EEG into sequence models') and notes compatibility with any processor exposing token_history, but doesn't explicitly say when NOT to use it or name alternative tools. The context is reasonably clear for when this tool applies.
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 burden of behavioral disclosure. It adds some useful context about the relative values being immune to impedance drift, which is a meaningful behavioral trait. However, it doesn't disclose return format details (though an output schema exists), any side effects, or error conditions. Given the useful impedance-drift insight but absence of broader behavioral details, a 3 is fair.
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 compact—three sentences. The first sentence is a clear purpose statement, the second identifies the tool's role, and the third provides actionable guidance. No filler or redundancy. It could arguably drop the 'workhorse' framing, but that framing also serves usage guidance. Efficient and front-loaded.
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 has 6 parameters, an output schema, and no nested objects. The description covers the core purpose, provides domain guidance (relative values immune to drift), and the schema covers all parameters. With an output schema present, return-format explanation isn't required. The main gap is no guidance on trade-offs versus get_psd for spectrum analysis, but the description is reasonably complete for its complexity level.
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 100%, so the schema fully documents each parameter. The description adds value by clarifying the _rel parameter's significance for threshold stability over time, which complements the schema's 'fraction of total power' wording. This extra guidance justifies a 3 rather than baseline 3 being penalized, but it doesn't substantially enrich parameter understanding beyond the schema.
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?
Description states 'Band power over the most recent window, per channel and averaged' and calls it 'the workhorse feature for neurofeedback and closed-loop triggering.' This clearly indicates verb (get/compute) + resource (band power) in a specific usage context. It doesn't explicitly distinguish from get_psd (which is its closest sibling), but the purpose is clear and specific.
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 on when to use it ('the workhorse feature for neurofeedback and closed-loop triggering') and importantly recommends using _rel values for thresholds because they're 'largely immune to impedance drift.' This is practical guidance on how to use the output. It doesn't explicitly state when NOT to use it or name an alternative like get_psd, slightly reducing the 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 of behavioral disclosure. It does explain that events from four sources are unified on one clock and why that matters (reconstructability). However, it doesn't disclose ordering behavior, pagination, whether it's bounded, or how limit/truncation works beyond what the schema already says. The clock-unification rationale adds genuine context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences. The first states the purpose directly, and the second explains the unifying-clock rationale and why that matters. Zero filler, front-loaded with the verb+resource declaration, and the closing rationale is genuinely useful rather than padding.
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 captures the essential domain context (unified clock, four event sources, reconstructability rationale) which is the key complexity this tool addresses. The full schema coverage plus an existing output schema means return-value explanation is not required. It could mention ordering (schema says 'most recent first' via limit) but that's already in the schema, so the description is adequately complete.
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 100% and all five parameters are documented in the schema (filters for label, origin, limit, last_seconds). The description adds conceptual context about what event types exist (board markers, annotations, stim commands, manual notes), which enriches the 'origin' filter meaning. But it adds little semantically beyond the schema's own parameter descriptions; baseline 3 with modest credit for the origin taxonomy.
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 states this reads 'the session's event log' and explains what sorts of events land there, distinguishing it from sibling tools like list_recording_events, get_epoch_around_event, and log_event. The verb+resource is clear, but it doesn't explicitly contrast with siblings by name, and get_epoch_around_event / list_recording_events could be confused without further contrast.
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 implicitly conveys 'use this to inspect the full unified event log' and explains events are unified on a single clock for reconstructability, which suggests when it's useful. However, it doesn't explicitly state when NOT to use it (e.g., when to use list_recording_events or get_epoch_around_event instead), so alternatives aren't clearly delineated.
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 discloses that it lists sessions and describes return content (source kind, running state, buffer fill), which is useful behavioral context. However, it doesn't clarify any side effects (none expected for a list operation) or distinguish whether this returns running-state snapshots vs historical data.
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?
Concise two-sentence description that front-loads the core purpose and then details return content. Every sentence adds value; no filler or repetition. Could be slightly more structured but is appropriately tight.
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?
This is a simple zero-parameter list tool with an output schema present, so the completeness bar is lower. The description adequately explains what's returned. However, it doesn't mention pagination or ordering behavior of the list, which could matter for many active sessions, but this is a minor gap for a tool of this simplicity.
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 schema coverage is 100%, so schema carries full weight. With 0 params, baseline is 4. The description explains what the returned summary includes (source kind, running state, buffer fill), adding interpretation value beyond the empty schema. No param semantics gap exists since there are no params.
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?
Description clearly states the verb (list) and resource (all active stream and replay sessions) with a specific scope ('active'). It distinguishes stream vs replay sessions and mentions a one-line summary format. It doesn't explicitly differentiate from sibling tools like stream_status or recording_status, but the scope ('all active sessions') gives reasonable clarity.
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 it ('list all active sessions'), providing a clear context. However, it doesn't explicitly state when not to use it or name alternative tools like stream_status for single-session queries. It doesn't mention whether it's a read-only helpful overview vs something more targeted.
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 behavioral disclosure burden. The description indicates a read-only reporting action ('Report...'), which is clear. However, it doesn't disclose what happens with an invalid session_id (error behavior, failure mode), whether it reflects real-time state or a snapshot, or any side effects. For a status tool this is reasonably low-risk, so the gaps are moderate.
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 listing the exact three things reported. Zero wasted words, front-loaded with the verb 'Report'. Ideal conciseness for a status tool.
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?
There is an output schema present, so return values are presumably documented there. The description names the three report dimensions (backends, arming state, dispatch counts), which is sufficient context for an agent to know what to expect. Minor gap: it doesn't note that this is a monitoring/snapshot call vs. a subscription, but for a 'status' tool this is reasonably complete.
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 100% (the only parameter `session_id` is documented as 'The session to report on'). The description adds no additional semantics beyond the schema, and with a single simple parameter there's little to add. Baseline 3 is appropriate when the schema fully documents the parameter.
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 uses a clear resource+aspect pattern: 'Report attached stimulation backends, arming state, and dispatch counts.' It clearly states what is reported. However, it doesn't explicitly differentiate from siblings like `list_stim_backends`, `stream_status`, or `processor_status`, though the specific enumerations (attached backends, arming state, dispatch counts) provide reasonable distinction for a status tool.
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 this is a status/read tool for a given session (via `session_id`), but provides no explicit guidance on when to use it versus `list_stim_backends`, `arm_stim`, `disarm_stim`, or `stream_status`. It does not state whether it should be called before arming, after attaching backends, or for monitoring. Usage context is only implied by the status-reporting nature.
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 full burden of behavioral disclosure. It does a decent job explaining the semantics of key fields (throughput_ratio, group_delay_sec, last_error) and what they signal. However, it doesn't disclose whether this is a read-only operation (which seems obvious given 'report'), error/edge cases, or what happens when a session doesn't exist.
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 compact but dense. The initial one-line summary is clear, and the follow-up bullets provide actionable interpretation guidance. The formatting with code literals and newlines is clean and scannable. No wasted words.
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?
An output schema exists, so the description needn't enumerate every return field. The description wisely highlights the fields that 'matter for closed-loop work,' which is exactly the kind of prioritization an agent needs. For a single-parameter read-only report tool, this is reasonably complete, though it could mention idempotence or frequent-polling suitability.
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 100% and session_id is well-described ('The session to report on'). The description adds context about what the output means, which helps the agent interpret results. With only one simple parameter at full schema coverage, the baseline is 3-4, and the description's field explanations add genuine value.
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 states this is a 'Health and timing report for a session,' which clearly indicates the tool reports on stream/session health. It distinguishes meaningfully by focusing on production health metrics (throughput, group delay). However, it doesn't explicitly contrast with siblings like stim_status or recording_status which are also status tools, though the title 'stream_status' plus 'session' framing differentiates it adequately.
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 explains which fields matter for closed-loop work, giving the agent context on how to interpret key output. However, it doesn't explicitly state when to use this vs. related status tools (stim_status, recording_status), nor does it address timing considerations like whether this should be polled regularly or only when a stream is active.
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 full burden. The word 'live' and 'currently serving' describe the tool as a read-only operation, which is adequate. However, it doesn't clarify behavior around stopped monitors, sort order, or whether the list is paginated. It's honest and non-deceptive but thin.
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, zero wasted words. It states the resource, the scope ('live', 'currently serving'), and the return value (URLs) all in minimal prose. Front-loaded with the core action.
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 parameterless read-only listing tool with an output schema present, the description is reasonably complete. It covers what is returned (active monitors + URLs). It could mention that stopped monitors are excluded more explicitly, but the word 'live' carries that meaning adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema carries no burden. The description clarifies the return payload will include URLs per active monitor, which is useful given there are no inputs to document. For a parameterless tool, this is an acceptable baseline.
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 states the tool lists live monitors currently serving with their URLs, using a specific verb and resource ('list' + 'monitors'). It distinguishes well from siblings like list_sessions, list_boards, and list_recordings which target different resources. The second sentence adds return details (Active monitors and URL) that reinforce purpose.
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 this is for viewing currently active monitors, and the sibling context (start_monitor, stop_monitor) suggests it pairs with those lifecycle tools. However, it doesn't explicitly state when to prefer this over similar list tools, nor does it clarify whether stopped monitors are excluded (which 'live' implies but doesn't confirm).
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 provided, so the description carries the full burden. It does disclose that this opens a transport and can be used for rehearsal, but it doesn't detail potential side effects (disarming existing stim, device connection requirements, whether the transport consumes hardware resources that need explicit teardown). The 'open its transport' phrasing hints at resource acquisition but doesn't explain cleanup requirements.
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 compact—two sentences that earn their place. The first states the purpose, and the second gives actionable advice. It's slightly front-loaded and could arguably add a bit more operational detail, but it's efficiently written with no 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?
Given the tool has moderate complexity, 100% schema coverage, and an output schema, the description covers the core scenario (backend selection, rehearsal to production flow). It could mention what the output/return contains or what 'transport' implies operationally, but with a rich schema and output schema present, the description is reasonably complete for selecting and invoking the 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the 'log' backend default for rehearsal and ties the 'switch once the timing looks right' advice to the backend parameter. The schema already documents backend and options well with examples, and the description reinforces the practical distinction between backends.
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 states the tool 'binds a stimulation target to a session and opens its transport', which is a specific verb+resource pair. It distinguishes from siblings like detach_stim_backend and list_stim_backends through the word 'open its transport' and the attached context, though it doesn't explicitly name the alternative/sibling options.
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 practical guidance: start with backend='log' to rehearse a protocol with no output, then switch once timing looks right. This provides concrete usage context, though it doesn't explicitly state when NOT to use this tool or name alternative tools.
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 full burden, and it does add behavioral context (it operates on the 'most recent window', uses filtered buffer by default per schema, returns capped bins). However, it doesn't disclose potential side effects, data volume, performance implications, or what happens when no session/stream is active. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tight, front-loaded description with the single-sentence summary first, then targeted usage guidance. No wasted words. Could add a touch more behavioral detail, but what's written 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 read-only analysis tool with 100% schema coverage and an output schema present, the description is reasonably complete. It clarifies the intended use cases and the 'most recent window' semantic. It's adequate but doesn't detail edge cases like no-data or unset filter chains.
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 100%, so the schema documents all parameters. The description reinforces key semantics ('most recent window' ties to seconds, frequency resolution ties to window length) but doesn't deeply elaborate beyond the schema. Given full coverage, this exceeds the baseline 3 by connecting the tool's purpose to parameter meaning.
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?
Clear verb+resource: computes 'Power spectral density over the most recent window.' It gives specific use cases (peak alpha, artifact confirmation, notch verification), distinguishing it from the sibling get_band_power. It doesn't explicitly name alternatives like plot_spectrum, so it stops short of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete scenarios for when to use it — 'when band power is too coarse' — implicitly naming get_band_power as the coarser alternative. This is clear context for when versus when-not, though it doesn't explicitly name plot_spectrum or other spectrum tools as siblings for comparison.
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?
Annotations are absent, so the description carries behavioral disclosure burden. It transparently explains the availability distinction between software vs hardware backends, and mentions that hardware backends must be armed. However, it doesn't disclose details like whether this is a pure read operation or anything about the 'safety ceilings' return value semantics. The description's behavioral content is useful but incomplete for a stateless list operation.
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 well-organized with a clear lead sentence, a structured breakdown of backend types, and a short return-value note. It's reasonably concise, though it could be trimmed slightly — the format hints like ('log', 'lsl', ...) are valuable and earned their place. The front-loaded purpose makes it skimmable.
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?
There is an output schema, so return values are partially explained by structured data. The description adds the distinction between backend categories and the environment-variable requirement, which is important operational context. The mention of 'safety ceilings' hints at what the returned catalogue includes. For a parameterless listing tool with an output schema, this is reasonably complete, though it could elaborate on what options/safety ceilings mean.
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?
This tool takes 0 parameters with 100% schema coverage (empty schema), so no parameter documentation is needed. The baseline for 0 parameter tools is 4, and the description appropriately covers what the tool returns without needing parameter details.
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 lists 'stimulation targets, their options, and which ones drive hardware', which is a specific verb (list) + resource (stimulation backends/catalogue). It is well-distinguished from sibling tools like attach_stim_backend, arm_stim, and stim_status, which involve different operations on stimulation state.
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 usage context by distinguishing software backends (always available: 'log', 'lsl', 'brainflow_marker') from hardware backends that require env var EEG_MCP_ALLOW_HARDWARE_STIM=1 and arming. This tells the agent when this listing is relevant and what constraints apply to the hardware entries. It lacks explicit guidance on when NOT to use it or alternatives, but the context is quite 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?
No annotations are provided, so the description carries the behavioral burden. It discloses that the operation is non-destructive to processor attachment ('without detaching them') and that it clears 'accumulated state and outputs.' However, it doesn't clarify whether this is reversible, whether it affects running data streams, or what the return value looks like. With no annotations and no output schema details in the description, 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?
Two sentences, zero wasted words. The first sentence states the core action, the second provides usage context. Efficient and well-paced.
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?
There is an output schema present, and only one simple parameter, so the description's job is light. It covers purpose, usage timing, and behavioral effects adequately. The only gap is not disclosing side effects on active streams or whether this is safe mid-stream, but for a reset tool with a simple session_id parameter, this is reasonably complete.
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 100% and there's only one parameter (session_id), which is well described in the schema itself. The description adds minimal beyond that — the session_id parameter is self-evident given the tool name. Description doesn't add syntax or format details beyond the schema, so baseline 3 is appropriate.
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 states the verb clearly ('Clear accumulated processor state and outputs') and specifies the resource ('processors'). It distinguishes itself from detach operations by noting 'without detaching them.' It reads coherently among siblings like detach_processor and clear_events, though it doesn't explicitly name a differentiating sibling alternative.
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 two clear usage contexts: 'between experimental blocks' and 'after a replay seek,' explaining why (so a rolling window does not straddle the discontinuity). This provides clear context for when to use it. It lacks explicit 'when not to use' or named alternatives, but the use cases are specific enough.
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 exist, so the description must carry transparency. It does explain the execution effect (runs once, on demand) and the mode-dependent behavior. However, it doesn't disclose side effects like whether this consumes data, whether it can be called repeatedly, or any destructive impact on the processor state or its scheduled outputs.
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?
Two paragraphs, front-loaded with the core action in the first sentence. The second paragraph explains mode differences efficiently. Every sentence earns its place, though the paragraph break could be tightened. No wasted words.
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?
An output schema exists, so return-value documentation is handled. Given this is a moderately complex on-demand execution tool with mode-dependent behavior, the description covers execution semantics well. It could add more about repeated invocations or interactions with scheduled outputs, but the core use case is adequately explained.
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 100%, so all parameters are documented. The description adds context around the 'seconds' and 'filtered' parameters (window length and overriding declared preference), which is implied in the schema descriptions but clarified. This goes somewhat beyond bare parameter definitions, though most weight settles on the schema.
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 states a specific action ('Run a processor once on the most recent window, on demand') with a clear resource (processor) and context (mode). However, it doesn't explicitly distinguish from sibling tools like get_processor_output or processor_status, which could be conflated. The verb+resource is clear but sibling differentiation is limited.
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 the usage context well: for non-streaming processors it's the only execution path, and for streaming ones it provides on-demand answers. This gives clear when-to-use guidance. However, it doesn't mention exclusions or when NOT to use it (e.g., when scheduled output is acceptable for streaming).
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 full burden. It discloses the behavioral effect (reads return raw signal), which for a destructive/state-changing action is meaningful. It doesn't state whether filters are permanently lost or recoverable, which would be useful, but the core behavior is conveyed.
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, zero wasted words. Every element adds value: the action, the target, and the observable consequence. Ideal length for a single-parameter tool with no additional configuration.
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 (one required param, no enums, no nesting) and an output schema exists. The description covers the action and its effect on read behavior. Sibling set_filters provides the natural counterpart. Could mention that this is a state-mutating operation, but the description is adequate for a simple filter-clearing 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?
Schema coverage is 100% for the single session_id parameter, which is well described as 'The session to clear filters on.' The description adds contextual meaning by clarifying the observable effect on reads for that session. No parameter gaps to compensate for.
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 'Remove the filter chain; reads return raw signal again' clearly states the verb (remove) and resource (filter chain), and adds the consequence (reads return raw signal). It distinguishes from its sibling set_filters. However, it doesn't explicitly name the sibling for contrast.
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 it (when filters are active and you want to return to raw signal) but does not explicitly state when-not-to-use or name alternative tools. The inverse relationship with set_filters is implicit but not articulated.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds valuable operational details: the auto-disable behavior after 10 raises, the poll interval default of 50ms, and the relationship to throughput_ratio in stream_status. This is meaningful transparency about system behavior beyond a simple read operation, though it doesn't state whether the tool itself has side effects or is purely diagnostic.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The additional diagnostic nuance (poll interval, disable-after-10, throughput_ratio) is concise and earns its place. Slightly verbose in the middle section but every sentence contributes meaningful operational context.
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?
An output schema exists, so return-value documentation is covered structurally. The tool is diagnostic in nature with one parameter, and the description covers purpose, metrics interpretation, and failure behavior. While it doesn't explicitly describe the return structure, the output schema handles that, making the description reasonably complete for a reporting tool.
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 100%, so the single session_id parameter is already fully documented in the schema. The description adds no additional parameter-level detail beyond what the schema provides, which meets the baseline 3 for full coverage.
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 reports attached processors, their health, and their cost. The verb 'report' with specific resources (processors, health, cost) makes the purpose explicit. While sibling tools like list_processors exist, the health/cost focus differentiates this tool's reporting function from a plain listing.
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 strong diagnostic context on what metrics to watch (mean_ms, max_ms vs the poll interval) and explains the starvation scenario, but it does not explicitly state when to prefer this tool vs the sibling list_processors or stream_status. The guidance about throughput_ratio referencing stream_status implies related tools 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?
No annotations are provided, so the description carries the burden. It lists the four control verbs but doesn't disclose behavior like whether 'status' returns session state, whether actions are safe/non-destructive, whether calling actions on a non-existent session errors, or what the output schema looks like. However 'status' action hints at query capability. Partial transparency; doesn't add depth beyond the verb list.
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?
Single concise sentence listing all supported verbs. Zero wasted words, front-loaded with the action verbs. Efficient and immediately parsable by an agent.
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 control tool with 100% schema coverage and an output schema present, the description covers the core verbs adequately. The action parameter with its enum-like list and per-parameter conditionality are handled by the schema. Could be slightly richer by noting the 'status' action returns current state, but schema and output schema fill most gaps. Reasonably 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?
Schema coverage is 100% and each parameter has a useful schema description (required for action='speed', required for action='seek', session created by start_replay). The description lists action verbs which complement the schema's action list. The description doesn't repeat parameter info, allowing the schema to carry that weight. Slight gap: no mention of what values speed accepts, which the schema also omits beyond 'number'.
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 uses a specific verb+resource pattern: 'Pause, resume, seek, or change the speed of a replay session.' It clearly enumerates the four primary actions and distinguishes the tool from siblings like start_replay (which creates sessions) and list_sessions (which enumerates them). 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (controlling an in-progress replay session) but doesn't explicitly define when to use it versus alternatives. It doesn't mention that session must be started first via start_replay (though session_id schema field hints at it), nor does it explain when to use seek vs speed vs status actions. Adequate but lacks explicit when/when-not guidance.
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?
With no annotations provided, the description carries full behavioral disclosure burden, and it does so excellently. It explicitly discloses the deliberate expiry behavior ('arming expires deliberately'), the rationale (prevent stale resumption), and recommends disarmament. This is rich behavioral context that the schema cannot convey.
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 compact and front-loaded, with the core purpose in the first sentence and behavior/guidance in the subsequent sentences. The prose about expiry rationale is somewhat verbose for a tool description but earns its place by conveying important behavioral transparency an agent needs. Slightly long but not bloated.
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?
This is a stateful arming tool with security-relevant behavior (expiry), and the description adequately covers the key operational concerns. With an output schema present and full parameter coverage, the description doesn't need to explain return values. The guidance about re-arming and disarming completes the operational picture reasonably well.
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 100%, so the schema already documents all three parameters (backend, ttl_sec, session_id) thoroughly. The description adds 'bounded window' context that relates to ttl_sec but doesn't add syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 states 'Permit hardware stimulation for a bounded window', which clearly identifies the verb (arm/permit) and resource (hardware stimulation) with a temporal bound. It distinguishes from sibling tools like disarm_stim (disarming) and send_stim_train (sending a stim), though it doesn't explicitly name the sibling alternative it contrasts with.
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 usage guidance: 'Re-arm as needed, or disarm the moment a block ends.' It explains the deliberate expiry mechanism and implies the recommended workflow. However, it doesn't explicitly say when NOT to use this tool or name alternative tools for specific scenarios, though the context around arming vs disarming is reasonably 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly explains the tool's role as a safety/precheck gate and the failure modes it detects (flat/railed electrode poisoning references and thresholds). However, it doesn't describe the return format (output schema exists but the description doesn't explain what the output contains), return semantics, or any side effects. The behavioral insight about flat/railed poisoning is valuable, but for an analysis tool without annotations, more disclosure would help.
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 purpose concisely. The second sentence delivers high-value usage guidance in two sentences — a concrete call-to-action ('call before trusting') and a vivid consequence example. Every sentence earns its place with no fluff or restatement.
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 has an output schema (present but not shown), all parameters are covered by the schema, and the description adds the critical 'when to call' context and failure-mode reasoning. For an analysis/precheck tool with full schema coverage and an output schema, this description is complete — it tells the agent what the tool does, when to use it, and why it matters.
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 input schema has 100% description coverage across all three parameters, so the schema already documents seconds (window length), line_freq (mains frequency), and session_id. The description doesn't add parameter-level meaning beyond what the schema provides; it focuses on overall behavior rather than specific parameters. With 100% coverage, the baseline of 3 is appropriate.
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 states a clear purpose: 'Per-channel health check' covering amplitude, flat/railed detection, and line noise. It distinguishes itself from siblings that manipulate streams, filters, or recordings. However, it doesn't explicitly name which sibling tools compete with it (e.g., get_band_power, get_psd) for signal-quality assessment, so differentiation is implicit rather than named.
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?
The description gives explicit guidance on when to use it: 'Call this before trusting any real-time feature, and definitely before driving stimulation from one.' It also explains the consequence of skipping it (a flat/railed electrode poisons average reference and band-power threshold without being visible in the feature value itself), which strongly implies when NOT to skip this tool. This is clear, actionable context.
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 full burden. It discloses noteworthy behavior: everything is inlined for portability, no internet required, long-term renderability. It does not describe output file type, size implications, or whether this is a read-only operation, but the portability behaviors are genuinely useful disclosures beyond what schema conveys.
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 content is compact and front-loaded — a clear first sentence states the purpose, a brief second paragraph explains the portability benefit. No wasted words. Minor deduction for not specifying output format/location, but the prose is tight and well-organized.
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 having 4 parameters and an output schema, the description is reasonably complete given the schema coverage is 100% and an output schema exists (which handles return-value explanation). Sibling tools are mostly granular operations (get_psd, plot_spectrum), so this aggregate export tool's role is clear. Could add the output file format/extension, but overall adequate.
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 100%, with well-described parameters (notes, seconds, session_id, include_spectrum all have meaningful descriptions). The description adds context that the tool aggregates traces/spectrum/quality/event log, which hints at how parameters map to sections, but doesn't add meaning beyond what the schema already provides. Baseline 3 is appropriate given full coverage.
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 verb ('Write a full review page') plus the resource ('the one artefact to keep from a session'). It enumerates contents (traces, spectrum, quality, event log) and distinguishes itself from sibling plotting/recording tools as a comprehensive export artifact rather than a single-view operation.
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 clearly implies when to use it: when you want a permanent, self-contained record of a session ('the one artefact to keep'). It explains the context (opens on any machine, needs no internet, renders years from now). It doesn't explicitly name alternative tools or exclusion criteria, but the framing as the canonical archive tool differentiates it well.
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 of behavioral disclosure. It explicitly states the stream continues running and that the signal buffer is untouched ('The signal buffer is untouched'), which is valuable behavioral context. It implicitly signals this is a destructive operation (clearing the log). For a simple tool with no annotation safety profile, this is commendable 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?
Two brief sentences with zero waste. The first sentence states the core action and its limitation (doesn't stop stream), the second adds usage context and a safety note (signal buffer untouched). Every sentence 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 tool with one parameter, an output schema, and 100% schema coverage, the description is sufficient. It explains the purpose, when to use it, and the side-effect boundary (stream continues, buffer untouched). This covers the essential context an agent needs 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'session_id' is described as 'The session whose log to clear,' which fully explains its semantics. The description itself doesn't add beyond the schema, but with only one well-documented parameter, the baseline of 3 is appropriate since the schema does the heavy lifting.
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 'Empty the session's event log without stopping the stream' — a specific verb ('empty'), resource ('event log'), and scope ('without stopping the stream'). It distinguishes itself from sibling tools like 'get_events' (read), 'log_event' (add), and 'clear_filters' (different resource).
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 stating 'Useful between blocks of an experiment,' indicating when (between experimental blocks) to use this tool. It also clarifies that clearing the log does not stop the stream, which helps an agent know when this is appropriate. However, it doesn't explicitly name alternatives (like what to use if you want to retain events) or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a non-obvious behavior: the event is logged to the session log even if the transport fails, and it is also punched into the acquisition stream when markers are supported. This goes beyond a simple 'deliver' and gives valuable operational insight.
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 paragraphs. The first sentence states the primary action, and the second explains logging and stream marker behavior. Every sentence earns its place; no redundancy or filler.
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 has 11 parameters but the schema fully documents them, and an output schema exists so return values need no explanation. The description covers the core purpose and key behaviors (failure logging, stream marking), which is sufficient for an agent to select and use the tool correctly.
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 100%, so every parameter is already described. The description adds some context (e.g., 'logged against the EEG clock', marker behavior) but does not elaborate on specific parameters beyond what the schema provides. Thus the baseline 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 opens with 'Deliver one stimulation command, and log it against the EEG clock', using a specific verb and resource. It clearly distinguishes itself from sibling tools like send_stim_train (train vs. one command) and arm/disarm_stim (delivery vs. setup).
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 establishes clear context: it delivers a single stimulation command and logs it. While it does not explicitly name alternatives or exclusions, the phrase 'one stimulation command' implicitly separates it from send_stim_train and other siblings. No when-not-to-use guidance is given, but the purpose is focused enough.
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?
No annotations are provided, so the description carries the full burden. It discloses the online nature and the ring-buffer constraint with a concrete example (default 60s buffer = last minute), which is meaningful behavioral context beyond the schema. It doesn't mention decimation/page limits or what happens when the event is no longer in the buffer, but the disclosure provided is substantive.
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 — two short paragraphs with effectively three sentences. Every sentence earns its place: it names the action, gives concrete use cases, and states the critical timing constraint. No filler or redundancy.
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?
With 7 parameters fully documented in the schema and an output schema present, the description's job is moderate. It handles the online-epoaching rationale and the ring-buffer constraint, which are the non-obvious aspects an agent needs. It could mention the decimation/max_samples behavior or failure modes, but for an online inspection tool with rich schema coverage, this is reasonably 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?
Schema coverage is 100%, so baseline is 3, but the description adds context explaining that 'label=None' takes the most recent event of any kind — though this is also in the schema. The description's online/window framing groups the tmin/tmax parameters conceptually. It doesn't add much beyond the schema's already-thorough parameter documentation, but the description reinforces the temporal semantics implicitly.
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 extracts 'the signal window around an event that already occurred.' It gives specific use cases (inspect response to recent stimulus, verify stimulation artifact placement) that distinguish it from sibling epoching/stream tools like read_window and get_events.
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 for when to use it ('inspect the response to the most recent stimulus, or verify a stimulation artifact lands where you expect') and states the key constraint (event must be inside the ring buffer). It doesn't explicitly name alternative tools or exclusion cases, but the online-epoching framing distinguishes it from recording-based tools.
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 full burden. The description does disclose the tool's behavioral trait of opening without starting playback (non-destructive inspection). However, it doesn't disclose details about return format, potential errors with unsupported file types, or behavior when path is invalid. The 'describe it without starting playback' is useful but limited.
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: one concise statement of purpose and one clear usage directive. Zero filler, every sentence earns its place, and the key differentiator (no playback) is front-loaded.
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 has an output schema (which presumably documents return structure), full schema parameter coverage of 100%, and only 1 required param. Given these, the description sufficiently explains what the tool does and when to use it. It could add a touch more on error handling or file-type edge cases, but the provided context is solid for a relatively simple 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?
Schema coverage is 100% with good descriptions for all 3 parameters. The description additionally explains the purpose of the max_events cap (limiting event listing) and clarifies the board param is only needed for BrainFlow CSV. The description adds contextual meaning around the schema fields, particularly connecting the parameters to the tool's purpose of answering questions about the recording.
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 a specific verb+resource action: 'Open a recording and describe it without starting playback.' It explicitly distinguishes from the sibling tool start_replay by noting this tool inspect the recording without playback. This is clear and non-tautological.
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?
The description explicitly says 'Use this before start_replay' and explains what it's used for: seeing how long the file is, what channels it has, and which annotations will be re-emitted as events during replay. This provides explicit when-to-use context with a named alternative 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?
No annotations are provided, so the description carries some burden. It's a non-destructive listing tool (read-only intent is clear), but it doesn't explicitly disclose safety profile like readOnlyHint would. However, the purpose inherently signals enumeration/read, and mention of SYNTHETIC_BOARD for development adds behavioral context. The description names what's returned (names, ids, rates, channel counts) which adds some transparency but doesn't explain return format or error cases.
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 compact and front-loaded with the primary purpose. Every sentence earns its place: the main listing intent, the 'start here' guidance, and the two no-hardware special cases, plus the returns summary. Slightly verbose in the returns section but otherwise tight and well-structured.
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 zero-parameter enumeration tool with an output schema present, the description is complete. It covers purpose, return contents, special no-hardware boards, and when to use it. The output schema handles return details, so no additional description burden exists. This is a fully adequate description for this simple 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 0 parameters, so the description only needs to convey what the no-arg call returns. With zero params, the baseline is 4. The description does clearly enumerate the return fields (board names, ids, sampling rates, EEG channel counts), which is useful context beyond the empty schema. It fully compensates since there are no parameters requiring explanation.
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 a specific verb+resource ('List every board BrainFlow can acquire from') and clearly scopes it by listing what's returned: names, ids, sampling rates, and EEG channel counts. It distinguishes this from the large sibling set by being the only discovery/enumeration tool for boards, clearly different from session, stream, event, and stim tools.
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?
The description explicitly says 'Start here when you do not know what hardware is available,' giving a concrete when-to-use cue. It also notes that two entries need no hardware (SYNTHETIC_BOARD and PLAYBACK_FILE_BOARD) and explains what they do, helping the agent pick appropriate boards for development and replay scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the blocking behavior, the hard caps (1000 pulses, 60s), and a subtle behavioral trait: every pulse is logged individually so the event log reconstructs exact delivered timing rather than intended timing. This is genuinely valuable behavioral context beyond what the schema provides.
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?
Four tight, front-loaded sentences. The first sentence states the core action, the second states when to use it, the third covers constraints and guidance, and the fourth reveals the logging behavior. Zero filler words, every sentence 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 has a complex delivery behavior (blocking, caps, per-pulse logging) and an output schema exists. The description covers the safety caps, blocking semantics, logging behavior, and provides construction advice for longer protocols. It's complete for the complexity level, though it could theoretically mention prerequisites like backends being attached, but those are covered by sibling tools and schema.
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 100% (all 8 params documented in schema), so baseline is 3. The description adds value by clarifying that label serves as a base event name with pulses logged as '<label>_<n>', which deepens the parameter semantics beyond the schema's 'Base event name' note. It also contextualizes interval_ms as 1000/frequency for rTMS. The main description doesn't enumerate params, but the schema already handles that well.
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+dose+resource: 'Deliver a regular train of pulses, blocking until it completes.' This clearly distinguishes it from siblings like log_event (single event logging) and arm_stim/stim_status which are for arming/monitoring rather than delivering pulses.
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 it's for rTMS bursts and repeated cues, provides a clear use case. It notes that calling blocks until completion with caps at 1000 pulses/60 seconds, advising to build longer protocols from multiple calls for decision points. However, it doesn't explicitly name alternative tools to use instead, only describes intra-tool guidance.
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?
No annotations are provided, so the description carries full burden of behavioral disclosure. It discloses that the raw unfiltered signal is written, that filter settings are stored alongside for reproducibility, and critically that the amplifier's actual output is not reconstructible from anything else. This is rich, useful behavioral 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?
Three short paragraphs, dense with useful information, no filler. Each sentence earns its place. Slightly longer than strictly necessary but every sentence adds value about when to use, data retention, and file format.
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?
Has an output schema for return value reference, 100% schema coverage on parameters, and the description covers timing, data-retention risk, formatting, and reproducibility. For a started-recording command this is comprehensively documented.
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 100%, so parameters are all documented in the schema. The description adds no per-parameter detail beyond the schema, but it does clarify the recording behavior (raw, unfiltered). Baseline 3 is appropriate since the schema handles parameter documentation fully and there are no undocumented semantics to compensate for.
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 states a specific verb+resource ('Begin writing the live signal to disk, continuously') which clearly distinguishes it from siblings like start_stream, stop_recording, and start_replay. It's unambiguous what the tool does and how it differs from adjacent recording/streaming tools.
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?
Explicitly instructs to call it at session start if data is intended to be kept, and warns about the ring buffer's short retention window. This clearly differentiates when to use this vs. when data would be lost, and contrasts with stream-only tools.
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 of behavioral disclosure. It transparently explains the side effects: the event log becomes annotations in the file, a metadata row is inserted by default, and raw crash-recovery files are normally removed after conversion. It also surfaces the register=false and keep_sidecar escape hatches, which reveals mutating behavior and cleanup semantics.
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, with the primary purpose in the first line and supporting detail in a follow-up paragraph. Every sentence adds information that is not redundant with the schema — no filler, no repetition of parameter names without added meaning.
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 has 3 parameters (all documented), an output schema, and no nested objects, so complexity is moderate. With no annotations, the description must compensate, and it does a good job disclosing the primary side effects (file writing, metadata insertion, crash-file cleanup) and the register/keep_sidecar options. It doesn't enumerate potential failure conditions or what the output schema contains, but with an output schema present, return-value explanation isn't strictly required.
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 100%, so all three parameters are already described in the schema. The description adds contextual meaning beyond the schema by explaining what 'register' actually does (inserts a row with subject/task/run/provenance into the metadata store) and why keep_sidecar exists (raw crash-recovery files are normally removed). This adds real value over the bare 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 clearly states the tool's verb (finish the recording), the resource (active recording session), and the specific actions performed: writing the .fif file and registering it for analysis. It distinguishes itself from siblings like stop_stream (which stops a data stream) and recover_recording (which handles crash recovery) by focusing on finalizing a recording into a file.
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 clearly says when this tool is used: to finish a recording session and produce a persistent .fif file for analysis. It explains the optional register=false path for skipping metadata insertion, giving the agent context on when to override the default. However, it doesn't explicitly name alternative tools or state when NOT to use it, though the sibling list makes this fairly evident.
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?
While no annotations are provided, the description fills that burden by disclosing the destructive/finalizing nature of the operation: it releases board, serial ports, and LSL outlets. It also warns about resource blocking consequences. It doesn't detail irreversible side effects (e.g., data loss for active recording), but genuinely conveys the teardown behavior.
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?
Extremely economical: one clear sentence stating the action and its full scope, followed by a terse imperative with concrete motivation. Every sentence earns its place; no filler or redundant restatements of the name.
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?
A simple one-param teardown tool with 100% schema coverage and an output schema present. The description adequately conveys purpose, scope of cleanup, and when to call it. Could marginally mention effects on active recordings, but for a teardown tool with good schema support, this is largely complete.
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 100% and the single param (session_id) is documented as 'The stream to stop.' The description references 'a stream' which maps to session_id implicitly. There's no added format/validation detail, but with full schema coverage and a single obvious parameter, the baseline 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 uses a specific verb ('Stop') with a clear resource ('a stream') and lists what gets released (board, serial ports, LSL outlets). It clearly distinguishes from sibling tools like start_stream and stream_status by specifying the full teardown scope — this is a teardown/completion operation.
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?
Explicitly states 'Always call this when finished' and explains the negative consequence of not calling it: 'A board left prepared can block the next process from acquiring the device.' This gives the agent clear when-to-use guidance and a concrete reason, contrasting with the start_stream sibling.
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 clearly discloses that the tool returns failed-to-load plugins so typos are visible, and explains the architectural constraint preventing runtime loading (arbitrary code execution). The security rationale adds genuinely useful behavioral context beyond bare functionality.
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?
Well-structured with the purpose line first, a clear explanation paragraph, and a marked 'Returns' section. Efficient use of space; each sentence contributes meaning. Slightly longer than strictly minimal, but all content is substantive rather than 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 zero-parameter enumeration tool with an output schema present, the description covers purpose, source/provenance, loading behavior, and failure visibility. The return-value details are useful supplement to the output schema. Coverage of why runtime loading is disallowed adds valuable completeness around constraints.
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 0 parameters, so the schema fully describes the input surface. The description compensates by explaining what the return payload will contain (available processors with parameters plus failures), which is itself a form of parameter/output semantics. Baseline for 0 params is 4, and the description earns it by describing the result composition.
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?
Uses a specific verb+resource combination ('List real-time processors available to attach') and clearly states the scope ('and where they came from'). It distinguishes its purpose from siblings like attach_processor, processor_status, and run_processor by focusing on enumeration of availability and provenance.
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?
Explicitly explains when processors appear versus when they don't, naming the three server-side loading mechanisms (entry point, EEG_MCP_PLUGINS, EEG_MCP_PLUGIN_DIR). It also clearly states an exclusion ('cannot be loaded from a tool call') and justifies it with a security rationale, giving the agent concrete guidance on expectations.
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?
No annotations are provided, so the description carries the full burden. It discloses that this is a frozen snapshot (non-live), produces a standalone self-contained file, and returns a path. It doesn't state whether existing files get overwritten or cleanup behavior, but given the tool generates a new output artifact this is reasonable coverage without annotation support.
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, with a clear first sentence stating the primary function and a second sentence providing purpose/context in exactly two short paragraphs. Every sentence earns its place — no filler or redundancy.
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 has 100% schema coverage on 5 parameters, an output schema indicating return structure, and the description explains the output format (HTML file path), the standalone nature, and disambiguates it from start_monitor. For a rendering/plot tool this is complete coverage with no apparent gaps.
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 100%, so all 5 parameters are already documented in the schema. The description adds marginal context by framing the output as a 'frozen snapshot' but doesn't elaborate on parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema carries the documentation load fully.
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 renders the recent signal as a standalone HTML file and returns its path. It uses a specific verb (render) plus resource (signal) plus output format (HTML file), which clearly distinguishes it from the sibling tools like start_monitor and plot_spectrum.
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?
Explicitly differentiates from start_monitor ('unlike start_monitor') and gives concrete use cases: 'keep a record, attach to a note, or share.' It also notes the file inlines everything and needs no internet, enabling use in offline/standalone contexts. This is strong when-to-use guidance with an explicit alternative named.
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 clearly discloses the security posture: bound to 127.0.0.1 only, requires a random per-monitor token, and unencrypted. It describes what the page renders (rolling traces, event markers, band power, per-channel quality) and the control-button behaviors. It doesn't explicitly state the return value format, but an output schema exists. Solid coverage for an unannotated 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 well-structured and front-loaded: first sentence states the core action, then a paragraph on rendering, then the allow_control distinction, then security. Every sentence earns its place and there is no fluff or repetition.
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?
This is a moderately complex tool with 5 params and an output schema. The description covers the use case, the difference between control and read-only modes, the security posture, and all parameter semantics are already in the schema. The network-binding caveat is an important operational detail an agent would need. This is complete for an agent to invoke correctly.
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 100%, so the schema already documents all 5 parameters well (port, refresh_ms, session_id, window_sec, allow_control all have clear descriptions). The tool description adds incremental value by explaining the behavioral meaning of allow_control (enables transport buttons) and noting window_sec is adjustable in-page. This matches the baseline-3 expectation for high schema coverage.
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 a specific verb+resource ('Open a live browser view of a running session and return its URL') and clearly distinguishes itself from static plot alternatives ('a static plot cannot answer whether the signal is good *now*'). It also differentiates this monitor tool from related sibling tools like plot_stream, start_replay, and inspect_recording.
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?
The description explicitly states when to use this tool ('This is the tool for let me watch the recording'), gives a concrete use case for when to use allow_control=false ('showing the screen to someone who should not be able to alter the run'), and contrasts it against static plots. It also warns against tunneling due to lack of encryption.
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 behavioral transparency burden. It does disclose non-obvious behaviors: data flows into a ring buffer from a background thread immediately, the session persists asynchronously, and read_window will have samples waiting. However, it doesn't disclose error conditions (e.g., invalid board name, connection failure), resource implications, or whether this mutates any persistent state. The key asynchronous behaviors are covered, but the failure/cleanup story is incomplete.
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 opening line states the core action, and immediately telegraphs the async/pre-buffering behavior. Every sentence earns its place: the ring buffer behavior, the read_window implication, and the stop_stream lifecycle note all add value without repetition. There is zero wasted verbiage.
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 tool with 100% schema parameter coverage and an output schema present, the description covers the essential behavioral context well. It explains the background-thread buffering semantics, the prerequisite relationship with read_window, and the termination contract with stop_stream. Given the tool's moderate complexity (4 params, all documented) and the presence of an output schema, this is complete enough for an agent to use it 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?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds lifecycle context around session_id (referenced as a persistent name for later calls) and implies the board/params relationship. The session_id semantics ('Name you will pass to every later call') is enriched by the description's context about the session keeping running. This meets the baseline 3 and adds a bit more value by explaining the session_id's cross-call role.
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 what the tool does: opens a board and begins buffering EEG in the background. It uses specific verbs (open, begin buffering) with a specific resource (board/EEG). It distinguishes itself from siblings like start_replay (which is for playback) and stop_stream (which is the inverse), and clarifies it's distinct from start_recording.
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?
The description explicitly explains when this tool is needed (before read_window calls) and what happens upon invocation (samples will be waiting), plus the lifecycle is made clear ('session keeps running until stop_stream is called'). It also references list_boards for board options via the schema, providing a clear alternative/discovery path.
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 of behavioral disclosure. It explains the behavioral differences between streaming and non-streaming modes, describes the performance implications (mean and worst-case times via processor_status), and notes the operational consequence (slow streaming code stalls acquisition). It doesn't cover edge cases like duplicate attachments or error handling, but the core behavioral traits are well disclosed.
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 well-structured and efficient, with a clear opening sentence followed by two focused paragraphs explaining streaming and non-streaming behavior. Every sentence adds value—none are filler. The use of code-formatted tool names ties it to other tools without wasting words.
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 has 3 parameters (100% schema covered) and an output schema, so much is handled by structured data. The description explains the critical semantic distinction (streaming vs non-streaming) that affects usage decisions. It could mention what the output/return value contains, but given that an output schema exists, this is adequately 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?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds context beyond the schema: it clarifies how the streaming vs non-streaming distinction relates to behavior, which helps the agent understand the implications of choosing certain processor types. However, it doesn't directly elaborate on the params field beyond what the schema says ('see its params in the listing').
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: "Attach a processor to a session." It distinguishes this from sibling tools like run_processor, detach_processor, and processor_status by explaining the attach action explicitly. The distinction between streaming and non-streaming processors further clarifies what this tool accomplishes.
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?
The description provides excellent usage guidance by distinguishing when each mode is appropriate: streaming for closed-loop logic requiring fast reaction within a poll interval, while noting the trade-off (slow code stalls acquisition). It also names related tools (processor_status, run_processor) that complement or follow this one, giving the agent clear context on when to use this vs 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?
No annotations were provided, so the description carries the full burden. It discloses the key behavioral trait that distinguishes this tool: it surfaces unreached events, not just those already emitted. The max_events cap behavior is disclosed via schema. Given no annotations, the description adds meaningful behavioral context, though it could note more about reading from a file vs live data or error 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 concise: one opening sentence stating the tool's purpose, followed by a focused two-sentence contrast with get_events. Every sentence adds distinct value with zero waste, and the most important clarifying information is front-loaded in the differentiation note.
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 moderately complex (reads from a session source file, has a cap parameter, and is distinguished from a sibling). The description fully explains the purpose and the differentiation from get_events, which is the key contextual concern. An output schema exists so return-value documentation isn't strictly required. A small gap is not mentioning what happens when max_events is unbounded or whether events are returned in chronological order, but the core is well covered.
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 100% and both parameters are well-documented in the schema (max_events cap, session_id). The description adds contextual value by framing session_id as tied to a replay session's source file, clarifying the relationship to start_replay. The description technically overrides a literal file-source ambiguity, though it doesn't go beyond schema deeply.
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 a specific verb+resource: 'List all events present in a replay session's source file.' It explicitly distinguishes itself from the sibling tool get_events, clarifying that this returns the *complete* event list from the file including not-yet-reached events, whereas get_events returns only what has been emitted so far. This is a clear, differentiating purpose.
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?
The description explicitly contrasts with get_events, naming the alternative and explaining the exact difference: list_recording_events returns the complete file contents while get_events returns only what was emitted so far. This provides clear when-to-use versus when-not-to-use guidance by naming the sibling and the contextual distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: events are recorded against the stream clock, the value is also written to a marker channel when mark_in_stream is set, and BrainFlow reserves 0 so a nonzero value is required. This is meaningful context beyond the schema. Minor gap: it doesn't describe the return/acknowledgement of successful logging.
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?
Extremely concise. The purpose is front-loaded in the first sentence, followed by two short sentences that clarify scope (what counts as a manual event) and the exclusion note about send_stim_event. Every sentence earns its place with zero 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?
The tool has 6 parameters, an output schema, and 100% schema coverage. The description adds the crucial manual-vs-automatic event distinction and the marker channel caveat. For a logging tool this is largely sufficient. Slight gap: it doesn't mention whether events can be queried later via get_events, though the output schema presumably covers return structure.
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 100% and all 6 parameters are individually described in the schema. The description adds contextual nuance to 'value' (marker channel writing, BrainFlow reserve) and to 'label' via practical examples. The novel addition is the mark_in_stream behavior interplay with the value field, which goes beyond schema text.
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 a specific verb+resource ('Record an event against the stream's clock') and lists concrete example use cases (task onset, subject report, experimenter note). It distinguishes itself from the sibling send_stim_event by explicitly noting stimulation commands are logged automatically by that tool and should not be logged by hand here.
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?
Explicitly says when to use: for anything the server did not generate itself. Explicitly says when NOT to use: stimulation commands, which are logged automatically by send_stim_event. This names the specific alternative tool and states the exclusion clearly.
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?
The description transparently discloses a critical limitation: events are not recoverable since they lived in memory, so the output file has signal without annotations. This is valuable behavioral context beyond any annotation. However, with no annotations at all, the description carries full burden and could also mention success criteria or failure modes, keeping it just below 5.
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 tightly organized: opening verb statement, mechanism explanation, usage instruction, and limitation note. Every sentence earns its place with no filler or redundancy. Fairly compact for the depth it provides.
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?
There is an output schema present, so return-value explanation is not needed. The description covers the recovery mechanism, the target artifact, and the key loss tradeoff. The only minor gap is no explicit mention of whether the original header remains intact or is consumed, but given the output schema and solid prose this is quite 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?
Schema coverage is 100%, with header_path and keep_sidecar both described in the schema. The description adds context on header_path by calling it an 'orphaned' file and clarifying its role, which adds meaning beyond the schema. With full schema coverage, baseline is 3, and the description's nuance on the header file bumps it to 4.
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 recovers an interrupted recording by converting an orphaned header file to a .fif. It uses specific verbs ('finish', 'convert') and names the resource (.eegmcp.json header). It effectively distinguishes from siblings like start_recording/stop_recording by addressing the failure-recovery niche.
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?
The description explicitly explains when to use this: when a recording process died before closing, point it at the orphaned .eegmcp.json header. It provides concrete context ('Samples are appended to disk as they arrive and the header is written up front') that clarifies the scenario this tool is designed for and implies it is not for normal recording closure.
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 full behavioral disclosure burden and largely delivers: it explains the wall-clock timing behavior, that annotations arrive at original timings, the identical buffering/chunking behavior to live streams, and the 'safe' framing implies non-destructive semantics. The description could add more on return values or side effects beyond event emission, but the core behavioral character is well disclosed.
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 tight paragraphs, zero filler. The opening line states the action, the second paragraph justifies why this tool exists (safe real-time pipeline building, code-portability promise), and the third closes on a specific behavioral guarantee. Every sentence earns its place and the most important information is front-loaded.
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?
This is a moderately complex tool with 8 parameters and an output schema, yet the description plus schema cover the use case thoroughly: when to use, how it behaves, key shortcuts (path resolution), and parameter meanings. An output schema exists so return value documentation isn't strictly required. The description is complete enough to guide correct selection and invocation, though a note on stopping/replay_control coordination could slightly enhance completeness.
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 100% and every parameter already has rich inline documentation (loop semantics, speed interpretation, start_sec offset, board requirement for BrainFlow, picks defaults, session_id usage). The description adds the key architectural context that parameters like speed and loop map to realistic-latency tradeoffs and long-running rehearsal use cases, reinforcing the schema. The description and schema together are quite complete; the marginal value added by the description's prose on parameters is moderate but real.
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 combination: 'Replay a recording against a wall clock, re-emitting its events.' It clearly distinguishes start_replay from sibling tools like start_stream (live data) and start_recording (capturing), establishing itself as the playback-side complement. The purpose is unambiguous and the scope is precisely defined.
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?
The description explicitly frames this as 'the safe way to build a real-time pipeline' because the session behaves exactly like a live stream with identical buffering, chunked delivery, and tools. It explains this is preferred over live hardware for development because code runs unchanged against hardware, giving a strong when/why directive. No explicit when-not guidance, but the contrast with live streams and the pipeline-building context serve as clear usage framing.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently discloses the decimation/limit behavior ('Long windows are decimated to max_samples per channel'), the filtering behavior depending on filter chain state, and the data-quality tradeoff. It doesn't mention the return format in detail, but an output schema exists to cover that.
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—two short sentences plus a parenthetical—with zero wasted words. Every sentence adds value: first states purpose, second discloses behavior and provides navigation to alternatives. Front-loaded with the primary action.
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 output schema exists, return-value explanation is not needed. The description covers the key behavioral caveats (decimation, filtering dependency) that an agent must understand to use the tool correctly. The alternative-tool guidance fully compensates for the tradeoff introduced by decimation. Complete for a signal-read tool with this level of complexity.
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 100%, so the baseline is 3. However, the description adds meaningful context beyond the schema by explaining the decimation interaction with max_samples and explicitly steering toward alternatives for full-resolution numeric work. The filter chain dependency of the `filtered` parameter is also contextualized.
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 ('Read the most recent samples from the buffer') and clearly distinguishes this from sibling tools by explicitly contrasting with get_band_power and get_psd. It specifies the read-only nature and buffer scope with high precision.
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?
The description explicitly states when NOT to use this tool ('for numeric work prefer get_band_power or get_psd'), names the alternative tools directly, and explains the context (filtered vs raw, decimation). It also references set_filters as a precondition, providing clear guidance on the workflow.
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?
No annotations are provided, so the description carries full burden. It discloses statefulness (filter state carried across chunk boundaries), causal-only limitation, output buffering behavior (raw available via read_window(filtered=False)), and group delay. This is rich behavioral context beyond 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?
Three concise paragraphs, each earning its place: what it does, why statefulness matters, and the causal/phase caveat. No fluff or repetition of schema content. Front-loaded with the core verb+resource statement.
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 stateful filter installation with 100% schema coverage and an output schema, the description is thorough: it covers operational semantics (background, continuous, causal), the buffer/raw-retrieval path, and how to verify output correctness (group_delay_sec). Output schema handles return-value documentation, and the description covers the behavioral gaps.
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 100%, so baseline is 3. The description adds value beyond schema: it explains the causal stateful behavior affecting all filter parameters, warns about boundary transients that corrupt phase-sensitive measures, and explains the group_delay_sec consequence of filters. However, it doesn't elaborate on parameter interplay (e.g., filters override vs the named arguments).
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 a clear verb+resource: 'Install a stateful online filter chain on a running stream.' It distinguishes from sibling tools like get_band_power/get_psd (analysis reads) and clear_filters (removal), and clarifies it operates on a live stream versus other tools. The scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when/when-not to use it: causal filters only, 'no zero-phase option, because that needs future samples.' It clarifies the continuous background filtering vs per-window filtering tradeoff and points to group_delay_sec for latency awareness. This is strong usage guidance.
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:

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

Score Badge

Copy to your README.md:

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

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