Skip to main content
Glama

Two Minute Toolkit

Two Minute Issue Tree

create_issue_tree
Read-onlyIdempotent

Generate a slide-deck-quality issue tree or driver tree: a key question, problem or top-line metric on the left, broken down left to right into drivers, sub-drivers and hypotheses in clean columns of rounded boxes joined by elbow connectors. Each first-level branch takes its own palette colour. Any box can carry a value ("$12.4m", "+3% YoY") and any parent an operator ("+", "-", "x", "/", drawn as + − × ÷ where its children join) for KPI and value driver trees (Profit = Revenue − Costs; Revenue = Customers × Revenue per customer); levels labels the columns and numbered adds 1, 1.1, 1.1.1. Choose it for consulting issue trees and MECE breakdowns, hypothesis trees, KPI, value and driver trees, root-cause and problem trees: anything where a parent is logically made up of its children. Use a mind map instead for loose brainstorms radiating from a centre with no hierarchy logic or values, and an org chart for people and reporting lines. Limits: 4 levels including the root, up to 6 children per box, 40 boxes; keep labels 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 key question, problem or top-line metric on the left (e.g. "Why has profitability declined?" or "Operating profit"), with its drivers nested in `children`. Limits: 4 levels in total including the root, up to 6 children per box and 40 boxes; extras are dropped with a warning, deepest levels and last-listed boxes first.
titleNoHeading shown top-left of the chart at 22px bold. Every chart has one title row; an empty string hides it.Issue 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).
levelsNoOptional column labels, left to right, printed in small caps above each level, e.g. ["Key question", "Drivers", "Sub-drivers", "Hypotheses"] (0–4). Omit for none.
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.
numberedNoPrefix every box below the root with its outline number, 1, 1.1, 1.1.1, as consultants number issue trees. Default false.

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 already cover safety (readOnlyHint, idempotentHint), but the description adds substantial non-obvious behavior: hard limits (4 levels, 6 children, 40 boxes) with the truncation rule ('extras are dropped with a warning, deepest levels and last-listed boxes first'), the instruction to infer missing details rather than ask, the builder Edit link, and the crucial caveat that inline chat images can't be saved so the link must always be given.

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 purpose and the 'choose it for / use X instead' routing are front-loaded, and the trailing operational guidance about limits, inference and the image link earns its place. It is a single dense paragraph though, and the layout description in the first sentence runs long relative to the decision-relevant content.

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 complex, deeply nested chart-generation tool with no output schema, the description supplies everything an agent needs: structural limits, the semantic choice between issue tree and value driver tree, nesting/colour/operator conventions, and explicit post-call instructions for surfacing the returned image link. Sibling differences are also resolved in-text.

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 every parameter including the nested node fields is already documented in structured data. The description reinforces the semantics of `value`, `operator`, `levels` and `numbered` through worked KPI examples (Profit = Revenue − Costs), which aids comprehension but adds little the schema doesn't already say. 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?

States a specific verb and resource ('Generate a slide-deck-quality issue tree or driver tree') and then describes the concrete visual output: key question on the left, broken into drivers/sub-drivers/hypotheses in columns of rounded boxes with elbow connectors. It actively distinguishes itself from siblings, naming mind map and org chart as the wrong tools for this job.

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?

Explicitly enumerates when to choose it (consulting issue trees, MECE breakdowns, hypothesis trees, KPI/value/driver trees, root-cause and problem trees) with the governing rule 'anything where a parent is logically made up of its children'. It also names what to use instead and the condition that selects it: mind map for loose brainstorms, org chart for people/reporting lines.

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