trident
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeCan modify data
What it can do
What data it sees
Do you need an account
No: the server works without sign-in
Create and edit collaborative architecture diagrams with any AI assistant using the Trident 2D DSL.
Server tool list (23)
Raw names from tools/list. Only developers need these.
| get_trident_spec | Returns the complete Trident 2D specification including grammar, syntax rules, coordinate system, containers, nodes, connections, shapes, and icon reference. Use this when you need deep understanding of the Trident DSL. |
| get_generator_guide | Returns LLM-optimized instructions for generating Trident diagrams, including quick reference, critical rules (especially Y-axis!), spacing guidelines, common patterns, color conventions, and error prevention checklist. Use this before generating any Trident diagram. |
| get_comprehensive_example | Returns a comprehensive Trident example demonstrating all syntax features including containers, nodes (traditional and bracket-style syntax), diamond/rectangle shapes, icons, connections with labels, routing modes, cards, and text annotations. Use this to see all features in action. |
| validate_trident | Returns a comprehensive validation checklist for Trident diagrams covering syntax rules, semantic rules, best practices, and common mistakes to avoid. Use this after generating a diagram to verify correctness. |
| get_quick_start | Returns a condensed 2-minute quick-start guide with minimal working examples, core syntax reference, and key concepts. Use this for rapid learning when you need to generate simple diagrams quickly. |
| open_document | Opens a live Trident document and returns its full contents as Trident markup DSL — the human-readable text format used to author diagrams. Use this to READ and UNDERSTAND the diagram: its structure, labels, connections, and layout. Do NOT rely on this to enumerate entity IDs for programmatic use — the DSL can be very large and the output may be truncated. To get a complete, structured list of all entity IDs and counts, use get_document_summary instead. Requires a valid access token. |
| get_document_summary | Returns a complete structured summary of a Trident document as JSON: all node IDs, container IDs, connection IDs, annotation IDs, labels, and entity counts. Use this for PROGRAMMATIC OPERATIONS — it is never truncated regardless of diagram size, so you always get every entity ID. Use this before any bulk update, delete, or enumeration task. To read and understand the diagram as a human-readable diagram, use open_document instead. Requires a valid access token. |
| get_recent_changes | Returns the recent change history for a live Trident document. Each entry shows who made the change, what was changed, and when. Useful for understanding what edits have been made by AI agents or human collaborators. Requires a valid access token. |
| add_node | Adds a new node (entity) to a live Trident document. The node appears immediately for all collaborators. Requires a valid editor access token. Before adding nodes: call open_document to understand the diagram layout and pick sensible positions; call get_document_summary to get all existing entity IDs so you can avoid duplicates. IMPORTANT: if this node belongs inside a container, pass node.container on THIS call — do NOT create the node without a container and reparent it later via update_node. Orphaned nodes appear immediately to all live collaborators and create unnecessary visual churn. |
| update_node | Updates properties of an existing node in a live Trident document. Only the fields you provide are changed; others are preserved. Use get_document_summary to get all node IDs before calling this. Requires a valid editor access token. |
| delete_node | Removes a node from a live Trident document. All connections to/from this node are also removed automatically. Use get_document_summary to get all node IDs before calling this. This action is reversible via Ctrl+Z in the Trident editor. Requires a valid editor access token. |
| add_container | Adds a new container (group/swimlane) to a live Trident document. Containers visually group related nodes. Use get_document_summary to check existing container IDs before adding to avoid duplicates. Requires a valid editor access token. |
| update_container | Updates properties of an existing container in a live Trident document. Only provided fields are changed. Use get_document_summary to get all container IDs before calling this. Requires a valid editor access token. |
| delete_container | Removes a container from a live Trident document. By default, nodes inside are detached (kept on the diagram without a container). Pass deleteNodes: true to remove the container's nodes as well. Use get_document_summary to get all container IDs before calling this. Requires a valid editor access token. |
| add_connection | Adds a connection (arrow/edge) between two nodes in a live Trident document. Use get_document_summary to get valid source and target node IDs before calling this. Requires a valid editor access token. |
| delete_connection | Removes a connection from a live Trident document. Provide either the connectionId, or both source and target node IDs to find and remove the matching connection. Use get_document_summary to get all connection IDs before calling this. Requires a valid editor access token. |
| get_document_png | Renders the current state of a live Trident document as a PNG image directly from the Yjs collaborative session — bypassing Firestore, which may be stale. Returns a base64-encoded PNG. Use this to visually verify that diagram edits look correct before or after making changes. |
| add_annotation | Adds a text annotation to a live Trident document. Two visual styles: style:stickyNote (default — post-it card with colored background, good for notes/callouts) or style:textBody (plain transparent text, good for diagram titles and section labels). Ideal for architectural notes, decision records, section labels, or TODO markers. Appears immediately for all collaborators. Requires a valid editor access token. |
| update_annotation | Updates an existing text annotation in a live Trident document. Only the fields you provide are changed. Use get_document_summary to get all annotation IDs before calling this. Requires a valid editor access token. |
| delete_annotation | Removes a text annotation from a live Trident document. Use get_document_summary to get all annotation IDs before calling this. Requires a valid editor access token. |
| update_canvas_graphic | Repositions or resizes a background image (canvas graphic) in a live Trident document. Use open_document to get the canvas graphic ID and current dimensions — it appears as: image <id> "<url>" at (x, y) width:W height:H. The position at (x, y) is the TOP-LEFT corner. USE THIS BEFORE placing many geographically-positioned nodes: if the background map is small (e.g. width < 700), scale it up so nodes have room to breathe and do not overlap. Requires a valid editor access token. |
| make_suggestion | Posts a visible suggestion to human collaborators watching the document WITHOUT making any changes to the diagram. Use this when you observe something worth flagging — a potential mistake, an improvement, or a question — but want the human to decide. The suggestion appears as a bold "SUGGESTION:" callout in the UI with a radar pulse animation on your presence dot for 10 seconds. Does NOT mutate the diagram. Requires a valid viewer or editor access token. |
| explain | Delivers an explanation payload to human collaborators watching the document, optionally anchored to a specific node or container. Use this when you want to explain what a diagram element represents, why it exists, or how it relates to other parts of the system — without suggesting a change. The explanation appears in the UI attributed to you. Does NOT mutate the diagram. Requires a valid viewer or editor access token. IMPORTANT: this tool automatically pauses (3–15 s, proportional to explanation length) before returning, so the human has time to read. Do NOT add your own artificial delays between explain calls — the pacing is built in. |