Skip to main content
Glama

List assignment milestones

list_assignment_milestones
Read-only

Break a large assignment into dated milestones from start date to due date, using default research, outline, draft, revise, and proofread steps or custom steps.

Instructions

List dated milestones that split a big assignment from a start date to the due date, with default steps for research, outline, draft, revise and proofread. Dates can be plain text, like Dec 12 or in 3 weeks. Example prompt: "Break my 6 hour essay due 2026-11-20 into milestones."

Input Schema

NameRequiredDescriptionDefault
stepsNoCustom steps with relative sizes. Defaults to research, outline, draft, revise, proofread.
titleYesAssignment name.
due_dateYesDue date. Use 2026-12-12, or plain text like Dec 12, next Friday or in 3 weeks.
start_dateNoDefaults to today. Use 2026-12-12, or plain text like Dec 12, next Friday or in 3 weeks.
estimated_hoursYesEstimated total hours.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context beyond that: default steps, flexible plain-text date parsing, and that a start date defaults to today, though it says nothing about the shape of the returned milestones.

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 core capability is front-loaded in the first clause, and the default steps and date-format note follow logically. The example prompt is a useful illustration rather than filler, keeping the description tight overall.

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

Completeness3/5

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

With no output schema, the description should clarify what the milestones look like (names plus computed dates, one per step). It implies this but never states the return shape, leaving a meaningful gap for a tool whose whole purpose is producing a dated list.

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 (title, due_date, start_date, estimated_hours, steps) is already documented with formats and defaults. The description only restates the default steps and plain-text date flexibility, adding no syntax the schema doesn't already carry.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource (dated milestones splitting an assignment from start date to due date) and explains the default step breakdown, so the operation is concrete. It does not, however, distinguish this tool from the sibling 'assignment_milestones', and the verb 'List' understates that it generates/computes milestones rather than retrieving stored ones.

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?

An example prompt ('Break my 6 hour essay due 2026-11-20 into milestones') gives a clear usage context and the description notes that steps default to research/outline/draft/revise/proofread. It lacks explicit when-not conditions or a named alternative among the many sibling planning tools.

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