Skip to main content
Glama

Two Minute Toolkit

Two Minute Football Field Chart

create_football_field
Read-onlyIdempotent

Generate a slide-deck-quality football field chart, the valuation summary used in banking and corporate-development decks: one floating horizontal bar per method from its low to its high value on a shared axis with round gridlines, the method name and an optional assumption line ("8.0x–10.0x EV/EBITDA") on the left, low and high values printed at the bar ends, up to 3 dashed marker lines (current share price, offer price) and an optional shaded implied range. Choose it for valuation ranges (DCF, trading comps, precedent transactions, 52-week range, analyst targets, LBO) and for any comparison of low–high ranges on one scale, such as salary bands, cost or estimate ranges, or price ranges by scenario. Use a timeline (Gantt) when the ranges are dates, a Harvey ball matrix for scores against criteria, and a pyramid/funnel for stage volumes. Values are plain numbers; set prefix ("$", default), suffix ("m", "/sh", "x") and decimals for display. Limits: 1–12 rows, 0–3 markers; a low above its high is swapped with a warning. 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
rowsYesThe valuation methods, top to bottom (1–12; extra rows are dropped with a warning). Each row is one horizontal bar from low to high on the shared axis, e.g. { "method": "Trading comps", "detail": "8.0x–10.0x EV/EBITDA", "low": 42, "high": 51 }. A row whose low is above its high is swapped and reported as a warning.
rangeNoOptional shaded band behind every row, e.g. the implied valuation range: { "low": 48, "high": 55, "label": "Implied range" }. Its label and values are shown above the band. Omit for none (the default).
titleNoHeading shown top-left of the chart at 22px bold. Every chart has one title row; an empty string hides it.Valuation summary
widthNoChart width in pixels (640–2400, default 1280, which suits a 16:9 slide). PNG output renders at 2x. Height is computed from the number of rows.
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 put before every value, default "$". Use "€", "£" or "" (none), e.g. "" for multiples.$
suffixNoText put after every value, default "" (none). E.g. "m" for $ millions, "/sh" for per share, "x" for multiples, "%" for percentages.
axisMaxNoOptional right end of the value axis, e.g. 70. Omit (recommended) and the axis ends at a round number slightly above the largest value.
axisMinNoOptional left end of the value axis, e.g. 30. Omit (recommended) and the axis starts at a round number slightly below the smallest value. Bars beyond the axis are cut off with a warning.
markersNoOptional vertical dashed reference lines across every row (0–3), each labelled at the top with its label and value, e.g. [{ "label": "Current price", "value": 45.1 }, { "label": "Offer", "value": 52 }]. Default: none.
paletteNoHex colours. Every bar takes the FIRST palette colour unless the row sets its own colour, so a brand colour as the first entry recolours the whole chart. Default: indigo, sky, emerald, amber, red, gray.
decimalsNoDecimal places for every value (0–3), e.g. 2 shows 45.10. Omit (the default) to show each value as given, rounded to at most 2 decimals.
showValuesNoPrint the low and high values just outside each end of every bar. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, closed-world), and the description adds genuinely non-obvious behavior: row/marker limits, automatic low/high swap with a warning, axis clipping of out-of-range bars, permission to infer missing details rather than ask, and the builder Edit link. The critical delivery rule — that inline images usually cannot be saved so the link must always be given — is behavioral context an agent would otherwise miss. Slightly short of 5 because it doesn't say what the response object actually looks like beyond the link.

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?

Front-loaded with purpose and content, then selection rules, then limits, then delivery instructions in a logical order. It is a dense single block — long for one paragraph — but nearly every sentence adds distinct operational value; only the repeated marker/row limit restates what the schema already declares.

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?

Thirteen parameters with nested objects and no output schema, and the description still covers what matters: hard limits, warning behaviors, defaults, the infer-don't-ask policy, post-generation editing, and the mandatory link delivery. An agent could call this correctly on the first attempt from the description alone.

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 coverage is 100% and is exceptionally rich (units, swap behavior, palette first-color rule, decimals default), so the schema carries the parameter burden. The description adds only the display-formatting guidance (plain numbers, prefix/suffix/decimals) and the assumption-line example, which the schema already documents.

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 artifact ("Generate a slide-deck-quality football field chart") and then spells out exactly what that artifact contains: one floating bar per method, shared axis, labels at bar ends, markers, shaded range. Explicitly distinguishes itself from the timeline, Harvey ball matrix, and pyramid siblings.

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?

Gives both a positive selection rule ("Choose it for valuation ranges… and for any comparison of low–high ranges on one scale, such as salary bands, cost ranges") and named alternatives with the condition that selects them (Gantt for dates, Harvey matrix for scores, pyramid/funnel for stage volumes). Nothing is left to inference.

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