README en japonés disponible aquí
⚠️ Este es un proyecto comunitario no oficial, no afiliado al equipo de RxJS.
Ejecuta, depura y visualiza flujos de RxJS directamente desde asistentes de IA como Claude.
Ejecuta código RxJS y captura emisiones
Visualización de línea de tiempo con marcas de tiempo
Seguimiento del uso de memoria
Soporte para todos los operadores principales de RxJS
Genera diagramas de canicas en ASCII
Visualiza el comportamiento del flujo a lo largo del tiempo
Detección automática de patrones
Leyenda y explicaciones claras
Analiza cadenas de operadores para evaluar el rendimiento
Detecta posibles problemas y cuellos de botella
Sugiere enfoques alternativos
Clasifica los operadores por función
Identifica suscripciones no canceladas
Detecta patrones de limpieza faltantes
Recomendaciones específicas para frameworks (Angular, React, Vue)
Proporciona ejemplos de limpieza adecuada
Obtén patrones de RxJS probados en producción
Implementaciones específicas para frameworks
Casos de uso comunes cubiertos:
Reintento HTTP con retroceso (backoff)
Búsqueda tipo "typeahead"
Reconexión de WebSocket
Validación de formularios
Gestión de estado
¡Y más!
Related MCP server: regex-mcp
# Install globally
npm install -g @shuji-bonji/rxjs-mcp
# Or use with npx
npx @shuji-bonji/rxjs-mcpAñade a ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Añade a .vscode/mcp.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Añade a ~/.cursor/mcp.json:
{
"mcpServers": {
"rxjs": {
"command": "npx",
"args": ["@shuji-bonji/rxjs-mcp"]
}
}
}Ejecuta código RxJS y captura las emisiones del flujo con una línea de tiempo.
La herramienta acepta una expresión que se evalúa como un Observable, o un fragmento de código que termine en dicha expresión; return es opcional.
// ✅ 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),
);Genera diagramas de canicas en ASCII a partir de datos de eventos.
// Input: array of timed events
[
{ time: 0, value: 'A' },
{ time: 50, value: 'B' },
{ time: 100, value: 'C' },
];
// Output: A----B----C--|Analiza cadenas de operadores de RxJS para evaluar el rendimiento y las mejores prácticas.
// Analyzes chains like:
source$.pipe(
map((x) => x * 2),
filter((x) => x > 10),
switchMap((x) => fetchData(x)),
retry(3),
);Detecta posibles fugas de memoria y falta de limpieza.
// Detects issues like:
- Missing unsubscribe
- No takeUntil operator
- Uncompleted Subjects
- Infinite intervalsObtén patrones listos para producción para casos de uso comunes.
Patrones disponibles:
http-retry - HTTP resiliente con reintento
search-typeahead - Búsqueda con debounce
polling - Sondeo inteligente con retroceso
websocket-reconnect - WebSocket con reconexión automática
form-validation - Validación reactiva de formularios
state-management - Almacén de estado simple
cache-refresh - Caché con estrategia de actualización
¡Y más!
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]La herramienta execute_stream ejecuta el código proporcionado por el usuario en un Worker thread aislado para evitar:
Contaminación del proceso principal
Fugas de recursos por bucles infinitos o temporizadores
Acceso a APIs sensibles de Node.js (process, fs, etc.)
La ejecución se termina forzosamente si excede el tiempo de espera configurado.
# 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 devLos lanzamientos están automatizados mediante GitHub Actions y se publican en npm utilizando Trusted Publisher (OIDC); no se utilizan tokens estáticos y cada lanzamiento lleva una atestación de procedencia de npm. Consulta RELEASING.md para ver el flujo de trabajo completo (y la configuración inicial de npm).
El servidor MCP de RxJS funciona muy bien junto con:
Angular MCP - Para la creación de proyectos Angular
TypeScript MCP - Para la comprobación de tipos
ESLint MCP - Para la calidad del código
La futura integración Meta-MCP permitirá una coordinación fluida entre estas herramientas.
┌─────────────────┐
│ AI Assistant │
│ (Claude, etc) │
└────────┬────────┘
│
MCP Protocol
│
┌────────┴────────┐
│ RxJS MCP Server│
├─────────────────┤
│ • execute_stream│
│ • generate_marble│
│ • analyze_operators│
│ • detect_memory_leak│
│ • suggest_pattern│
└─────────────────┘¡Las contribuciones son bienvenidas! Por favor, siéntete libre de enviar un 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.
