⚠️ これは非公式のコミュニティプロジェクトであり、RxJSチームとは提携していません。
ClaudeなどのAIアシスタントから直接RxJSストリームを実行、デバッグ、可視化します。
RxJSコードを実行し、排出（emission）をキャプチャ
タイムスタンプ付きのタイムライン可視化
メモリ使用量の追跡
主要なすべてのRxJSオペレーターをサポート
イベントデータからASCIIマーブルダイアグラムを生成
時間経過に伴うストリームの挙動を可視化
自動パターン検出
明確な凡例と解説
パフォーマンス向上のためのオペレーターチェーン分析
潜在的な問題やボトルネックの検出
代替アプローチの提案
機能ごとのオペレーター分類
未購読（unsubscribed）のサブスクリプションを特定
クリーンアップ漏れのパターンを検出
フレームワーク固有の推奨事項（Angular, React, Vue）
適切なクリーンアップ例の提供
実戦で鍛えられたRxJSパターンを取得
フレームワーク固有の実装
一般的なユースケースを網羅:
バックオフ付きHTTPリトライ
検索のタイプアヘッド
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（来歴）証明が付与されます。完全なワークフロー（および初期の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.
