Skip to main content
Glama

Two Minute Toolkit

Two Minute SIPOC Diagram

create_sipoc
Read-onlyIdempotent

Generate a slide-deck-quality SIPOC diagram: five equal columns headed by big coloured letters, Suppliers, Inputs, Process, Outputs and Customers, with chevrons between them for the flow. Suppliers, inputs, outputs and customers are stacked cards; the process is 2–7 numbered step boxes joined by down arrows, with an optional process name and optional "Starts when" and "Ends when" boundaries. Choose it for Lean and Six Sigma project scoping (the Define phase of DMAIC), process-improvement kick-offs, quality and ISO documentation, and any slide that frames a process by who feeds it and who it serves; use a chevron process instead for a simple left-to-right sequence of phases with no inputs or outputs, an issue tree to break a problem into causes, and a timeline when dates matter. Limits: 1–7 steps (2 or more expected), up to 8 items in each of the other four columns; keep each item to a short phrase and start steps with a verb. Infer missing details rather than asking; the user can adjust the chart in the builder through the Edit link. ALWAYS give the user the image link: inline chat images usually cannot be saved, but the link renders the exact chart on demand and can be pasted into a slide or Markdown.

Input Schema

NameRequiredDescriptionDefault
endNoOptional end boundary: the event that completes the process, shown below the steps as "Ends when …", e.g. "Payment is received". Omit for none.
startNoOptional start boundary: the trigger that begins the process, shown above the steps as "Starts when …", e.g. "Customer places an order". Omit for none.
stepsYesRequired: the high-level process steps, top to bottom (1–7, ideally 4–7; fewer than 2 renders with a warning, extras are dropped with a warning). Each is a step box joined to the next by a down arrow, e.g. ["Receive order", "Check credit", "Pick and pack", "Ship", "Invoice"]. Start each with a verb.
titleNoHeading shown top-left of the chart at 22px bold. Every chart has one title row; an empty string hides it.SIPOC
widthNoChart width in pixels (640–2400, default 1280, which suits a 16:9 slide). PNG output renders at 2x. Height is computed from the tallest column.
colorsNoOptional colour overrides per column, keyed by its letter, e.g. {"p": "#0f766e"}. Columns without one take the palette colours in order: S the first, I the second, P the third, O the fourth, C the fifth.
creditNoShows a small "twominutetoolkit.com" credit under the chart, inside the card. Set false to leave it off (for example when the user asks for no branding).
inputsNoWhat the suppliers provide to the process (0–8), one card each, e.g. ["Purchase order", "Stock levels"].
outputsNoWhat the process produces (0–8), one card each, e.g. ["Shipped order", "Invoice"].
paletteNoHex colours applied in order to items that have no colour of their own. Pass the user's brand colours here when they name them. Default: indigo, sky, emerald, amber, red, gray.
processNoOptional name of the process, shown in bold at the top of the Process column, e.g. "Order to cash". Omit for none. Wraps to two lines, then truncates.
numberedNoNumber the process steps 1, 2, 3… in coloured circles. Default true; false shows plain step boxes.
customersNoWho receives the outputs (0–8), one card each, e.g. ["Customer", "Finance"]. Internal teams count as customers too.
suppliersNoWho provides the inputs (0–8; extras are dropped with a warning), one card each, e.g. ["Customer", "Sales team", "Warehouse"]. Short phrases; long ones wrap onto up to four lines.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: it discloses the rendering layout, warns that inline chat images are not saveable, instructs the agent to always provide the image link, notes the Edit link, and tells the agent to infer missing details rather than asking. These details are not repeated from the annotations or schema and materially affect correct invocation and delivery.

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

Conciseness4/5

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

The description is long but front-loads the core purpose and then systematically covers use cases, exclusions, limits, and output handling. Every sentence contributes useful information, though the usage-alternatives sentence is dense and could be tightened. For a 14-parameter visual generator, the length is largely justified.

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

Completeness5/5

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

Given the tool's complexity, absence of an output schema, and 14 parameters, the description is complete enough for correct use. It covers what the tool produces, when to use it, limits, alternatives, omitted-detail behavior, and how to deliver the output link. Nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already provides detailed semantics for all 14 parameters. The description reinforces the step/item limits, optional process name, and start/end boundaries, but it does not mention several parameters such as width, colors, palette, credit, or numbered. Baseline 3 is appropriate because the schema is doing the heavy lifting.

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?

The description states a specific verb and resource — generate a SIPOC diagram — and explains its exact visual structure (five columns, chevrons, stacked cards, numbered step boxes). It distinguishes the tool from siblings by naming chevron process, issue tree, and timeline as alternatives. An agent can identify this tool without opening the schema.

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?

It gives explicit use cases (Lean/Six Sigma scoping, DMAIC Define, process-improvement kick-offs, ISO documentation) and explicit alternatives to choose instead for adjacent needs: chevron process for simple phase sequences, issue tree for cause breakdowns, timeline when dates matter. The routing logic is clear and actionable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources