Skip to main content
Glama

triz_export

Export a type-checked function model as Graphviz DOT, Mermaid, SVG, or open hypergraph; invalid models are rejected with errors.

Instructions

Export a function model that type-checks: 'dot' gives Graphviz DOT (each box a table: name and «role» in a role-coloured header, input ports left and output ports right with their carriers, open ports in italics; functions as edges between ports, harmful red, insufficient dashed, excessive bold; flows dotted blue; a legend of what occurs; render with dot -Tsvg), 'mermaid' gives a Mermaid flowchart that GitHub, GitLab, and many chat clients render without tools (Mermaid has no ports, so each edge names its out port, in port, and carrier), 'svg' gives a self-contained SVG picture with dot's conventions, laid out by ELK with orthogonal edges, for when Graphviz is not at hand (stdio server only: it needs the optional elkjs package; the hosted server answers ok:false with format-unavailable), 'hypergraph' gives an open hypergraph (ports as carrier-typed vertices, boxes and functions as hyperedges, unwired ports as the interface). A model that fails the type-check is not exported (ok:false with the errors).

Input Schema

NameRequiredDescriptionDefault
modelYes
formatYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the burden well: it discloses the type-check gate, the failure return (ok:false with the errors), the svg-only optional dependency on elkjs, and the hosted-server behavior (ok:false with format-unavailable). It does not say the operation is non-mutating/read-only or whether large models are truncated, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core statement is front-loaded, but the body is one run-on sentence built from stacked parentheticals and semicolons, making the per-format guidance hard to scan. It is information-dense rather than padded, but a bulleted or per-format breakdown would read far better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description explains only the failure envelope (ok:false with errors / format-unavailable), never what a successful call returns — a string of DOT text, an SVG document, a JSON wrapper? For a tool whose whole job is producing an artifact, that is a material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Top-level schema coverage is 0%, so the description has to carry the format enum — and it does, explaining what each of dot/mermaid/svg/hypergraph yields and its constraints. The 'model' parameter is left entirely to the (rich) $ref schema, so half the parameter surface is unaddressed in prose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Export a function model') and enumerates the four output artifacts by name, so an agent knows exactly what it produces and how it differs from siblings like triz_function_model or triz_graph.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Selection guidance is given per format: mermaid for clients that render without tools, svg 'for when Graphviz is not at hand', hypergraph for an open interchange structure, dot for the canonical picture. It also names the precondition (the model must type-check) that gates any use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.