"Mermaid" matching MCP tools:

• update_docA

  DockA

  Replace a workspace's doc body. Takes EITHER TipTap JSON (`content`) OR Markdown (`markdown`): pass markdown when you're producing prose from scratch (CommonMark + GFM is the format every LLM emits natively), pass TipTap JSON when you need structural edits to an existing doc (round-trip from get_doc, mutate, write back). Beyond CommonMark + GFM, the markdown layer recognizes: - **** → inline image. Use ANY publicly-reachable URL (HTTPS preferred — HTTP fires browser mixed-content warnings; data: URIs are rejected by `allowBase64: false`). Renders block-feeling via CSS (max-width 100%, rounded corners, drop shadow) even though the underlying node is inline. The `alt` text is the accessible label and shows in place of the image if the URL fails to load — always include it. To attach a user-uploaded file, hit `POST /api/workspaces/:slug/upload-image` from the human-side UI first to get a Vercel Blob URL, then reference that URL in the doc markdown. - A **lone video-file URL on its own line** (extension `.mp4` / `.m4v` / `.webm` / `.mov` / `.mkv`, signed-params + timestamp fragments tolerated) → native HTML5 `<video controls preload="metadata">` player. Source URL is referenced directly: no iframe, no transcoding, no quality loss. Vercel Blob is the canonical hosting (5 GB per file, served with HTTP range requests so 4K masters stream cleanly), but ANY publicly-reachable HTTPS URL works. Sample shape: a paragraph containing only `https://cdn.dock.ai/2025-launch-walkthrough.mp4`. Mid-paragraph URLs stay as plain links — surrounding prose disqualifies the auto-promotion (matches the oEmbed convention). - **```mermaid** fenced code → diagram (15 sub-types: flowchart, sequence, gantt, ER, state, class, mindmap, timeline, pie, quadrant, sankey, XY-chart, packet, block, journey) - **$x$** inline math, **$$x$$** block math (LaTeX, KaTeX-rendered, scripts/href disabled) - **> [!NOTE]** / **[!TIP]** / **[!IMPORTANT]** / **[!WARNING]** / **[!CAUTION]** GFM-style callouts - **```svg** fenced code → sanitized SVG embed (the universal escape hatch for custom diagrams; scripts and event handlers stripped at write time) - **<details><summary>X</summary>BODY</details>** → collapsible toggle - **[[slug]]** / **[[org/slug]]** / **[[slug#tab]]** / **[[slug#row-id]]** / **[[slug|display]]** → cross-references to another workspace, surface, or row. Resolved against your accessible workspace set; targets you can't see render as plain text on the reader's side (no info leak). Every cross-ref creates a Backlink row so the target's 'referenced from' sidebar shows this doc. - **[@Label](dock:mention/<kind>/<id>)** → @-mention of a user or agent. `<kind>` is `agent` or `human`; `<id>` is the principal id. Optional query params `?org=<slug>` (agents) or `?email=<addr>` (humans) for renderer hints. Mentioning a human writes a `doc_mention` row to their inbox + sends a deep-link email; mentioning an agent fires the `doc.mention_added` webhook so the agent service can wake up and reply. Re-saving a doc that already mentions someone does NOT re-fire — only newly-added mentions notify (computed from a diff against the previous body). Use this from agent code to ping a teammate when a doc you wrote needs their eyes. - A **lone URL on its own line** from a safelisted provider (YouTube, Vimeo, Loom, Figma, CodePen, GitHub gists) → sandboxed iframe embed. Other URLs stay as regular links. Surrounding prose disqualifies the auto-embed. Per-format caps: max 50 Mermaid diagrams (30 KB source each), max 500 math expressions (8 KB source each), max 50 SVG blocks (100 KB source each post-sanitize), max 200 cross-refs per doc, max 500 @-mentions per doc, max 20 embeds per doc, max 20 videos per doc (5 GB per file at upload time), max 200 images per doc. See /docs/doc-formats for examples. Last-write-wins; no CRDT merge. Emits doc.updated + doc.heading_added + doc.mention_added events as applicable. Requires editor role. Multi-surface workspaces optionally accept `surface_slug` to write to a specific doc tab; omitted writes the primary doc surface. Append-only updates have a dedicated `append_doc_section` tool that doesn't require fetching the body first.

  ConnectorNo auth

• update_doc_sectionA

  DockA

  Replace a single section of a workspace's doc body, identified by its heading text. The targeted edit complement to `update_doc` (full replacement) and `append_doc_section` (append-only at the end). Use this when the agent maintains a recurring section (e.g., a 'Status' block in a launch-prep doc, an 'Outcomes' block in a meeting note) and only needs to refresh that one piece. Without it, agents are forced into 'GET → splice → PUT' which costs tokens, costs latency, and races against any concurrent human edit elsewhere in the doc (last-write-wins clobbers). Section semantics: the FIRST heading whose plain text matches `heading` exactly (case-sensitive on trimmed text) is found, and everything from that heading up to the next heading at the same OR shallower level is replaced. So a `## Outcomes` section ends at the next `## …` or `# …`; nested `### …` subsections stay part of the replaced range. Returns 404 when no matching heading exists; strict by design so a misremembered heading fails loudly. `markdown` is the FULL replacement, INCLUDING the heading line: pass it back as-is to keep the heading, change it to rename or rewrite the heading, change the heading level, or omit the heading entirely (collapses the section into the prior one). Empty `markdown` deletes the section. Same markdown surface as update_doc / append_doc_section (CommonMark + GFM + `` images + lone-URL videos (mp4/webm/mov/mkv/m4v) + Mermaid + KaTeX + callouts + SVG + details + cross-refs + @-mentions + URL embeds). Identity / attribution / events / doc-guard all flow through the same writeDocBody path as the other doc endpoints, so @-mentions in the new section fire `doc.mention_added` for newly-added mentions just like update_doc does. Requires editor role. Multi-surface workspaces optionally accept `surface_slug` to target a specific doc tab. WARNING — a section runs to the next heading of the SAME OR SHALLOWER level, so targeting the LAST heading (or a lone H1) means its section extends to the END OF THE DOCUMENT and this call replaces everything below it. That has silently destroyed a doc twice (#8196), both times returning success. Call `get_doc` first and check which headings follow the one you are targeting. Agent writes that would drop most of the doc's blocks are now REFUSED with both block counts; pass `allowBlockLoss: true` to confirm an intended large deletion.

  ConnectorNo auth

• mutateA

  Agentic MermaidA

  Apply a list of structured edit ops to an existing Mermaid `source` and return the edited diagram. This is the declarative counterpart to `execute`: plain JSON in, plain JSON out, no sandbox. Prefer it for straightforward edits; reserve `execute` for logic the ops don't express. Returns { ok, family, source, verify:{ ok, warnings } } on success, or { ok:false, family, opIndex, error } — where `error` names the offending field and lists the valid ones — when an op is malformed or cannot apply. Ops apply in order and are all-or-nothing: the first failing op stops the batch (its position is `opIndex`) and the input is left untouched. Each op is { "kind": <op>, …fields }. Call `describe_sdk` for the detected family before authoring unfamiliar ops; it returns compact signatures or exact field types, enum values, defaults, and constraints.

  ConnectorNo auth

• visualiseA

  recordariA

  Generate a Mermaid.js flowchart for human visual inspection only. NOT for orphan detection or programmatic analysis — use audit(mode=orphans) to find isolated memories. Output may be truncated for large domains; never infer graph properties (e.g. orphans) from a truncated result. Pass memory_id (memory ID) to see a single memory and all its direct connections. Pass domain to see the full domain graph (most-connected memories first, capped at limit, default 40 max 100). Returns JSON with mermaid, node_count, edge_count, nodes_shown, nodes_total, edges_shown, edges_total, truncated, memories([{id,label}]) and connections([{from,to,relationship}]). If client supports HTML widgets, prefer passing memories and connections to an interactive renderer rather than outputting raw mermaid. If not, output mermaid inside a ```mermaid code block. If truncated is true, note only most-connected memories are shown and nodes_total/edges_total reveal what was dropped.

  ConnectorAPI key

• edit_diagramA

  FlowgrafA

  Apply a list of operations to an EXISTING diagram. The ops re-use this tool's op vocabulary; you author them, we validate + apply + re-layout + re-render. ALWAYS call get_diagram(diagramId) first: it returns the current ids and the `version`. Pass that version as `baseVersion`. If the diagram changed since you fetched it, you get a STALE_VERSION error telling you the current version — refetch with get_diagram, recompute your ops, and retry. The operations (each element of `ops`): - add_node { op, node:{ id, label, kind, parentId? } } - remove_node { op, id } (also drops edges touching the node) - update_node { op, id, patch:{ label?, kind?, parentId?, metadata? } } - add_edge { op, edge:{ id, source, target, kind, label?, directed? } } - remove_edge { op, id } - update_edge { op, id, patch:{ source?, target?, label?, kind?, directed? } } - add_group { op, group:{ id, label, type, parentId? } } - remove_group{ op, id } - move_to_group { op, nodeId, groupId } (groupId null un-nests the node) - set_layout { op, patch:{ direction?, spacing? } } - insert_between { op, newNode:{ id, label, kind, parentId? }, sourceId, targetId, inKind?, outKind? } insert_between IS THE KEY OP for "add X between A and B" requests. It splices newNode onto the existing A→B edge: removes that edge, adds the node, and wires A→newNode→B so the connection re-routes through it automatically. WORKED EXAMPLE — "add a Redis cache between the API and the DB" on the diagram above: 1) get_diagram(diagramId) → shows nodes n_api, n_db and version 1. 2) edit_diagram({ diagramId, baseVersion: 1, ops: [ { "op": "insert_between", "sourceId": "n_api", "targetId": "n_db", "newNode": { "id": "n_redis", "label": "Redis", "kind": { "catalog": "saas", "type": "redis" }, "parentId": "g_vpc" }, "inKind": "request", "outKind": "data_flow" } ] }) The API→DB edge is gone and now flows API→Redis→DB. Never send x/y/position — geometry is computed for you. Node kinds: catalog ∈ {aws, gcp, azure, k8s, saas, generic} with rich per-catalog types (e.g. aws:lambda, gcp:bigquery, azure:cosmos_db, k8s:deployment, saas:kafka), plus generic flowchart kinds (process, decision, terminator, data, document, subprocess). Returns { url, svg, mermaid, appliedOps, version }.

  ConnectorNo auth

• minimize_sip_traceA

  SipflowA

  [cost: free (pure CPU, no network) | read-only, no persistence] Reduce a raw SIP trace to a compact form suitable for sending to an LLM. Preserves SDP bodies and routing/auth/dialog headers; prunes well-known noise (User-Agent, Server, Allow, Accept-*, Date, P-* informational, etc.). Expected input format: raw SIP messages separated by blank lines, each starting with a request line (`INVITE sip:...@... SIP/2.0`) or status line (`SIP/2.0 200 OK`). PCAP-decoded text from sngrep / ngrep / tcpdump / tshark, syslog with SIP body, sipflow's own export format, or a hand-pasted INVITE/200 dialog all work. Annotation lines like `# [timestamp] sender -> receiver` or ngrep-style `U <ip>:<port> -> <ip>:<port>` between blocks are tolerated. Safe to run on production traces - the input is processed in-memory and is not persisted or sent off-server. Pair with: `detect_sip_stack` to identify the vendor, then `search_sip_docs(vendor=...)` for vendor-grounded analysis; `render_sip_ladder` to visualize the trace as a Mermaid call-flow ladder; `lint_sip_request` / `parse_sip_message` to mechanically validate any single message in the trace.

  ConnectorNo auth

• plan_deployA

  mcpA

  Turns YOUR repo classification (you scan the repo and pass what you found) into a complete, approvable deploy plan WITHOUT creating anything. ⚡ REDU NEEDS THREE FILES IF THEY EXIST - redu.md, the compose file, the Dockerfile - and there are two ways to give them. ⭐ BEST, for an upload-mode deploy: run prepare_upload FIRST and pass its `source_token`; redu reads all three straight out of the upload you already made, the upload stays deployable, and you emit nothing. Pasting the same files costs you 20-29 KB of output for bytes the server already has. Otherwise (git mode) paste `redu_md` (cat redu.md), `compose_yaml`, `dockerfile`. Either way you do NOT read or interpret them; redu parses them SERVER-SIDE and returns (a) a short digest, (b) `pin_dname` so a redeploy keeps the SAME public URL, and (c) `preflight` - preemptive fixes for known failure patterns found in YOUR repo, each learned from a real failed build. Giving redu these files is the single highest-value thing you can do for a first deploy. picks the VM + managed-Postgres sizes, prices them at the real pricing_rules rates, and checks they FIT your quota — so a plan that can't provision is caught HERE, before any spend. You pass what you detected in the repo (runtime, port, needs_postgres/redis/clickhouse/vector_db); it returns resources + £/hr + £/mo + a feasibility verdict + a checkpoint summary to confirm with the user. Defaults: app VM m1.medium, managed Postgres m1.small, managed ClickHouse m1.medium; pass single_vm to collapse the app + Postgres onto one VM. SET needs_clickhouse:true FOR ANY ANALYTICS-SHAPED APP (Plausible, PostHog, Langfuse, Matomo, SigNoz, or anything with a clickhouse image / CLICKHOUSE_* env / a ClickHouse client dep): those products keep config in Postgres and EVERY EVENT in ClickHouse, so the events tier is a second VM with a second line on the bill: measured 2026-08-07, omitting it quoted GBP 53.29/mo for a GBP 65.99/mo deployment. It is sized, quota-checked and priced here; unlike Postgres and Redis it is not auto-wired by deploy_app, so the plan tells you to run plan_managed_datastore engine:'clickhouse' -> create_clickhouse and pass CLICKHOUSE_* env yourself. Vector-DB needs are flagged, not provisioned. Any containerizable app works (node, python, go, ...) — it deploys as a container, so the language doesn't gate it. Set serves_http:false for a non-web repo (a library, CLI, or language runtime with no HTTP server) and it returns a clean not-a-web-service verdict instead of a costed VM plan. Set heavy_build:true for resource-heavy builds (compiled-from-source native code, a monorepo/turborepo build, a large Node heap) and it raises the app VM to a build-capable floor so the on-VM build doesn't get OOM-killed. Set memory_heavy:true for a RAM-forward app whose persistent state lives in a MANAGED DB / external store (Next.js like cal.com/cal.diy, Rails, Django, JVM/Java apps) — it sizes onto a memory-optimized SMALL-DISK flavor (m1.mem16/m1.mem32: full RAM, a lean 40 GB disk instead of 160 GB) that costs less and snapshots/clusters far faster; do NOT set it if the app keeps lots of data on local disk. Also returns a brand-named markdown report (Mermaid diagram + cost) to save as redu-deploy-plan.md and show the user. Every deploy leaves TWO MANDATORY files at the repo root with DIFFERENT purposes: redu-deploy-plan.md = THIS run's plan/estimate, and redu.md = the DURABLE deploy memory the NEXT deploy reads. If a redu.md exists, READ it FIRST and reuse its known-good plan + recorded fixes; if NONE exists, one MUST be created at the end of the deploy (get_deployment returns redu_md_bootstrap_markdown for exactly that case; when a redu.md DOES exist, pass it as redu_md and write the merged redu_md_markdown). They are SEPARATE files — even if your own memory/notes from a prior deploy call redu-deploy-plan.md 'the record', the durable record is redu.md, so do not skip creating it.

  ConnectorNo auth

• render_sip_ladderA

  SipflowA

  [cost: free (pure CPU, no network) | read-only] Parse a raw SIP trace (PCAP-decoded text, sngrep export, syslog, or pasted INVITE/200 dialog) and emit a Mermaid `sequenceDiagram` block visualizing the call flow. Most chat hosts (Claude, ChatGPT, Cursor, GitHub) render Mermaid inline. Lane keying: by default participants are keyed by IP, not `ip:port`, so an endpoint that sends from an ephemeral source port and listens on 5060 collapses into one column. Multi-port IPs list their ports in the participant label (e.g. `10.0.0.1 :5060,:53412`) and arrows touching them get a `(:srcPort→:dstPort)` suffix. Pass `groupByIp: false` to restore the legacy one-column-per-`ip:port` layout. Lane labeling: aliases are matched against (in order) `${ip}:${port}` from message source/dest, then bare `${ip}`, then top-Via host, then Contact host. The most-specific match wins. When no alias matches the renderer falls back to the peer's address rather than emitting `unknown:5060`. Pair with: `minimize_sip_trace` first to compact a noisy trace; `diff_sip_messages` when two adjacent INVITEs in the ladder differ unexpectedly; `lint_sip_request` to validate a single message you pulled from the ladder.

  ConnectorNo auth

• sip_ladder_exampleA

  SipflowA

  [cost: free (pure CPU, no network) | read-only] Return a hand-curated SIP scenario as a Mermaid `sequenceDiagram` plus a bullet list of step-by-step explanations with RFC references. Use this when the user asks 'show me what X looks like' and you don't have a real trace handy. Available scenarios: basic-call, auth-challenge, cancel-before-answer, early-media, hold-resume, refer-blind, proxy-with-record-route, shaken-attested-invite, bye-glare, redirect-302. Pair with: `search_sip_docs` for vendor-specific quirks of the scenario; `render_sip_ladder` if the user does have a real trace.

  ConnectorNo auth

• render_mermaidA

  Diagrams MCPA

  Render a Mermaid diagram definition and return the image with metadata. The definition should be valid Mermaid syntax (e.g. flowchart, sequence, class, ER, state, or Gantt diagram). Returns a list of content blocks: the rendered image plus a JSON text block with metadata including a mermaid.live edit link for opening the diagram in a browser editor. Args: definition: Mermaid diagram definition text. filename: Output filename without extension. format: Output format — ``"png"`` (default), ``"svg"``, or ``"pdf"``. download_link: If True, return a temporary download URL path (/images/{token}) that expires after 15 minutes; if False, return inline image bytes. Defaults to True (URL) — set ``DIAGRAMS_INLINE_DEFAULT=true`` on the server to flip the default. SVG/PDF and PNGs larger than the inline limit always use a download link.

  ConnectorNo auth

• append_doc_sectionA

  DockA

  Append a chunk of Markdown to the END of a workspace's doc body. Designed for crons + ingest agents that produce content in timestamped chunks (changelog updates, daily standups, batch summaries). Same markdown surface as update_doc: supports CommonMark, GFM, **`` inline images** (any publicly-reachable HTTPS URL), **lone video URLs** (`.mp4`/`.webm`/`.mov`/`.mkv`/`.m4v` → native `<video>` player, 5 GB per file), ```mermaid diagrams, $math$/$$math$$ KaTeX, > [!NOTE]/[!TIP]/[!IMPORTANT]/[!WARNING]/[!CAUTION] callouts, ```svg sanitized embeds, <details><summary>X</summary>...</details> toggles, [[slug]] cross-references, [@Label](dock:mention/<kind>/<id>) @-mentions of users + agents, and lone-URL embeds (YouTube/Vimeo/Loom/Figma/CodePen/gists). Server fetches the current body, splices the new blocks on, and writes the result through the same path as update_doc with the same auth, same events, same byte/depth/node-count guard. Append is non-idempotent by design (every call adds content); the caller is responsible for dedupe. @-mentions inside the appended chunk fire `doc.mention_added` + inbox/email fan-out for newly-added mentions only — appending a chunk that re-mentions someone already mentioned earlier in the doc won't re-fire. Requires editor role. Multi-surface workspaces optionally accept `surface_slug` to append to a specific doc tab.

  ConnectorNo auth

• executeA

  Agentic MermaidA

  Run JavaScript in an isolated sandbox; return a value. One call composes edits. Submit JavaScript; declaration types are guidance. No promises, async/await, dynamic import, or type annotations. Hosted note: execute runs in an on-demand isolate and costs more than the direct render_svg/render_ascii/render_png/verify/describe tools — prefer those for plain render/verify calls. For straightforward structured edits, prefer the declarative mutate/build tools; reserve execute for logic the ops don't express. Hosted mermaid.renderMermaidSVG*, renderMermaidASCII*, and layoutMermaidWithReceipt calls force security:'strict' and embedFontImport:false; caller code cannot weaken that host policy. SDK declaration: type DiagramKind = 'flowchart' | 'state' | 'sequence' | 'timeline' | 'class' | 'er' | 'journey' | 'architecture' | 'xychart' | 'pie' | 'quadrant' | 'gantt' | 'mindmap' | 'gitgraph' | 'radar' type MutationOp = { kind: string; [field: string]: unknown } type Result<T, E = { code: string; message: string }> = { ok: true; value: T } | { ok: false; error: E } interface SourceLocation { readonly line: number; readonly col: number } interface SourceMapSpans { readonly preserved: PreservedSourceSpans; readonly nodes: ReadonlyMap<string, SourceSpan>; readonly edges: ReadonlyMap<string, SourceSpan>; readonly groups: ReadonlyMap<string, SourceSpan>; readonly labels: ReadonlyMap<string, SourceSpan> } interface SourceMap { readonly nodes: ReadonlyMap<string, SourceLocation>; readonly edges: ReadonlyMap<string, SourceLocation>; readonly groups: ReadonlyMap<string, SourceLocation>; readonly labels: ReadonlyMap<string, SourceLocation>; readonly spans?: SourceMapSpans } interface ValidDiagram { readonly kind: DiagramKind; readonly source: SourceMap } type ExternalFamilyId = `family:${string}` interface ExtensionCompatibility { readonly [contract: string]: string | undefined readonly core?: string readonly scene?: string } interface ExtensionProvenance { readonly owner: string; readonly source: string; readonly reference?: string } interface ExtensionIdentity<Kind extends string = string> { readonly id: `${Kind}:${string}` readonly kind: Kind readonly version: string readonly compatibility: ExtensionCompatibility readonly provenance: ExtensionProvenance } interface SourceSpanPoint { readonly offset: number; readonly line: number; readonly col: number } interface SourceSpan { readonly start: SourceSpanPoint; readonly end: SourceSpanPoint } interface PreservedSourceSpans { readonly source: SourceSpan readonly wrapper?: SourceSpan readonly frontmatter?: SourceSpan readonly initDirectives?: readonly SourceSpan[] readonly accessibilityDirectives?: readonly SourceSpan[] readonly header: SourceSpan readonly body: SourceSpan } interface SourcePreservationReceipt { readonly version: 1 readonly classification: 'unsupported' | 'inventory-only' | 'unknown' readonly source: string readonly header: string readonly upstreamFamilyId?: string readonly mermaidVersion: string readonly spans?: PreservedSourceSpans } interface ParseError { readonly code: string readonly message: string readonly line?: number readonly col?: number readonly preservation?: SourcePreservationReceipt readonly help?: string } interface ExtensionValidDiagram { readonly kind: ExternalFamilyId readonly descriptorIdentity: ExtensionIdentity<'family'> readonly source: SourceMap } interface PreservedValidDiagram { readonly kind: ExternalFamilyId readonly source: SourceMap readonly body: { readonly kind: 'preserved' readonly representation: 'opaque' | 'unknown' readonly source: string readonly preservation: SourcePreservationReceipt readonly spans: PreservedSourceSpans readonly diagnostic: { readonly code: 'UNSUPPORTED_FAMILY' | 'UNKNOWN_HEADER' | 'FAMILY_DESCRIPTOR_MISMATCH' readonly message: string readonly help: string } } } type ParsedDiagram = ValidDiagram | ExtensionValidDiagram | PreservedValidDiagram type RenderedRegionKind='node'|'edge'|'label'|'canvas'|'group'|'cluster'|'lane'|'band'|'compartment'|'plot'|'ring' type DiagramActionSecurity='safe'|'unsafe'|'source-only'|'unsupported' interface RenderedRegion { id:string;kind:RenderedRegionKind;elementId?:string;parentId?:string;bounds:{x:number;y:number;w:number;h:number};sourceLine?:number } interface DiagramActionRecord { id?:string;regionId?:string;family:DiagramKind;target:string;action:'href'|'call'|'callback';raw:string;line?:number;href?:string;security:DiagramActionSecurity;executable:false;message?:string } interface RenderedLayout { version: 1; kind: DiagramKind | ExternalFamilyId; bounds: { w: number; h: number }; nodes: unknown[]; edges: unknown[]; groups: unknown[]; regions?: RenderedRegion[]; actions?: DiagramActionRecord[] } interface VerifyResult { ok: boolean; warnings: unknown[]; layout: RenderedLayout } type CheckMermaidSpec = string[] | { include?: string[]; exclude?: string[]; exact?: boolean } interface CheckMermaidResult { ok: boolean; missing: string[]; unexpected: string[]; facts: string[] } type MermaidConfigScalar = string | number | boolean | null type MermaidConfigValue = MermaidConfigScalar | MermaidConfigValue[] | { [key: string]: MermaidConfigValue | undefined } type MermaidRuntimeConfig = { [key: string]: MermaidConfigValue | undefined } interface StyleColors {bg?:string;fg?:string;line?:string;accent?:string;muted?:string;surface?:string;border?:string} type SceneStyleRole="node"|"edge"|"edge-label"|"group"|"group-header"|"label"|"actor"|"lifeline"|"activation"|"message"|"block"|"note"|"class-box"|"member"|"entity"|"attribute"|"relationship"|"cardinality"|"pie-slice"|"legend"|"bar"|"series"|"point"|"axis"|"grid"|"plate"|"section"|"task"|"milestone"|"marker-line"|"rail"|"period"|"event"|"score"|"actor-pill"|"service"|"junction"|"icon"|"title"|"defs"|"prelude"|"chrome" type ExactSceneStyleRole="node"|"edge"|"group"|"group-header"|"label"|"actor"|"relationship"|"pie-slice"|"legend"|"bar"|"series"|"point"|"task"|"milestone" type BindableSceneStyleRole="group-header"|"actor"|"relationship"|"pie-slice"|"legend"|"bar"|"series"|"point"|"task"|"milestone" type RoleStyleSpec={"fontFamily"?:string;"fontSize"?:number;"fontWeight"?:number;"letterSpacing"?:number;"textTransform"?:"uppercase"|"lowercase"|"capitalize";"textColor"?:string;"paddingX"?:number;"paddingY"?:number;"cornerRadius"?:number;"lineWidth"?:number;"bendRadius"?:number;"fillColor"?:string;"borderColor"?:string;"strokeColor"?:string;"headerFillColor"?:string;"cue"?:"none"|"outline"|"double-line"|"pattern"} type RoleStyleFor<R extends ExactSceneStyleRole>=R extends "node"|"actor"?Pick<RoleStyleSpec,"borderColor"|"cornerRadius"|"fillColor"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"paddingX"|"paddingY"|"textColor"|"textTransform">:R extends "edge"|"relationship"?Pick<RoleStyleSpec,"bendRadius"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"strokeColor"|"textColor"|"textTransform">:R extends "group"?Pick<RoleStyleSpec,"borderColor"|"cornerRadius"|"fillColor"|"fontFamily"|"fontSize"|"fontWeight"|"headerFillColor"|"letterSpacing"|"lineWidth"|"paddingX"|"paddingY"|"textColor"|"textTransform">:R extends "group-header"?Pick<RoleStyleSpec,"borderColor"|"cue"|"fillColor"|"fontFamily"|"fontSize"|"fontWeight"|"letterSpacing"|"lineWidth"|"strokeColor"|"textColor"|"textTransform">:R extends "label"?Pick<RoleStyleSpec,"fontSize"|"fontWeight"|"letterSpacing"|"textColor"|"textTransform">:R extends "pie-slice"|"task"|"milestone"?Pick<RoleStyleSpec,"borderColor"|"cue"|"fillColor"|"lineWidth"|"strokeColor">:R extends "legend"?Pick<RoleStyleSpec,"borderColor"|"fillColor"|"lineWidth"|"strokeColor"|"textColor">:R extends "bar"|"point"?Pick<RoleStyleSpec,"borderColor"|"fillColor"|"lineWidth"|"strokeColor">:R extends "series"?Pick<RoleStyleSpec,"borderColor"|"lineWidth"|"strokeColor">:never type RoleStyles={[R in ExactSceneStyleRole]?:Readonly<RoleStyleFor<R>>} type SemanticBindingChannel="category" interface SemanticBinding {channel:SemanticBindingChannel;value:string;slot:string;role?:BindableSceneStyleRole} type BrandConstraint={kind:"contrast";action:'warn'|'error';role?:SceneStyleRole;minimum?:number}|{kind:"accent-area";action:'warn'|'error';maxFraction:number}|{kind:"mono-role";action:'warn'|'error';role:SceneStyleRole} interface StyleSpec {"formatVersion"?:1;"$schema"?:string;"name"?:string;"blurb"?:string;"colors"?:StyleColors;"font"?:string;"roles"?:RoleStyles;"semanticSlots"?:Readonly<Record<string,Readonly<RoleStyleSpec>>>;"bindings"?:readonly SemanticBinding[];"constraints"?:readonly BrandConstraint[];"stroke"?:"crisp"|"jittered"|"freehand";"roughness"?:number;"bowing"?:number;"passes"?:number;"strokeWidth"?:number;"fill"?:"none"|"hachure"|"solid"|"wash";"hachureAngle"?:number;"hachureGap"?:number;"fillWeight"?:number;"washOpacity"?:number;"washEdge"?:number;"backdrop"?:"plain"|"paper-ruled"|"grid";"intent"?:"premium"|"draft"|"lofi";"mono"?:boolean} type StyleInput=string|StyleSpec type ArchitectureVisualOverrides = Readonly<Record<string, unknown>> interface SharedRenderOptions { bg?:string;fg?:string;line?:string;accent?:string;muted?:string;surface?:string;border?:string;font?:string;style?:StyleInput | StyleInput[];padding?:number;nodeSpacing?:number;layerSpacing?:number;wrappingWidth?:number;componentSpacing?:number;transparent?:boolean;interactive?:boolean;shadow?:boolean;class?:{ hierarchicalNamespaces?:boolean };architecture?:{ visual?:ArchitectureVisualOverrides };timeline?:{ maxWidth?:number };journey?:{ experienceCurve?:boolean };gantt?:{ dependencyArrows?:boolean; criticalPath?:boolean };mermaidConfig?:MermaidRuntimeConfig;embedFontImport?:boolean;compact?:boolean;idPrefix?:string;security?:'default' | 'strict';ganttToday?:string;seed?:number;} interface ConfigDiagnostic { code: 'INEFFECTIVE_CONFIG'; field: string; message: string } interface TerminalProjectionDiagnostic { code: string; feature: string; message: string } interface SvgRenderOptions extends SharedRenderOptions { onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;} interface AsciiRenderOptions extends SharedRenderOptions { useAscii?:boolean;paddingX?:number;paddingY?:number;boxBorderPadding?:number;colorMode?:'auto' | 'none' | 'ansi16' | 'ansi256' | 'truecolor' | 'html';theme?:{ fg?:string; border?:string; line?:string; arrow?:string; accent?:string; bg?:string; corner?:string; junction?:string };maxWidth?:number;targetWidth?:number;onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;onProjectionDiagnostic?:(diagnostic: TerminalProjectionDiagnostic) => void;} interface LayoutRenderOptions extends SharedRenderOptions { debug?:boolean;regions?:boolean;actions?:boolean;onConfigDiagnostic?:(diagnostic: ConfigDiagnostic) => void;} interface RenderArtifactDiagnostic { code: string; message?: string; reference?: string; feature?: string; input?: string; canonicalId?: string; removal?: { release: string; date: string } } interface CapabilityResolution { readonly id: `${string}:${string}`; readonly range: string; readonly level: 'required' | 'preferred' | 'optional'; readonly status: 'selected' | 'unsupported' | 'incompatible'; readonly version?: string } interface CapabilityDecision { readonly version: 1; readonly accepted: boolean; readonly resolutions: readonly CapabilityResolution[] } interface RenderExecutionDecision { readonly family: { readonly id: string; readonly version: string };readonly backend: { readonly mode: 'scene'; readonly requestedId: string; readonly selectedId: string; readonly version: string; readonly hostPolicy: boolean } | { readonly mode: 'family-svg' };readonly digest: string;} interface RenderRequestReceipt { version: 2; output: 'svg' | 'png' | 'ascii' | 'unicode' | 'html' | 'layout'; sharedRequestDigest: string; requestDigest: string; appearanceDigest: string; capabilityDecision: CapabilityDecision; diagnostics?: readonly RenderArtifactDiagnostic[]; graphicalProjectionDigest?: string; executionDecision?: RenderExecutionDecision } interface RenderedSvg { svg: string; receipt: RenderRequestReceipt } interface RenderedAscii { text: string; receipt: RenderRequestReceipt; terminalStyle: Record<string, unknown>; outputPolicy: Record<string, unknown> } interface RenderedLayoutArtifact { layout: VerifyResult['layout']; receipt: RenderRequestReceipt } declare const mermaid: { parseRegisteredMermaid(source: string): Result<ParsedDiagram, ParseError[]> createMermaid(kind: DiagramKind, opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): ValidDiagram buildMermaid(kind: DiagramKind, ops: MutationOp[], opts?: { direction?: 'TD' | 'TB' | 'LR' | 'BT' | 'RL' }): Result<ValidDiagram, { code: string; message: string; opIndex: number }> asFlowchart(diagram: ValidDiagram): ValidDiagram | null asState(diagram: ValidDiagram): ValidDiagram | null asSequence(diagram: ValidDiagram): ValidDiagram | null asTimeline(diagram: ValidDiagram): ValidDiagram | null asClass(diagram: ValidDiagram): ValidDiagram | null asEr(diagram: ValidDiagram): ValidDiagram | null asJourney(diagram: ValidDiagram): ValidDiagram | null asArchitecture(diagram: ValidDiagram): ValidDiagram | null asXyChart(diagram: ValidDiagram): ValidDiagram | null asPie(diagram: ValidDiagram): ValidDiagram | null asQuadrant(diagram: ValidDiagram): ValidDiagram | null asGantt(diagram: ValidDiagram): ValidDiagram | null asMindmap(diagram: ValidDiagram): ValidDiagram | null asGitGraph(diagram: ValidDiagram): ValidDiagram | null asRadar(diagram: ValidDiagram): ValidDiagram | null mutate(diagram: ValidDiagram, op: MutationOp): Result<ValidDiagram> verifyMermaid(input: ParsedDiagram | string, opts?: { suppress?: string[]; labelCharCap?: number; renderOptions?: SharedRenderOptions }): VerifyResult analyzeMermaid(diagram: ValidDiagram): Record<string, unknown> analyzeMermaidSource(source: string): Result<Record<string, unknown>> describeMermaidFacts(diagram: ValidDiagram): string[] describeMermaidFactsSource(source: string): Result<string[]> checkMermaid(diagram: ValidDiagram, spec: CheckMermaidSpec): CheckMermaidResult checkMermaidSource(source: string, spec: CheckMermaidSpec): Result<CheckMermaidResult> serializeMermaid(diagram: ParsedDiagram): string renderMermaidSVG(input: ParsedDiagram | string, opts?: SvgRenderOptions): string renderMermaidSVGWithReceipt(input: ParsedDiagram | string, opts?: SvgRenderOptions): RenderedSvg renderMermaidASCII(input: ParsedDiagram | string, opts?: AsciiRenderOptions): string renderMermaidASCIIWithReceipt(input: ParsedDiagram | string, opts?: AsciiRenderOptions): RenderedAscii layoutMermaidWithReceipt(input: ParsedDiagram | string, opts?: LayoutRenderOptions): RenderedLayoutArtifact describeOps(family: DiagramKind): Record<string, { name: string; required: boolean; type: string; note?: string }[]> opSignatures(family: DiagramKind): string[] }

  ConnectorNo auth

• create_diagramA

  FlowgrafA

  Create a NEW architecture diagram from a graph that YOU author, and get back a shareable, editable canvas URL plus a rendered SVG and Mermaid. You produce only the SEMANTICS — nodes, the groups (VPC/cluster/...) they live in, and the directed edges between them. You do NOT lay anything out: never send x/y/position/pinned. A deterministic layout engine computes all geometry and an icon layer picks the pictures from each node's kind. kind.catalog is one of aws | gcp | azure | k8s | saas | generic, each with rich per-catalog kind.types (e.g. aws:lambda, gcp:bigquery, azure:cosmos_db, k8s:deployment, saas:kafka): - "aws" (api_gateway, lambda, s3, rds, dynamodb, sqs, bedrock, kinesis, fargate, eventbridge, aurora, ...). - "gcp" (compute_engine, gke, cloud_run, cloud_sql, spanner, firestore, bigquery, pubsub, dataflow, vertex_ai, ...). - "azure" (virtual_machine, aks, app_service, functions, blob_storage, sql_database, cosmos_db, service_bus, event_hubs, key_vault, ...). - "k8s" (pod, deployment, statefulset, daemonset, job, cronjob, service, ingress, configmap, secret, hpa, ...). - "saas" for hosted third-parties (redis, postgresql, mysql, mongodb, kafka, stripe, twilio, auth0, github, cloudflare, ...). - "generic" primitive when nothing branded fits: service, database, cache, queue, user, external_system, storage, gateway, function, note. - "generic" FLOWCHART kinds for processes/flowcharts: process, decision, terminator, data, document, subprocess. edge.kind is one of: request, response, async_event, data_flow, dependency, network, generic. WORKED EXAMPLE — a user hitting an API in a VPC that talks to Postgres: { "title": "Web API", "domain": "cloud_architecture", "graph": { "groups": [{ "id": "g_vpc", "label": "VPC", "type": "vpc" }], "nodes": [ { "id": "n_user", "label": "User", "kind": { "catalog": "generic", "type": "user" } }, { "id": "n_api", "label": "API", "kind": { "catalog": "aws", "type": "api_gateway" }, "parentId": "g_vpc" }, { "id": "n_db", "label": "Postgres", "kind": { "catalog": "aws", "type": "rds" }, "parentId": "g_vpc" } ], "edges": [ { "id": "e1", "source": "n_user", "target": "n_api", "kind": "request" }, { "id": "e2", "source": "n_api", "target": "n_db", "kind": "data_flow" } ] } } Returns { diagramId, url, svg, mermaid, version }. Give the user the url — opening it shows the same diagram on an editable canvas (anonymous; it's theirs to claim by signing in). To change the diagram afterwards, use get_diagram then edit_diagram.

  ConnectorNo auth

• render_mindmapA

  MindMapA

  Render an interactive MCP app mind map when the user needs hierarchical structure shown visually instead of as prose. Use it for breaking down ideas, plans, study material, or systems into a root topic with nested branches; do not use it for tables, flowcharts, Mermaid/Graphviz diagrams, or plain text lists. Input `mindmap_markdown` must be a clean markdown tree with one `#` root heading and 2-space-indented bullet nesting. If the user gives prose, first reshape it into that hierarchy, then call this tool.

  ConnectorNo auth

• describe_sdkA

  Agentic MermaidA

  Return version-matched mutation operations for one diagram family. Use detail=signatures for the compact op menu or detail=fields (default) for exact field types, required flags, enum values, defaults, and constraints. Call this before build, mutate, or execute when the family schema is not already known.

  ConnectorNo auth

• render_asciiA

  Agentic MermaidA

  Render a Mermaid source string to text. Returns { ok, text }. useAscii true → plain ASCII (+,-,|); false/absent → Unicode box drawing (┌,─,│). targetWidth sets a hard terminal display-cell bound; impossible bounds return a typed error.

  ConnectorNo auth

• map_business_processA

  ALM X++ MCP ServerA

  WHEN: mapping the technical D365 objects behind a business process, or understanding which tables/forms implement a flow. Triggers: 'processus métier', 'Order-to-Cash', 'Procure-to-Pay', 'Record-to-Report', 'business process flow', 'qui est impliqué dans', 'map the process', 'flux du processus', 'quels objets dans le flux'. Map a D365 F&O business process to its complete object chain. For known processes (Order-to-Cash, Procure-to-Pay, Record-to-Report, Plan-to-Produce, Inventory-Management, Hire-to-Retire, Project-Accounting, Asset-Lifecycle): shows every step with forms, tables, classes, entities, reports, and security roles involved. For any other object name: traces all dependencies (tables, classes, forms, entities) from that entry point. Produces a Mermaid process flow diagram. Use 'list' to see all known process mappings. NOT for a single object's FK relations only -- use `find_related_objects` for that (faster and more precise).

  ConnectorNo auth

• generate_diagramA

  ALM X++ MCP ServerA

  WHEN: generating a visual diagram of D365 table relationships or security chains. Triggers: 'generate diagram', 'diagramme', 'visualize', 'schéma', 'ER diagram', 'entity-relationship', 'relation diagram', 'security diagram', 'show connections'. Generate visual Mermaid diagrams from D365 F&O knowledge base data. Diagrams render directly in Copilot Chat, Cursor, Claude, and markdown viewers. Types: 'er' (entity-relationship diagram for a table and its relations), 'security' (security chain: Role->Duty->Privilege->EntryPoints -- use when you need a VISUAL Mermaid diagram; for the structured text chain with tables of duties/privileges/entry-points use `trace_security_chain` instead). Note: 'flow' (execution flowchart) is disabled -- static call trees are misleading in D365 due to CoC and event handlers.

  ConnectorNo auth

• get_guideA

  CanvsA

  Returns guidance on diagram-creation workflow and tool selection: how to choose between Mermaid and manual element creation, and the recommended iteration workflow. Consult before building complex diagrams.

  ConnectorNo auth

• add_elementsA

  CanvsA

  Creates elements on a canvas. Creates a new canvas if room_id is omitted, or adds to the existing canvas if room_id is provided. Use cases: wireframes, UI mockups, freeform illustrations, standalone shapes, and manual layouts that Mermaid does not cover well. For diagrams Mermaid can express, use add_elements_from_mermaid instead. Element types: rectangle, ellipse, diamond, arrow, line, freedraw, text, image. Rich text: the text field supports limited HTML for text elements and rectangle/ellipse/diamond shape labels. Supports the rich-text plugin HTML subset: <b>/<strong>, <i>/<em>, <u>, <br>, <div>/<p>, <ul>/<ol>/<li>, <a href>, <font color>, and <span style="color, background/background-color, font-size, font-family">. Use textAlign for left/center/right alignment; avoid unsupported HTML/CSS. TEXT IN SHAPES: use containerId on text element pointing to shape id. ARROWS: Position at EDGE of source shape. Auto-bound within 30px. Colors: strokeColor, backgroundColor (hex).

  ConnectorNo auth

• add_textA

  cnvs.appA

  Create a NEW text node, or update an existing one (pass the same `id` to overwrite content/position in place — preferred over creating a duplicate). Supports cnvs markup (Markdown-ish) and Mermaid diagrams in the content. When using Mermaid, the ENTIRE content of this text node must be a single Mermaid diagram (one ```mermaid fenced block and nothing else — no heading, no prose before or after). If you need prose + a diagram, create two separate text nodes. `postit: true` renders as a yellow sticky; `diagram: true` renders as a framed box (2px border in the text colour, centred text) — the two are mutually exclusive. Coordinates are in board-world pixels, +x right, +y DOWN; pick a spot that does not overlap existing items (check `get_preview` first). Default width auto-fits content up to ~320 px; pass `width` for explicit wrapping (160–4096). Keep content under 100 000 chars.

  Connector

  Destructive

  No auth