MCP tools for radars, templates and architecture

These fourteen tools manage radars themselves: list them, create and rename them, give them lanes and a look, delete them, and work with the charter, decisions and boundaries of an Architecture radar. Topics, sharing and publishing are on topics and sharing. Ids and scopes are explained in the MCP reference overview.

Note: A radar you cannot read is reported as "not found", never as forbidden. That is deliberate, so an error never confirms that a radar exists.

Listing, creating and changing radars

list_radars

Lists every radar you own or have been given access to, with blip counts and last activity.

• Scope: radars:read. Read-only.
• Optional: includeArchived (boolean, default false), template (one of the template ids, for example helpdesk, to list only radars on that template across every topic).
• Returns: for each radar, id, name, tagline, blipCount, lastBlipAt, visibility, kind, template, your role and canWrite, plus topic, isDropBox and accessVia: "topic" when they apply. A smart radar reports a blip count of 0 because it owns no rows. read_radar counts what it shows.

create_radar

Creates a new radar: a container for blips about one thing. To group several radars together, use create_topic instead.

• Scope: radars:write. Writes. Putting the new radar straight into a topic with topicId also needs manage access on that topic. Depending on your plan, the call can be refused because the template is not included or because you have reached your radar allowance.
• Required: name (1 to 120 characters).
• Optional:
  • tagline (up to 300) and description (up to 2,000).
  • accent and glyph: one of the values listed in the tool's schema.
  • template: the template id. The schema describes each template. Which templates you can create can depend on your plan. See Templates and lanes.
  • templateConfig: grouping (none or day), collapseDone (boolean), lanes and defaultStatus. Use set_radar_lanes for lanes.
  • theme, commentsEnabled, reactionsEnabled.
  • archiveAfterDays (integer, 0 for never, null for the default).
  • topicId (UUID or null).
• Returns: id, name, template, lanes (the lane ids) and url.

Send tagline for the one-line subtitle. Sending topic is refused, because topic now means the group a radar belongs to. Use topicId for that.

{ "name": "Spring launch", "tagline": "Everything for the April release", "template": "kanban" }

update_radar

Renames a radar, changes its tagline, colour, glyph or template, or archives it. To move it between topics, set_radar_topic is the dedicated tool.

• Scope: depends on the fields. Changing only presentation (tagline, description, accent, glyph, display-only templateConfig) needs radars:write. Changing any of name, archived, topicId, template, templateConfig.lanes, filter, commentsEnabled, reactionsEnabled, archiveAfterDays or theme needs radars:manage and ownership. Writes.
• Required: radarId (UUID), plus at least one field to change.
• Optional: the same fields as create_radar, plus archived (boolean) and filter (only on a smart radar).
• Returns: id, name, archived, template and lanes.

The drop box can only use a template that declares itself an inbox, currently stream and kanban. Your plan can also limit which template a radar may be switched to, and a radar that holds boundaries, contracts or amendments cannot leave the Architecture template until they are deleted. Shortening archiveAfterDays takes finished blips off the board for everyone the radar is shared with.

create_smart_radar

Creates a smart radar: a saved tag search over every radar you can read. It holds no blips of its own. Use it for "one place to see all my #bug blips".

• Scope: radars:write. Writes.
• Required: name, and a filter. Give either filter or the flat arguments below, not both. Mixing them is refused.
• Optional:
  • filter: an object with tags (1 to 24 tags, each up to 48 characters), and optionally match (any, the default, or all), states, kinds, radarIds (up to 64) and q (up to 200 characters).
  • Flat form: tags, match, states, kinds, radarIds and query.
  • tagline, description, accent, glyph.
  • The schema also lists the other create_radar fields, but a smart radar ignores theme, commentsEnabled, reactionsEnabled and archiveAfterDays. A topicId is refused, and so is a Helpdesk template.
• Returns: id, name, filter, url and a note.

A smart radar cannot be captured into, published, filed in a topic, or given a webhook or feed. Read it with read_radar. Like create_radar, it can be refused by your plan's radar allowance.

{ "name": "All bugs", "filter": { "tags": ["bug"], "states": ["inbox", "active"] } }

delete_radar

Permanently deletes a radar and every blip in it. Confirm with the person first.

• Scope: radars:manage, and you must be the owner. Writes, and cannot be undone. The drop box cannot be deleted.
• Required: radarId (string), confirmName (the radar's exact name). If the name does not match, nothing is deleted.
• Returns: { "deleted": "<radarId>" }.

Templates, lanes and look

describe_templates

Returns the rulebook for templates and custom lanes: every template, what it does with its blips, the lanes it ships with, and exactly what a custom lane set must satisfy. Read it before set_radar_lanes.

• Scope: no scope is checked beyond a valid connection, so it works with radars:read. Read-only.
• Arguments: none.

set_radar_lanes

Replaces a radar's lane vocabulary with your own: the columns of a board or the stages of a queue. A template decides behaviour (layout, reading order). A lane set is only vocabulary.

• Scope: radars:manage, and you must be the owner. Writes.
• Required: radarId (string), lanes: an array of 2 to 8 lanes in reading order, or null to restore the template's own lanes.
• Each lane has:
  • id: lowercase letters, digits and hyphens, up to 24 characters. It is stored on every blip filed there.
  • label: what people read, up to 24 characters.
  • state: the triage state a blip takes when it lands in the lane.
  • terminal (optional boolean): work that reaches this lane is over.
• Optional: defaultStatus (string): the lane new blips land in. Defaults to the first.
• Returns: the radar with its lanes and whether they are custom.

Changing a label is free. Changing an id makes a different lane. A lane set that would strand blips already in a dropped lane is refused, and the refusal says how many blips are in which lane. A Decision log must keep a lane with the id superseded, and at least one lane must not be terminal. Only templates that already have lanes accept a custom set. A Stream, a Microblog and an Architecture radar do not. This tool cannot send the client status that every Helpdesk lane needs, and neither can the Edit lanes dialog in the app, so a Helpdesk lane set cannot be saved. Treat the Helpdesk lanes as fixed. See Templates and lanes.

{
  "radarId": "5b2c7e2e-1f0a-4a55-9a53-0d1f6f3b8a10",
  "lanes": [
    { "id": "lead", "label": "Lead", "state": "inbox" },
    { "id": "proposal", "label": "Proposal", "state": "active" },
    { "id": "won", "label": "Won", "state": "done", "terminal": true }
  ]
}

set_radar_theme

Changes how a radar's page looks, from a closed list of choices. Any axis you do not name stays as it is. There is no CSS, colour, image or font argument, and keys such as css, style, stylesheet, backgroundImage and html are refused by name.

• Scope: radars:manage, and you must be the owner. Writes, and idempotent.
• Required: radarId (string).
• Optional:
  • preset: one of plain, paper, press, noir, studio, terminal, blueprint, geocities, arcade, garden. plain puts the radar back to the default look.
  • Individual axes, each one of the values listed in the tool's schema: surface (Paper), pattern (Pattern), bodyFont (Reading face), chromeFont (Instrument face), corners (Corners), rule (Between posts), density (Spacing), cursor (Pointer), headline (Headline).
• Returns: id, name, theme.

Only some templates can be themed. A Kanban board and a Helpdesk cannot, and the refusal says so. Theming never changes visibility. To publish a radar use set_radar_visibility on topics and sharing.

{ "radarId": "5b2c7e2e-1f0a-4a55-9a53-0d1f6f3b8a10", "preset": "press", "density": "roomy" }

Architecture radars

An Architecture radar holds a charter and the decisions (ADRs) that amend it, plus the boundaries and contracts of the system. Use read_architecture, not read_radar, on one. These six tools refuse any radar that is not an Architecture radar.

read_architecture

Returns the charter and its ADR index in one call, with boundaries and contracts and which ADRs amend each. Element and ADR bodies are not included: use get_blip on one id.

• Scope: radars:read. Read-only.
• Required: radarId (UUID).
• Optional:
  • view: amended (default, accepted replacements are in the text), written (the original) or source (amendment markers kept).
  • pages (up to 50 page UUIDs, or a comma-separated string): read only these pages.
  • outline (boolean): headings only.
  • boundary (UUID): narrow the answer to one boundary, its seams, counterparties and the ADRs that amend them.
• Returns: compact JSON with radar, charter, adrs, boundaries and contracts.

propose_adr

Proposes an amendment to the charter. Each anchor quotes one line of charter text exactly and gives its replacement. The ADR stays Proposed until decide_adr.

• Scope: radars:write. Writes.
• Required: radarId (UUID), title (up to 300), rationale (1 to 20,000 characters).
• Optional:
  • anchors (0 to 10): each has quote (1 to 400 characters, plain text with no square brackets, pipe, backtick or line break), with (the one-line replacement, up to 600), and optionally pageId, occurrence (0-based) and seen (how many matches the reader saw).
  • supersedes (UUID): an accepted ADR on the same radar that this one replaces. The old one is untouched until the new one is accepted.
  • amends (up to 10 UUIDs): boundaries or contracts this ADR changes.
• Returns: the ADR and its anchors.

A quote must match exactly once. When it recurs, pass pageId, or pageId with occurrence and seen. Refusals are named: quote_not_found, quote_moved, quote_ambiguous, quote_overlaps, quote_in_amendment, page_full, not_an_element.

decide_adr

Accepts or rejects a proposed ADR, or repeals an accepted one. Accepting an ADR that supersedes another repeals that one.

• Scope: radars:write. Writes.
• Required: adrId (UUID), decision (accept, reject or repeal).
• Returns: the ADR and the ids it filed.

Other lane moves are refused with lane_move_refused, including through update_blip.

upsert_boundary

Creates or changes a boundary: a part of the application, or an external system, and what it owns. It matches by id, otherwise by title ignoring case. Fields you leave out are kept.

• Scope: radars:write. Writes.
• Required: radarId (UUID), title (up to 300).
• Optional: id (UUID), owns (up to 100 items, each up to 200 characters), body (up to 100,000), external (boolean, for an outside system).
• Returns: the boundary and whether it was created. Refusals: not_a_boundary, title_taken.

upsert_contract

Creates or changes a contract: the seam between two boundaries. At least one side must be inside the application. Both sides are replaced on each call.

• Scope: radars:write. Writes.
• Required: radarId (UUID), title (up to 300), a and b (boundary UUIDs).
• Optional: id (UUID), version (up to 32 characters), body (up to 100,000).
• Returns: the contract and whether it was created. Refusals: same_boundary, outside_seam, not_a_boundary, not_an_element, title_taken.

trace

Returns everything touching one boundary, contract or ADR. For a boundary: what it owns, its seams and the ADRs that amend it. For a contract: both sides and its ADRs. For an ADR: its anchors, what it amends and what it supersedes.

• Scope: radars:read. Read-only.
• Required: id (UUID).

A charter page is refused with not_traceable. Deleting a boundary or contract is delete_blip, and is refused while seams or amendments still depend on it.

Next

• MCP reference overview
• MCP tools: topics, sharing and publishing
• Templates and lanes
• Public radars