Skip to main content
Glama

Propose a task

propose

Turn a note, message or request into a task with steps, dates and tags. File several tasks at once or split larger work into parts so each item is tracked on its own.

Instructions

Propose a task — something to do; what will be read again is a document (write_doc). Give it a title. Several read from one thread go together in tasks, each judged on its own, so a bad one does not sink the rest. A step is one line of a checklist; work that is several tasks with one end — a move, a release, a plan — goes in parts, one level deep, rather than packed into steps. A ticket's progress, its reviews, pull requests and audits are this task's page and its parts, never documents. Tisty tags it #agent by itself.

Input Schema

NameRequiredDescriptionDefault
dateNoThe day it is meant to be done (2026-08-31)
listNoThe existing list it belongs in, by name; `lists` says which. Expected: left out, it lands in the inbox, and that needs a reason
tagsNoThe subjects it is about, one word each in the person's plain words; capitals and accents decide nothing. Six is already a lot, and a word that merely appears in the title is no subject. Reuse what `tags` lists when it means the same
againNoOnly when the person asks you in this conversation to do again what was already proposed from this source and closed since: files a new task despite the source being known. Say in the description how the last one ended. Never for a source whose task is still open
partsNoThe tasks the work is made of, each shaped like a single one with its own steps; the task around them is finished when they are. One level, at most 32 here — add more later with `part_of`
stepsNoA checklist, each step at most 100 characters; what needs more is a part
tasksNoSeveral at once, each shaped like a single one. Left out when proposing one
titleNoWhat has to be done, in a line
remindNoWhen to ring, each like 2026-08-30T20:00. Only for what happens once at a set time and cannot be caught up on — an appointment, a flight — set the evening before; never for work any day will do, nor for what repeats
sourceNoWhere you read it — a message id, a thread link
part_ofNoThe id of a task you may work on — one an agent filed, or one the person opened to agents — that this one is a part of
deadlineNoThe day it actually runs out (2026-08-31)
priorityNoOnly if someone said so. Leave it out otherwise
descriptionNoWhat you read, in the Tisty language

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 burden and discloses real behavior: it auto-tags every task #agent, batching in `tasks` isolates failures ('a bad one does not sink the rest'), `parts` is capped at one level and at most 32, and `again` creates a duplicate only under stated conditions. It does not state what is returned (the task id that `part_of` later needs) or permission/auth constraints.

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?

A single dense paragraph that front-loads the definition and then layers the structural rules (tasks, steps, parts, page, tags). Nearly every clause carries information, though the sentence combining batching with per-item failure tolerance packs two ideas into one and the prose style is idiosyncratic.

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 14-parameter creation tool with no annotations and no output schema, the description covers the conceptually hard parts (task vs document, steps vs parts vs tasks, when duplication is allowed) that the schema alone would not convey. The remaining gap is that it never says a task id comes back, which matters because `part_of` consumes one.

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%, so all 14 parameters including the tricky `again`, `parts`, `steps`, and `remind` distinctions are already documented in the schema. The description reinforces a few of them (`title`, steps-vs-parts, batching) but adds no syntax or format detail beyond what the schema provides, so 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?

The description opens with a specific verb+resource and immediately defines it against the nearest sibling: a proposal of 'something to do', while 'what will be read again is a document (`write_doc`)'. An agent can tell apart propose vs write_doc vs note without opening either 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 gives concrete routing rules: several reads from one thread go in `tasks` (each judged independently), a checklist line is a step, multi-task work with one end goes in `parts` one level deep, and a ticket's reviews/PRs/audits belong to its page and parts rather than documents. It stops short of naming siblings like `plan` or `remind` as alternatives, so it is clear context rather than explicit when/when-not exclusions.

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