⚠️ 이 프로젝트는 커뮤니티 프로젝트이며, RxJS 팀과는 관련이 없습니다.
Claude와 같은 AI 어시스턴트에서 직접 RxJS 스트림을 실행, 디버깅 및 시각화하세요.
RxJS 코드 실행 및 방출(emission) 캡처
타임스탬프가 포함된 타임라인 시각화
메모리 사용량 추적
모든 주요 RxJS 연산자 지원
이벤트 데이터로부터 ASCII 마블 다이어그램 생성
시간 경과에 따른 스트림 동작 시각화
자동 패턴 감지
명확한 범례 및 설명
성능을 위한 연산자 체인 분석
잠재적인 문제 및 병목 현상 감지
대안 접근 방식 제안
기능별 연산자 분류
구독 해제되지 않은 구독 식별
누락된 정리(cleanup) 패턴 감지
프레임워크별 권장 사항 (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 thread)**에서 실행하여 다음을 방지합니다:
메인 프로세스 오염
무한 루프나 타이머로 인한 리소스 누수
민감한 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)을 포함합니다. 전체 워크플로우(및 초기 npm 설정)는 RELEASING.md를 참조하세요.
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.
