The rxjs-mcp-server lets you execute, debug, visualize, and analyze RxJS streams directly from AI assistants via the MCP Protocol.
Execute RxJS code (execute_stream) — run Observable code in an isolated worker thread, capturing stream emissions, timelines, and performance metrics, with configurable timeout, value limits, and memory tracking.
Generate marble diagrams (generate_marble) — produce ASCII marble diagrams to visually represent stream behavior over time, with customizable time scale and value display.
Analyze operators (analyze_operators) — inspect RxJS operator chains for performance bottlenecks, best-practice violations, and alternative approaches.
Detect memory leaks (detect_memory_leak) — identify unsubscribed subscriptions and missing cleanup patterns, with framework-specific recommendations (Angular, React, Vue).
Suggest patterns (suggest_pattern) — get production-ready RxJS patterns for 15+ common use cases (e.g., HTTP retry, search typeahead, WebSocket reconnection, polling, state management, infinite scroll, auto-save), tailored to a target framework (Angular, React, Vue, or vanilla).
Analyzes RxJS streams within Angular applications to detect memory leaks and provides framework-specific recommendations for proper subscription cleanup.
Coordinates with ESLint to maintain code quality and ensure best practices are followed in RxJS implementations.
Identifies potential RxJS memory leaks in React applications and suggests proper cleanup patterns for reactive streams.
Enables the execution, debugging, and visualization of TypeScript-based RxJS code, including operator chain analysis and marble diagram generation.
⚠️ This is an unofficial community project, not affiliated with RxJS team.
Execute, debug, and visualize RxJS streams directly from AI assistants like Claude.
Execute RxJS code and capture emissions
Timeline visualization with timestamps
Memory usage tracking
Support for all major RxJS operators
Generate ASCII marble diagrams
Visualize stream behavior over time
Automatic pattern detection
Clear legend and explanations
Analyze operator chains for performance
Detect potential issues and bottlenecks
Suggest alternative approaches
Categorize operators by function
Identify unsubscribed subscriptions
Detect missing cleanup patterns
Framework-specific recommendations (Angular, React, Vue)
Provide proper cleanup examples
Get battle-tested RxJS patterns
Framework-specific implementations
Common use cases covered:
HTTP retry with backoff
Search typeahead
WebSocket reconnection
Form validation
State management
And more...
Related MCP server: regex-mcp
Node.js >= 22 (engines.node). The MCP TypeScript SDK v2 this server is
built on requires Node.js >= 20; this package sets the higher floor to stay on
a maintained LTS line.
# Install globally
npm install -g @shuji-bonji/rxjs-mcp
# Or use with npx
npx @shuji-bonji/rxjs-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Add to .vscode/mcp.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Execute RxJS code and capture stream emissions with timeline.
The tool accepts either an expression that evaluates to an Observable, or a
snippet ending in such an expression — return is optional.
// ✅ 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),
);Generate ASCII marble diagrams from event data.
// Input: array of timed events
[
{ time: 0, value: 'A' },
{ time: 50, value: 'B' },
{ time: 100, value: 'C' },
];
// Output: A----B----C--|Analyze RxJS operator chains for performance and best practices.
// Analyzes chains like:
source$.pipe(
map((x) => x * 2),
filter((x) => x > 10),
switchMap((x) => fetchData(x)),
retry(3),
);Detect potential memory leaks and missing cleanup.
// Detects issues like:
- Missing unsubscribe
- No takeUntil operator
- Uncompleted Subjects
- Infinite intervalsGet production-ready patterns for common use cases.
Available patterns:
http-retry - Resilient HTTP with retry
search-typeahead - Debounced search
polling - Smart polling with backoff
websocket-reconnect - Auto-reconnecting WebSocket
form-validation - Reactive form validation
state-management - Simple state store
cache-refresh - Cache with refresh strategy
And more...
Lint RxJS code snippets for common issues and best practices. Based on eslint-plugin-rxjs-x rules.
// Parameters:
{
code: string; // RxJS code to lint
config?: 'recommended' | 'strict'; // Rule set (default: recommended)
framework?: 'angular' | 'react' | 'vue' | 'none'; // Framework context
rules?: string[]; // Specific rules to check (overrides config)
}Config levels:
recommended — 20 rules covering the most common issues
strict — the 28 rules in eslint-plugin-rxjs-x's strict (no-exposed-subjects,
no-misused-observables, no-unnecessary-collection, etc.)
finnish is in neither config, matching the plugin, and runs only when named:
rules: ["finnish"]. Framework-specific checks are added on top of both levels.
Framework-specific checks:
Angular — Detects missing takeUntilDestroyed() or takeUntil(destroy$) in components
React — Detects subscribe() without useEffect cleanup
Vue — Detects subscribe() without onUnmounted cleanup
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]The execute_stream tool runs user-provided code in an isolated Worker thread to prevent:
Main process pollution
Resource leaks from infinite loops or timers
Access to sensitive Node.js APIs (process, fs, etc.)
Execution is forcefully terminated if it exceeds the configured timeout.
# 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 devReleases are automated via GitHub Actions and published to npm using Trusted Publisher (OIDC) — no static tokens are used, and every release carries an npm provenance attestation. See RELEASING.md for the full workflow (and initial npm setup).
RxJS MCP Server works great alongside:
Angular MCP - For Angular project scaffolding
TypeScript MCP - For type checking
ESLint MCP - For code quality
Future Meta-MCP integration will allow seamless coordination between these tools.
┌─────────────────┐
│ AI Assistant │
│ (Claude, etc) │
└────────┬────────┘
│
MCP Protocol
│
┌────────┴────────┐
│ RxJS MCP Server│
├─────────────────┤
│ • execute_stream│
│ • generate_marble│
│ • analyze_operators│
│ • detect_memory_leak│
│ • suggest_pattern│
│ • lint_rxjs │
└─────────────────┘The server is built on the MCP TypeScript SDK v2
(@modelcontextprotocol/server@^2.0.0, protocol revision 2026-07-28). It speaks
stdio only: src/index.ts hands the createServer() factory in src/server.ts
to serveStdio(), which also serves clients that still speak the 2025 protocol
revisions.
Since v0.3.0, analyze_operators outputs three-tier documentation links for each operator and creation function:
Tier | Source | Purpose | AI-readable? |
Official | Authoritative API reference for humans | ❌ (SPA) | |
Source | JSDoc + implementation — the richest context for AI | ✅ | |
Guide | Bilingual JP/EN explanations with practical examples | ✅ |
rxjs.dev is a client-rendered SPA. AI assistants cannot fetch its content — HTTP requests return an empty shell with JavaScript loaders. The official site is therefore a "link to hand to humans," not a source AI can read.
GitHub source provides raw truth. The RxJS source code (pinned at tag 7.8.2) contains JSDoc, type signatures, and implementation details. This is the primary reference for AI assistants.
The bilingual guide adds learning context. It organizes operators by use-case (not just alphabetically), provides runnable examples, and offers Japanese translations. For Japanese-speaking users or learners, this fills a gap that neither rxjs.dev nor raw source addresses.
When the MCP server outputs references, it follows this priority:
officialUrl — always shown (authority, human-readable)
sourceUrl — shown when available (AI should read this)
guideUrl — shown when the page exists (supplementary)
If a guide page does not yet exist for an operator, the field is simply omitted (no broken link). Coverage is tracked by the URL validation CI.
Currently there is no runtime option to exclude guideUrl from output. If you prefer official-only references, you can fork this server or open a feature request. A future version may support a --references=official,source flag.
Contributions are welcome! Please feel free to submit a 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.
