Skip to main content
Glama
Cafelatte1

FronyBoard

create_task

Add a task as an issue- or branch-sized unit of work with todo status; assigns a project-global ID and opens the current quarter when needed.

Instructions

Use it when you start a piece of work or the user asks to add one (add a task, new to-do).

Create a task — one issue/branch-sized unit of work — with status todo.

The id is assigned from the project-global sequence and never reused. `period` is
YYYYQn: the current quarter (in the server's time zone) opens by itself if it is not
open yet, and the answer then carries `opened`; any other quarter must already be open
(open_period). Nothing else — no overview, no milestone — has to exist first.

`title` is a short English imperative ("Add multi-select status filter") — it is what
every reader sees, so it has to say the whole thing.

`content` is optional: one line, at most 300 characters, English. It answers **why this
task exists** — the pressure that made it necessary, or the scope you deliberately left
out. It is written now, before the work, so it cannot describe the approach or the
result: the approach you choose, and why, goes in the commit; what proves the work done
is `check`, which transition_task takes when you finish. Do not restate the title here:
a note that only rephrases it tells the next agent nothing. Line breaks are folded into
spaces; a longer text is rejected, not cut.

`tags` are free-form labels ("frontend", "bug", "infra"): up to 8 per task, 24
characters each, no commas. Reuse the wording already in use on the project
(list_tasks shows it) instead of coining a new spelling for the same thing.

`depends_on` lists the task ids this one builds on — the *earlier* work whose result it
needs, or the task that handed it this scope. Full ids, other projects allowed. It
points backwards only: there is no forward list, so a task never has to be updated
because a later one appeared. It is a pointer, not a lock — nothing is blocked, and
`list_tasks` / `get_status` merely flag the entries not yet done as `waiting_on`.

Input Schema

NameRequiredDescriptionDefault
keyYes
tagsNo
titleYes
periodYes
contentNo
depends_onNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses important behavior: ids are project-global and never reused, the current quarter opens automatically and returns `opened`, other quarters must already be open, and depends_on is a pointer rather than a lock. It does not describe permissions/auth requirements or the full response shape, so it is strong but not exhaustive.

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 description is long but front-loads purpose and usage, then organizes parameter semantics into clear paragraphs. Most sentences earn their place by adding constraints or routing guidance, though some of the content/title prose is more verbose than strictly necessary.

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?

Given no annotations, no output schema, and 0% schema coverage, the description is largely complete: it explains creation scope, side effects, period handling, and most parameter semantics. The missing `key` semantics and incomplete return-value detail keep it from being fully complete.

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 0%, so the description must compensate, and it does richly for period, title, content, tags, and depends_on, including syntax and constraints. However, the required `key` parameter is never explained anywhere, leaving a clear gap for one of the three required inputs.

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?

The description gives a specific verb and resource ("Create a task"), scopes the unit of work ("one issue/branch-sized unit of work") and status ("todo"), and distinguishes creation from later lifecycle steps by referencing transition_task. An agent can tell this is the creation tool without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It opens with a clear trigger ("when you start a piece of work or the user asks to add one") and routes related actions: finishing uses transition_task, other quarters use open_period, and list_tasks/get_status expose tags and waiting_on. It does not explicitly say when to use update_task instead for existing tasks, so it stops short of full when/when-not/alternatives guidance.

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