Skip to main content
Glama

Two Minute Toolkit

by com.twominutetoolkit
OverviewDiscussionsAdmin

Two Minute RACI Matrix

create_raci
Read-onlyIdempotent

Generate a slide-deck-quality RACI matrix (responsibility assignment matrix): tasks or deliverables as rows, roles or teams as columns, and each cell a rounded letter chip, R Responsible, A Accountable, C Consulted or I Informed, with "A/R" for an owner who also does the work and model: "RASCI" adding S for Support. Rows can be grouped into phases with type: "section" rows; a legend explains the letters. With checks (default on), tasks without exactly one A or without an R get an amber note at the row end ("No A", "2 As", "No R") and every broken rule is returned in warnings; give every task exactly one A and at least one R unless the user's data says otherwise. Choose it for project roles and responsibilities, PMO governance, onboarding and handover plans, and any "who does what" slide; use a Harvey ball matrix instead to score options against criteria, an org chart for reporting lines, and a timeline when the point is when work happens. Limits: 1–10 roles and up to 30 rows (tasks plus sections); keep task names to a short verb phrase and roles to a job title. 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
modelNo"RACI" (Responsible, Accountable, Consulted, Informed) or "RASCI", which adds S for Support. Sets the legend and the builder's click cycle; an S in a RACI chart is still drawn and added to the legend. Default "RACI".RACI
rolesYesColumn headings, left to right: the roles, teams or people, e.g. ["Project manager", "Dev lead", "Design", "Legal"]. 1–10 roles, up to 30 characters each; long names wrap onto up to three lines. Prefer roles over personal names.
tasksYesThe rows, top to bottom (1–30): tasks, deliverables or decisions, each with one cell per role. A row with "type": "section" is a full-width phase heading (e.g. "Discovery") that groups the tasks below it; it has no cells.
titleNoHeading shown top-left of the chart at 22px bold. Every chart has one title row; an empty string hides it.RACI matrix
widthNoChart width in pixels (640–2400, default 1280, which suits a 16:9 slide). PNG output renders at 2x. Height is computed from the content.
checksNoCheck the RACI rules: every task has exactly one A and at least one R (A/R counts as both), and every role is R or A on some task. Tasks that break a rule get an amber dot and a short note ("No A", "2 As", "No R") at the row end, and every broken rule is listed in `warnings`. Default true; set false to hide the notes.
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).
legendNoShow a legend row under the matrix explaining each letter. Default true.
paletteNoHex colours: the first fills R chips, the second tints C chips, the third tints S chips (A is always dark and I light gray, so the letters stay distinct). Pass the user's brand colours here when they name them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds real context beyond them: the amber per-row rule notes, that broken rules surface in a `warnings` field, hard limits of 1–10 roles and 30 rows, and that the chart is editable via an Edit link. The one gap is that it never says how the image link/return value is shaped, though it does insist the link be given to the user.

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?

Purpose, usage, exclusions, limits and the mandatory image-link instruction are all front-loaded and in a sensible order. It is a dense single block rather than scannable sections, and the RACI letter definitions repeat what the schema already says, which costs some tightness.

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 9-parameter generative tool with no output schema, the description covers the shape of the artifact, validation behavior and warnings, size constraints, styling hints, and the required follow-up of surfacing the image link. Nothing an agent needs to call it correctly appears to be missing.

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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining the A/R combined owner case, that `model: "RASCI"` adds S, and that `type: "section"` rows are full-width headings with ignored cells. It does not, however, cover width/palette/credit/legend, which the schema alone must carry.

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 RACI matrix") and then describes the actual artifact: rows are tasks, columns are roles, cells are letter chips with R/A/C/I, plus optional section rows. It explicitly distinguishes itself from siblings (Harvey ball, org chart, timeline), so an agent can pick it without opening a 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?

Names concrete use cases (project roles, PMO governance, onboarding/handover, any "who does what" slide) and explicit when-not cases with the correct alternative tool for each. It also gives an operating rule — infer missing details rather than asking — which removes a common decision point.

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

All Two Minute Toolkit toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources