Skip to main content
Glama

Set track

set_track
Destructive

Declare a track on a project, or edit the one that already has this tag. The tag is the LABEL issues carry to join it ('cherry-orchard'), so it cannot contain a space — labels are stored space-separated. The name is what a reader sees ('The Cherry Orchard'); leave it out and the tag speaks for itself. Declaring a track writes nothing to any issue: the ones already carrying the label are in it at once. Needs permission to write in the project.

Input Schema

NameRequiredDescriptionDefault
tagYesThe label that puts an issue in this track, e.g. 'cherry-orchard'. No spaces. An existing track with this tag is edited rather than duplicated; matched exactly, so 'Hamlet' and 'hamlet' are two tags, as they are two labels.
iconNoOne or two emoji shown BESIDE the name, never instead of it. Leave it out to keep what is there; send an empty string to take it off. Anything that is not an emoji is refused rather than ignored.
nameNoWhat a reader sees, e.g. 'The Cherry Orchard'. Leave it out to keep what is there; send an empty string to drop it and let the tag speak.
newTagNoRename the tag to this. The label on existing issues is NOT rewritten, so work in the old tag leaves the track — rename only when the issues are being relabelled too.
archivedNotrue takes the track off the row above the board WITHOUT undeclaring it — a play that has been staged: its name, icon, place and tag are kept, its issues stay in it (they do not become 'outside every track'), and links to it keep working. false puts it back in the row. Leave it out to keep what is there. Prefer this to remove_track for a track that is finished.
positionNoWhere it sits in the row above the board, counting from 1. Leave it out and a new track goes last, an existing one stays where it is.
projectKeyYesProject key, e.g. 'TH'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true) the description discloses that declaring writes nothing to issues and that existing label-carrying issues join immediately, plus an explicit write-permission requirement. It still does not explain where the declared destructiveness actually lies – the destructive edge cases (newTag orphaning issues, archive semantics) are only in parameter text.

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?

About 90 words, front-loaded with the verb and upsert rule, then vocabulary, side-effect, and permission notes in a sensible order. Slight redundancy with the tag/name schema descriptions keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter mutation with full schema coverage and annotations, the description supplies the missing pieces an agent needs: upsert behavior, the no-issue-writes nuance, and the permission prerequisite. Return behavior and the destructive specifics are left implicit, but no output schema exists to rely on either.

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 is already documented in detail. The description adds a usable mental model (tag = space-free label, name = reader-facing label, name optional) but restates rather than extends the schema. 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?

"Declare a track on a project, or edit the one that already has this tag" states a specific verb, resource, and upsert semantics in one line. An agent can tell this apart from list_tracks and remove_track 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The create-vs-edit condition is stated explicitly, which is the main routing decision, and the closing sentence names the permission precondition. But the description never points at siblings – the strongest guidance ("Prefer this to remove_track for a track that is finished") lives in the archived parameter's schema text, not here.

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