このプロジェクトでは、脳コンピュータインターフェース (BCI) テクノロジーとモデルコンテキストプロトコル (MCP) を統合して、神経信号の取得、処理、AI 対応のインタラクションのための強力なフレームワークを作成します。
BCI-MCP は次のものを組み合わせます:
脳コンピュータインターフェース（BCI） ：神経信号のリアルタイム取得と処理
モデルコンテキストプロトコル（MCP） ：標準化されたAI通信インターフェース
この統合により、ヘルスケア、アクセシビリティ、研究、人間とコンピュータの相互作用における高度なアプリケーションが可能になります。
Related MCP server: KOI-MCP Integration
神経信号取得：脳活動からの電気信号をリアルタイムで捕捉する
信号処理：脳信号の前処理、特徴抽出、分類
コマンド生成: 解釈された脳信号をコマンドに変換する
フィードバックメカニズム: ユーザーのコントロールを向上させるためのフィードバックを提供する
リアルタイム操作：最小限の遅延で脳活動を処理
標準化されたコンテキスト共有：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制御の学習と適応を加速
プロトコル開発：神経データ交換の標準を確立する
アダプティブインターフェース：神経信号とAI支援に基づいて調整するインターフェース
意図認識：神経信号を通じてユーザーの意図をより深く理解する
補助的コミュニケーション：言語障害のある人のための強化されたコミュニケーション
プロジェクトのドキュメントは、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貢献を歓迎します！お気軽にプルリクエストを送信してください。
リポジトリをフォークする
機能ブランチを作成する ( git checkout -b feature/amazing-feature )
変更をコミットします ( git commit -m 'Add some amazing feature' )
ブランチにプッシュする ( git push origin feature/amazing-feature )
プルリクエストを開く
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細については LICENSE ファイルを参照してください。
OpenBCIプロジェクトに触発されて
モデルコンテキストプロトコルフレームワーク上に構築
神経科学とAI研究コミュニティに感謝
Enkhbold Ganbold - GitHub プロフィール
プロジェクトリンク: https://github.com/enkhbold470/bci-mcp
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.
v0.2.0calibrateconnectdisconnectget_band_powersget_brain_stateget_neurofeedback_scoreget_signal_qualitylist_devicesmark_eventrecordstart_neurofeedbackstream_summaryScored across 12 tools
Each 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
