该项目将脑机接口 (BCI) 技术与模型上下文协议 (MCP) 相结合，为神经信号采集、处理和人工智能交互创建一个强大的框架。
BCI-MCP 结合了：
脑机接口（BCI） ：实时采集和处理神经信号
模型上下文协议（MCP） ：标准化AI通信接口
这种集成使得医疗保健、无障碍、研究和人机交互等领域的高级应用成为可能。
Related MCP server: MCP Hardware Access Library
神经信号采集：实时捕捉大脑活动的电信号
信号处理：预处理、提取特征和分类脑信号
命令生成：将解释的脑信号转换为命令
反馈机制：提供反馈以帮助用户提高控制
实时操作：以最小延迟处理大脑活动
标准化上下文共享：使用 MCP 将 BCI 数据与 AI 模型连接起来
工具曝光：让 BCI 功能可用于 AI 应用程序
可组合工作流程：构建结合 BCI 信号和 AI 处理的复杂操作
安全数据交换：实现隐私保护的神经数据传输
BCI-MCP系统由几个关键组件组成：
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ BCI Hardware │──────│ BCI Software │──────│ MCP Server │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └────────┬────────┘
│
│
┌────────▼────────┐
│ │
│ AI Applications │
│ │
└─────────────────┘Python 3.10+
兼容的EEG硬件（或使用模拟模式进行测试）
requirements.txt 中列出的其他依赖项
# Clone the repository
git clone https://github.com/enkhbold470/bci-mcp.git
cd bci-mcp
# Create a virtual environment
python -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install dependencies
pip install -r requirements.txt为了更容易设置，您可以使用 Docker：
# Build and start all services
docker-compose up -d
# Access the documentation at http://localhost:8000
# The MCP server will be available at ws://localhost:8765# Start the MCP server
python src/main.py --server
# Or use the interactive console
python src/main.py --interactive
# List available EEG devices
python src/main.py --list-ports
# Record a 60-second BCI session
python src/main.py --port /dev/tty.usbmodem1101 --record 60BCI-MCP 集成支持一系列尖端应用：
辅助技术：使行动不便人士能够控制设备
康复：通过实时反馈支持神经康复
诊断工具：辅助诊断神经系统疾病
神经科学研究：促进大脑功能和认知的研究
BCI 训练：加速学习和适应 BCI 控制
协议开发：建立神经数据交换标准
自适应界面：根据神经信号和人工智能辅助进行调整的界面
意图识别：通过神经信号更好地理解用户意图
增强沟通：增强言语障碍人士的沟通能力
项目文档托管在 GitHub Pages 上： https://enkhbold470.github.io/bci-mcp/
本文档使用 MkDocs 和 Material 主题构建。更新文档：
对main分支上docs/目录中的 Markdown 文件进行更改
提交并将更改推送到main分支
GitHub Actions 工作流程将自动构建更新的文档并将其部署到 GitHub Pages
要在本地使用文档：
安装所需的依赖项：
pip install mkdocs-material mkdocstrings mkdocstrings-python运行本地服务器：
mkdocs serve查看文档： http://localhost:8000
.
├── docs/ # Documentation files
│ ├── api/ # API Documentation
│ ├── features/ # Feature Documentation
│ ├── getting-started/ # Getting Started Guides
│ └── index.md # Documentation Home Page
├── mkdocs.yml # MkDocs Configuration
└── .github/workflows/ # GitHub Actions Workflows欢迎贡献代码！欢迎提交 Pull 请求。
分叉存储库
创建功能分支（ git checkout -b feature/amazing-feature ）
提交您的更改（ git commit -m 'Add some amazing feature' ）
推送到分支（ git push origin feature/amazing-feature ）
打开拉取请求
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅 LICENSE 文件。
Enkhbold Ganbold - GitHub 个人资料
Capture a baseline so focus/calm/etc. are personalized to the wearer.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No | ||
| condition | No | relax |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only says 'capture a baseline.' It does not explain whether the tool is read-only or destructive, whether it requires the device to be worn, or what happens during calibration (e.g., prompts or feedback). The description is too vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices informativeness. It could be restructured to front-load the key action and then include brief parameter hints, but currently it is too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema or annotations, the description should provide more context about calibration duration, conditions, and expected outcomes. The current description is insufficient for an agent to understand the full scope of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters ('seconds' and 'condition') with defaults, but the description does not mention them at all. With 0% schema description coverage, the description should compensate but fails to add any meaning beyond the schema, leaving the agent without guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to capture a baseline for personalization of focus/calm metrics. It distinguishes from sibling tools like 'get_band_powers' or 'start_neurofeedback' by focusing on calibration rather than real-time data or feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not specify that calibration should be done before using neurofeedback or that it may need to be repeated. The description lacks context for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to an EEG device and start streaming. Default is the synthetic brain.
| Name | Required | Description | Default |
|---|---|---|---|
| device_uri | No | synthetic:// |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should fully disclose behavioral traits. It mentions 'start streaming' but does not explain if the operation is blocking, how to stop it, or how multiple connections are handled. This lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences with no redundancy. It front-loads the key action. However, additional context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is somewhat complete for a simple connection tool, but it lacks context about prerequisites (e.g., device discovery) and the streaming lifecycle, which is important given sibling tools like 'stream_summary' and 'disconnect'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It notes 'default is the synthetic brain', which clarifies the default URI value. However, it does not describe the expected format or other possible device URIs, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect to an EEG device') and the result ('start streaming'). It also specifies the default synthetic brain, which distinguishes this tool from siblings like 'disconnect' or 'list_devices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'calibrate', 'list_devices'). There is no mention of prerequisites or best practices, leaving the agent without context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from the current EEG device.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'disconnect', failing to disclose behavioral traits like impact on ongoing sessions, required state, or side effects beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous information, well-suited for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description covers the core purpose adequately. However, it could mention that disconnection stops any active data flow or session for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter-level meaning. The schema coverage is 100%, justifying a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'disconnect' and the resource 'current EEG device', making the tool's purpose immediately obvious and distinguishing it from siblings like 'connect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to terminate a connection, but provides no explicit guidance on when to use vs. not use, nor alternatives. It is adequate but lacks depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get absolute and relative EEG band powers (delta, theta, alpha, beta, gamma).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether reading is instantaneous, requires prior connection, or any side effects. Minimal behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify return structure (e.g., units, dictionary keys). It only mentions 'absolute and relative' without further detail, leaving ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is irrelevant. The description adds meaning by specifying absolute/relative and listing bands, which compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves absolute and relative EEG band powers, listing five standard bands (delta, theta, alpha, beta, gamma). This distinguishes it from siblings like get_brain_state or get_signal_quality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_brain_state or get_neurofeedback_score. The context does not explain decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current brain state: focus, calm, attention, band powers, signal quality.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does not disclose behavioral traits such as read-only nature, whether it requires an active connection, or if it has any side effects. The description is too minimal for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, efficiently lists components. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema. The description provides a high-level summary of the return values. However, it could mention prerequisites (e.g., 'Requires a connected device') to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds value by listing the components of the brain state, which goes beyond the empty schema. Baseline for 0 parameters is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current brain state and lists specific components (focus, calm, attention, band powers, signal quality), distinguishing it from sibling tools like get_band_powers and get_signal_quality that are more targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings, but the purpose is implied. Lacks instructions on prerequisites like connection status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sample the current neurofeedback score (in-zone now + cumulative %).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation ('sample'), but does not disclose side effects, latency, or whether it requires a connection. For a zero-parameter tool, the description is adequate but could mention that it returns immediately or is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no superfluous words and efficiently conveys the core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking an output schema, the description partially explains the return value ('in-zone now + cumulative %') but is vague about the format (e.g., separate numbers, object). It does not specify if other data is included. For a simple tool, more clarity on the return structure would complete the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (trivial). The description does not need to add parameter details. Baseline score of 4 is appropriate as it provides no additional parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool samples the current neurofeedback score, specifying it includes 'in-zone now + cumulative %'. This distinctly identifies the resource and action, differentiating it from siblings like get_band_powers or get_brain_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_brain_state, get_signal_quality). The context of 'sample' vs 'get' is not clarified, and there is no mention of prerequisites or context where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get electrode signal quality and detected artifacts (blink, railing, …).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. The description implies a read operation but does not disclose side effects, required permissions, or what 'signal quality' entails beyond artifact detection. Lacks behavioral traits like whether it uses current device connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys the core purpose. It is front-loaded with the main action. Could be slightly expanded to cover context, but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, output schema, or annotations, the description is minimal. It does not explain what 'signal quality' metrics are, how artifacts are reported, or how to interpret results. Given sibling tools, more context about when to use this specific signal quality check would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline 4 applies. The description adds no parameter info because none exist. It implicitly suggests no input needed, but does not clarify that it operates on the current device state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('electrode signal quality and detected artifacts'), with specific examples like blink and railing. However, it does not explicitly distinguish from siblings like get_band_powers or get_brain_state, which have overlapping themes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_brain_state or get_band_powers). No exclusion criteria or context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List EEG devices/URIs you can connect to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the tool lists devices/URIs for connection, which is a read-only operation. However, it does not disclose any authentication requirements, formatting of results, or potential limitations (e.g., network constraints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose with no extraneous words, earning a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. However, it lacks details about the return format (e.g., list of strings or objects) and does not help the agent understand how to use the output with sibling tools like 'connect'. More context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty object). The description adds no parameter-specific meaning because there are none, but it correctly implies that no input is needed, matching the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and specifies the resource as 'EEG devices/URIs you can connect to.' This clearly distinguishes it from sibling tools like 'connect' or 'calibrate' which involve actions beyond listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used for discovering available devices before connecting, but it does not explicitly state when to use it versus alternatives (e.g., before 'connect'), nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Annotate the live stream with a labeled event marker.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility to disclose side effects or safety. It only says 'annotate,' implying a write operation, but does not mention persistence, mutability, or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, it is too brief, lacking essential details. Conciseness should not come at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema or annotations, the description should provide more context on the live stream state, label semantics, and effect. It fails to fully inform an agent for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'label' parameter beyond its type. No examples, allowed values, or context are given for what constitutes a valid label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (annotate) and resource (live stream) with a specific output (labeled event marker). It is distinct from sibling tools like 'record' or 'stream_summary', though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states the function without context on preconditions, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the live stream for N seconds to a file (npz/csv/edf).
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | ||
| path | No | session.npz | |
| seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, but it only states the basic action. It does not disclose file overwrite behavior, whether recording is blocking or async, or what happens if parameters are invalid (e.g., seconds=0).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the verb and key resource ('Record the live stream'), no extraneous words, and clear structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool's complexity is moderate (3 parameters, no output schema). The description covers the main action but omits important context like error handling, file overwrite behavior, and return value. It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must add value. It explains 'fmt' with formats (npz/csv/edf) and mentions 'seconds' and 'file'; however, it does not detail the 'path' parameter or constraints on 'fmt' values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a live stream for a specified duration to a file with specific formats (npz/csv/edf). It is distinct from siblings like 'connect' or 'calibrate', though the stream type (e.g., EEG) is implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Missing prerequisites (e.g., must be connected to a device) and conditions like when recording might fail or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin a neurofeedback session rewarding time spent above a metric target.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | focus | |
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only mentions rewarding time above a target, but does not describe side effects, if it stops existing sessions, or requirements like prior calibration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence front-loading the action. However, it omits important details that could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a session-starting tool with no output schema and two parameters, the description lacks essential context: how to end the session, what happens during it, and return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely references 'metric' and 'target' without explaining valid values, units, or how they affect the session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Begin') and resource ('neurofeedback session'), and clarifies the session's function ('rewarding time spent above a metric target'). It distinguishes from sibling tools like calibrate or connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., connection, calibration) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current brain-state snapshot. (The seconds window for rolling stats arrives in a
later phase; this currently returns the live reading.)
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It honestly discloses that the `seconds` window is not yet functional and that the tool returns a live reading. This is good but does not cover other behavioral aspects like whether it is read-only or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key information (snapshot, live reading, future seconds) is front-loaded. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description explains the current behavior and the future intent of the parameter. However, it lacks details on the output format or what a 'brain-state snapshot' constitutes, which may be insufficient for an agent to fully understand the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description indirectly explains the `seconds` parameter by stating it is intended for rolling stats in a future phase. This adds context beyond the schema, though it does not fully describe the parameter's current behavior or valid range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns a 'current brain-state snapshot' and 'live reading', which clearly identifies the tool's purpose. However, it does not explicitly distinguish from sibling tools like 'get_brain_state', though the snapshot term implies a different level of detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The note about the `seconds` parameter being for a future phase implies that for rolling stats one should wait, but no alternative tool is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0calibrateconnectdisconnectget_band_powersget_brain_stateget_neurofeedback_scoreget_signal_qualitylist_devicesmark_eventrecordstart_neurofeedbackstream_summaryEach tool has a distinct purpose: connection management, data retrieval, recording, neurofeedback control, and event marking. While get_brain_state and stream_summary both provide state snapshots, their descriptions clarify that get_brain_state is detailed and stream_summary is a rolling snapshot, ensuring clear differentiation.
All tool names follow a consistent pattern: lowercase with underscores, using verbs like 'get_', 'list_', 'start_', 'record', etc. There is no mixing of conventions, making it easy to predict tool names.
With 12 tools, the server covers the essential BCI operations—device connection, data streaming, recording, neurofeedback, and calibration—without being overwhelming or sparse. This is a well-scoped set for a BCI server.
The tool set covers core workflows: connect/disconnect, calibrate, retrieve various brain metrics, record, mark events, and start neurofeedback. However, it lacks explicit stop operations for recording and neurofeedback, which could be a minor gap. Overall, it is largely complete for the stated domain.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
Cross-device AI memory with encrypted activity capture and context handoff between AI tools
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
NeuralBrain MCP Server - RAG, Vector Memory, LLM Routing, Agent Identity, x402 Payments
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/enkhbold470/bci-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
