⚠️ 这是一个非官方的社区项目，与 RxJS 团队无关。
直接从 Claude 等 AI 助手执行、调试和可视化 RxJS 流。
执行 RxJS 代码并捕获发射的数据
带有时间戳的时间轴可视化
内存使用情况跟踪
支持所有主要的 RxJS 操作符
从事件数据生成 ASCII 大理石图
可视化流随时间的变化行为
自动模式检测
清晰的图例和说明
分析操作符链的性能
检测潜在问题和瓶颈
建议替代方案
按功能对操作符进行分类
识别未取消的订阅
检测缺失的清理模式
针对特定框架的建议 (Angular, React, Vue)
提供正确的清理示例
获取经过实战检验的 RxJS 模式
针对特定框架的实现
涵盖常见用例：
带退避策略的 HTTP 重试
搜索输入联想 (Typeahead)
WebSocket 重连
表单验证
状态管理
以及更多...
Related MCP server: regex-mcp
# Install globally
npm install -g @shuji-bonji/rxjs-mcp
# Or use with npx
npx @shuji-bonji/rxjs-mcp添加到 ~/Library/Application Support/Claude/claude_desktop_config.json：
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}添加到 .vscode/mcp.json：
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}添加到 ~/.cursor/mcp.json：
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}执行 RxJS 代码并捕获带有时间轴的流发射数据。
该工具接受一个计算结果为 Observable 的表达式，或者一个以该表达式结尾的代码片段 —— return 是可选的。
// ✅ Trailing expression (v0.2.0+): the last expression is returned implicitly
interval(100).pipe(
take(5),
map((x) => x * 2),
);
// ✅ Declaration + trailing reference
const stream$ = interval(100).pipe(
take(5),
map((x) => x * 2),
);
stream$;
// ✅ Explicit return (always works)
return interval(100).pipe(
take(5),
map((x) => x * 2),
);从事件数据生成 ASCII 大理石图。
// Input: array of timed events
[
{ time: 0, value: 'A' },
{ time: 50, value: 'B' },
{ time: 100, value: 'C' },
];
// Output: A----B----C--|分析 RxJS 操作符链的性能和最佳实践。
// Analyzes chains like:
source$.pipe(
map((x) => x * 2),
filter((x) => x > 10),
switchMap((x) => fetchData(x)),
retry(3),
);检测潜在的内存泄漏和缺失的清理逻辑。
// Detects issues like:
- Missing unsubscribe
- No takeUntil operator
- Uncompleted Subjects
- Infinite intervals获取适用于常见用例的生产级模式。
可用模式：
http-retry - 具有重试功能的弹性 HTTP 请求
search-typeahead - 防抖搜索
polling - 带有退避策略的智能轮询
websocket-reconnect - 自动重连的 WebSocket
form-validation - 响应式表单验证
state-management - 简单的状态存储
cache-refresh - 带有刷新策略的缓存
以及更多...
User: "Execute this RxJS stream and show me the output"
Claude: I'll execute that RxJS stream for you.
[Uses execute_stream tool]
## Stream Execution Result
✅ Completed
Execution Time: 523ms
Values Emitted: 5
### Emitted Values
[0, 2, 4, 6, 8]User: "Check this Angular component for memory leaks"
Claude: I'll analyze your component for potential memory leaks.
[Uses detect_memory_leak tool]
## Memory Leak Analysis
⚠️ Potential leaks detected
1. 🔴 subscription (high severity)
- Found 3 subscribe() calls but only 1 unsubscribe()
- Fix: Use takeUntil pattern with destroy$ subjectUser: "Show me how to implement search with RxJS"
Claude: I'll show you the search typeahead pattern.
[Uses suggest_pattern tool with useCase: 'search-typeahead']
## Search Typeahead with Debounce
[Full implementation with explanation]execute_stream 工具在隔离的 Worker 线程中运行用户提供的代码，以防止：
主进程污染
无限循环或定时器导致的资源泄漏
访问敏感的 Node.js API (process, fs 等)
如果执行时间超过配置的超时时间，执行将被强制终止。
# Clone the repository
git clone https://github.com/shuji-bonji/rxjs-mcp-server
cd rxjs-mcp-server
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test # Unit tests (vitest)
npm run test:mcp # MCP integration test
npm run test:inspector # MCP Inspector (GUI)
# Run in development
npm run dev发布流程通过 GitHub Actions 自动化，并使用 Trusted Publisher (OIDC) 发布到 npm —— 不使用静态令牌，且每次发布都带有 npm 来源证明 (provenance attestation)。请参阅 RELEASING.md 获取完整的工作流程（以及初始 npm 设置）。
RxJS MCP Server 可以很好地与以下工具配合使用：
Angular MCP - 用于 Angular 项目脚手架
TypeScript MCP - 用于类型检查
ESLint MCP - 用于代码质量检查
未来的 Meta-MCP 集成将允许这些工具之间进行无缝协作。
┌─────────────────┐
│ AI Assistant │
│ (Claude, etc) │
└────────┬────────┘
│
MCP Protocol
│
┌────────┴────────┐
│ RxJS MCP Server│
├─────────────────┤
│ • execute_stream│
│ • generate_marble│
│ • analyze_operators│
│ • detect_memory_leak│
│ • suggest_pattern│
└─────────────────┘欢迎贡献！请随时提交 PR。
MIT
Shuji Bonji
Analyze RxJS code for creation functions, operators, performance patterns, and best practices
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | RxJS operator chain code to analyze | |
| checkPerformance | No | Whether to check for performance issues | |
| includeAlternatives | No | Whether to suggest alternative approaches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already state readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds scope detail (creation functions, operators, performance patterns, best practices) but does not disclose how results are returned or what a typical analysis output contains. No contradiction with annotations.
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, front-loaded sentence that immediately identifies the action, target, and scope. There is no filler or redundant phrasing.
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 read-only analysis tool with well-documented parameters and helpful annotations, the description covers the core action. However, with no output schema, the description does not explain what the agent should expect as a result, and it gives no sibling comparison to guide selection among the listed alternatives.
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 100%, so the schema documents all three parameters, including defaults for checkPerformance and includeAlternatives. The description aligns loosely with those parameters by mentioning performance patterns and best practices, but it adds no semantic detail beyond 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 states a specific verb ('Analyze') and resource ('RxJS code'), and names concrete analysis dimensions: creation functions, operators, performance patterns, and best practices. However, it does not explicitly distinguish itself from overlapping siblings like lint_rxjs or detect_memory_leak, so it is clear but not fully differentiated.
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 about when to use this tool versus alternatives such as lint_rxjs, detect_memory_leak, or suggest_pattern. Usage is only implied by the phrase 'Analyze RxJS code', with no exclusions, prerequisites, or routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze RxJS code for potential memory leaks and subscription management issues. Recognizes modern auto-cleanup patterns (takeUntilDestroyed, async pipe, useEffect cleanup, onUnmounted) to avoid false positives.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | RxJS code to analyze for potential memory leaks | |
| componentLifecycle | No | Component lifecycle context | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: it recognizes modern auto-cleanup patterns to avoid false positives, which tells the agent the analysis is conservative about known correct patterns.
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 short sentences, front-loaded with the tool's purpose and followed by a key behavioral qualifier. Every sentence earns its place; there is no filler or redundancy.
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?
Inputs and safety are well covered by the schema and annotations. However, there is no output schema and the description does not state what the analysis returns or how the componentLifecycle parameter influences the results, leaving those aspects incomplete.
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 100%, so the baseline is 3. The description's framework-specific pattern examples (takeUntilDestroyed, useEffect cleanup, onUnmounted) hint at the componentLifecycle enum's purpose, but they never explicitly explain how or when to set the componentLifecycle parameter.
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 ('Analyze'), a clear resource ('RxJS code'), and a specific focus (memory leaks and subscription management issues). It does not explicitly contrast sibling tools like lint_rxjs, so sibling differentiation is implicit rather than overt.
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 use case is implied: use this when someone needs RxJS memory-leak or subscription-management analysis. However, the description gives no explicit when-to-use or when-not-to-use guidance, and it does not mention alternative sibling tools such as lint_rxjs or suggest_pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute RxJS code in an isolated environment and capture the stream emissions, timeline, and performance metrics. Code runs in a separate worker thread for security.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | RxJS code to execute. Should return an Observable. | |
| timeout | No | Timeout in milliseconds | |
| takeCount | No | Maximum number of values to take from the stream | |
| captureMemory | No | Whether to capture memory usage | |
| captureTimeline | No | Whether to capture emission timeline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnly and idempotent annotations by stating that code runs in a separate worker thread for security, implying isolation. It also discloses what gets captured, which is useful for understanding the tool's behavior. It does not contradict the annotations.
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 two sentences with no filler: the first sentence states the action and outputs, the second provides the security/isolation context. It is front-loaded and every sentence earns its place.
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 output schema, the description should provide enough detail about return values; it names high-level outputs (emissions, timeline, performance metrics) but not their structure or format. It also doesn't mention error behavior or timeout handling explicitly, though the parameter descriptions cover some of this. Overall it is adequate but leaves room for 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?
Schema description coverage is 100%, with all five parameters individually documented, so the description does not need to repeat parameter-level details. It aligns broadly with the capture flags and timeout but adds no further semantic value beyond 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 a specific verb and resource — "Execute RxJS code in an isolated environment" — and explicitly lists what it captures: emissions, timeline, and performance metrics. This clearly differentiates it from the sibling tools, which are about linting, analyzing, detecting leaks, generating marble diagrams, and suggesting patterns.
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 gives clear context for when to use the tool: to run RxJS code and capture stream emissions, timeline, and performance metrics. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to select this tool over the non-execution siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ASCII marble diagrams to visualize RxJS stream emissions over time
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Time scale factor (ms per character) | |
| events | Yes | Array of events to visualize | |
| duration | No | Total duration to show in the diagram | |
| showValues | No | Whether to show values below the timeline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context by specifying the output form (ASCII marble diagrams) and what the tool visualizes, which goes beyond the structured annotations. No contradiction exists.
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, well-formed sentence with no filler or redundancy. It front-loads the core purpose ('Generate ASCII marble diagrams') and immediately follows with the domain context, making it highly scannable for an agent.
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, read-only, idempotent visualization tool, the description is complete. The input schema fully documents parameters, annotations cover side-effect concerns, and the description identifies the output format. No critical information needed to invoke the tool correctly is missing.
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 100%, so the structured schema already documents all four parameters (events, scale, duration, showValues) with meaningful descriptions. The description does not add extra parameter-level meaning, but it does not need to because the schema carries that information.
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 names a specific action ('Generate'), a concrete resource ('ASCII marble diagrams'), and the exact domain ('RxJS stream emissions over time'). This clearly distinguishes it from sibling tools like execute_stream or lint_rxjs, none of which are about generating visual diagrams.
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 gives a clear usage context: use this tool when you need to visualize RxJS stream emissions over time as ASCII marble diagrams. It does not explicitly list when-not-to-use conditions or alternative tools, but the purpose is specific enough that an agent can infer the appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint RxJS code snippets for common issues and best practices (regex-based best-effort analysis, no ESLint runtime required). Based on eslint-plugin-rxjs-x rules. Checks for nested subscribes, memory leaks, deprecated patterns, and more. Rules marked as type-info-required use heuristics and may have false positives/negatives. Supports framework-specific rules for Angular, React, and Vue.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | RxJS code to lint | |
| rules | No | Specific rule names to check (overrides config). Example: ["no-nested-subscribe", "no-async-subscribe"] | |
| config | No | Lint config level: recommended (default) or strict (includes all rules) | recommended |
| framework | No | Framework context for framework-specific rules | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description candidly discloses that analysis is 'regex-based best-effort' and that type-info-required rules 'use heuristics and may have false positives/negatives.' This is valuable, non-obvious behavioral context that sets proper expectations for the agent.
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 compact and front-loaded, with each sentence contributing purpose, mechanics, caveats, or framework scope. The phrase 'and more' is somewhat vague, and the opening parenthetical interrupts flow slightly, but overall the structure is 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 moderate four-parameter tool with no output schema, the description gives enough behavioral and parameter context for an agent to invoke it correctly. It could be more complete by describing the shape of the lint results or explicitly routing to/away from specialized siblings like detect_memory_leak.
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 100%, so the baseline is 3. The description adds limited meaning by mentioning rule categories and Angular/React/Vue support, which maps to the rules and framework parameters, but it does not substantially elaborate beyond what the schema already documents.
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 opens with a specific verb and resource: 'Lint RxJS code snippets,' and then enumerates concrete checks such as nested subscribes, memory leaks, and deprecated patterns. It clearly defines the tool's purpose but does not explicitly differentiate it from sibling tools like detect_memory_leak or analyze_operators, so it falls just 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use this when you want stand-alone, regex-based linting of RxJS snippets without requiring ESLint, with optional framework-specific rules. However, it never explicitly states when to prefer this tool over a sibling or when not to use it, leaving alternatives and exclusions unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest RxJS patterns and best practices for common use cases
| Name | Required | Description | Default |
|---|---|---|---|
| useCase | Yes | The use case for which to suggest an RxJS pattern | |
| framework | No | Target framework for the pattern | vanilla |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the 'Suggest' wording is consistent with those. The description does not add behavioral detail beyond the annotations, such as what kind of output to expect or any limitations, but it also does not contradict them.
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?
One short, front-loaded sentence with no filler. Every word earns its place, and the core intent is immediately clear.
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 schema and annotations cover inputs and safety, and the purpose is clear. However, the description does not explain the expected output, nor does it position the tool relative to similar siblings, leaving some selection and invocation context incomplete.
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 100%, with both parameters having meaningful descriptions and enums. The description adds no significant meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 a specific verb ('Suggest') and a clear resource ('RxJS patterns and best practices'), and the purpose is easily distinguished from sibling tools like lint_rxjs, analyze_operators, or execute_stream. It communicates exactly what the tool offers.
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 gives no guidance about when to use this tool versus the sibling tools. It does not mention alternatives, exclusions, or conditions, so an agent must infer selection from the tool name and schema enums.
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.5.3analyze_operators2 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsedetect_memory_leak2 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseexecute_stream2 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsegenerate_marble4 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / events / items / additionalPropertiesRemoved value: -falseInput schema / properties / events / items / requiredPrevious value: -[
- "time"
-]New value: +[
+ "time",
+ "value"
+]lint_rxjs2 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsesuggest_pattern2 fields changedInput schema / $schemaAdded value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falsev0.4.1lint_rxjsv0.1.3analyze_operatorsdetect_memory_leakexecute_streamgenerate_marblesuggest_patternScored across 6 tools
Most tools are distinct, but lint_rxjs, analyze_operators, and detect_memory_leak have overlapping analysis purposes. An agent may struggle to choose between linting for memory leaks and running a dedicated memory-leak detector.
All tool names follow the same verb_noun snake_case pattern: execute_stream, generate_marble, lint_rxjs, analyze_operators, detect_memory_leak, suggest_pattern. The naming is predictable and consistent.
Six tools is a well-scoped set for an RxJS helper server. Each tool covers a distinct high-level workflow such as execution, visualization, linting, analysis, leak detection, and pattern suggestion.
The surface covers the main RxJS developer workflows: run code, visualize output, lint for issues, analyze operators, detect leaks, and suggest patterns. Minor gaps exist around code fixing or detailed educational explanations, but the core domain is well covered.
Live browser debugging for AI assistants — DOM, console, network via MCP.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Let Claude, Cursor, or ChatGPT author Mermaid diagrams your team can read and share.
