Skip to main content
Glama

Two Minute Toolkit

Two Minute Decision Tree

create_decision_tree
Read-onlyIdempotent

Generate a slide-deck-quality decision tree drawn left to right in clean columns of rounded boxes, in the decision-analysis convention: a square where a decision splits into options, a circle where chance splits into events, and a triangle at each end outcome. Branch lines carry an optional label ("Yes", "No", an option) and, under a chance node, the probability ("Strong demand · 60%"); end outcomes can carry a numeric payoff, lined up in a column at the right (prefix "$", suffix "m"). Expected values are rolled back automatically once the tree has payoffs and probabilities: every decision and chance node shows its EV, each decision's best option is drawn in the accent colour and the rejected ones are muted with a ‖ prune mark; probabilities that don't add up to 100% are warned about and drawn as given. Node types are inferred (branches with probabilities make a chance node, no branches an outcome, otherwise a decision), so a plain yes/no troubleshooting or eligibility flowchart is just questions with "Yes"/"No" labels and no numbers. Choose it for choosing between options under uncertainty (launch, invest, build vs buy, litigate or settle), expected-value and decision-analysis homework, and yes/no question flowcharts; use an issue tree instead to break a problem or metric into its parts, a chevron process for steps in order, and a Harvey ball matrix to score options against criteria. Limits: 5 levels including the root, up to 5 branches per node, 40 nodes; keep names to a few words. 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
rootYesThe first decision or question, on the left (e.g. "Launch strategy for Atlas" or "Does the laptop power on?"), with its branches nested in `children`. Limits: 5 levels in total including the root, up to 5 branches per node and 40 nodes; extras are dropped with a warning, deepest levels and last-listed nodes first.
titleNoHeading shown top-left of the chart at 22px bold. Every chart has one title row; an empty string hides it.Decision tree
widthNoChart width in pixels (640–2400). Omit it (recommended) and the chart sizes itself to its content with comfortable margins, between 880 and 1280px wide. PNG output renders at 2x.
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).
prefixNoText before every payoff and expected value, e.g. "$", "€" or "£". Default none.
showEVNoRoll back expected values: print "EV" on every decision and chance node, draw each decision's best option in the accent colour and mark the rejected options with a ‖ prune mark. When omitted it is on as soon as the tree has both payoffs and probabilities; set false to hide it, true to show it for decision-only trees with payoffs.
suffixNoText after every payoff and expected value, e.g. "m", "k", "bn" or " pts". Default none.
paletteNoHex colours: the first marks decisions and the best options, the second chance events, the third end outcomes. Pass the user's brand colours here when they name them. Default: indigo, sky, emerald.

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?

Annotations only declare readOnly/idempotent/closed-world, and the description adds substantial behavior beyond that: node types are inferred, EVs roll back automatically and best options are accent-coloured while rejected ones get a prune mark, probabilities not summing to 100% are warned about but still drawn, and overflow is dropped 'deepest levels and last-listed nodes first' with a warning. Hard limits (5 levels, 5 branches, 40 nodes) and the instruction to always return the image link are disclosed too.

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?

It is long but front-loaded: what it draws, then how EV/inference works, then when to choose it, then limits and the link requirement. A few clauses duplicate the input schema's own property descriptions (payoff column, probability warning), which costs it a point, but no sentence is purely filler.

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?

For a rich 8-parameter generative tool with no output schema, the description covers everything an agent needs: how types are inferred so it can omit them, how EV is triggered, the hard structural limits, what happens on invalid probabilities, and the requirement to hand the user the image link. Nothing material 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 explains payoff, probability, label, prefix/suffix, showEV and palette in detail. The description restates the payoff/prefix/suffix convention and the 'Strong demand · 60%' rendering, adding little beyond the schema; the genuinely additive guidance ('infer missing details rather than asking') is workflow, not parameter semantics. Baseline 3 applies.

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 opening sentence names a specific verb and artifact ('Generate a slide-deck-quality decision tree') and pins down the exact visual convention (square/circle/triangle, left-to-right columns). The second half explicitly separates the two supported use cases — decision analysis under uncertainty and plain yes/no flowcharts — so an agent knows precisely what this produces.

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 a positive routing rule ('Choose it for choosing between options under uncertainty... expected-value homework, yes/no flowcharts') and three named exclusions with the sibling that handles each: issue tree for decomposition, chevron process for ordered steps, Harvey ball matrix for criteria scoring. This maps directly onto create_issue_tree, create_process and create_harvey_matrix.

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