Skip to main content
Glama

Create timeline draft

create_timeline

Turn a structured brief into a timeline draft by defining acts, axes, filters, and relations, producing interactive filterable timelines.

Instructions

Create a timeline draft from the build brief (Flow 2 §B–§I). brief: {title, subject?, timeline_id?, columns?: 3|5, node_noun?, period_noun?, accent?, entity_axis_label?, entity_axis_singular?, acts: [{label, short?, color?}] (2-7), mode?: 'linear'|'outline' — 'linear' (default) flows nodes through the bands in sequence; 'outline' makes them concepts that CONTAIN one another, one family per band, structure carried by node parent, §D-Outline, axes?: [{label, singular, hide_nav?: bool, values:[{id,name,...}]}] (≤2; hide_nav drops the axis from the nav bar, drawer and legend but KEEPS its card chips and detail pages, and labels those chips with the value name — right for a large uncapped axis such as a course's cases), filters?: [{id, label, source: 'entity'|'axis1'|'axis2'|'acts'|'coverage'|'depth'|'custom', values?: [{id,name}] (custom source only, 2-10), replace_nav?: bool}] (≤2; 'coverage' = auto Solid/Thin from node density; 'depth' = auto Level 1/2/3+ from the containment structure), relations?: [{key,label?,color?}] ('spine' = neutral main thread; other relations get distinct palette colors when color is omitted, so their lines stay tellable apart from the spine. Each label is user-visible: it appears in the on-page line key (desktop nav + mobile drawer) next to a swatch of its line color, for every relation a connection actually uses — so keep labels short, e.g. 'Overrules'), chip_filters?: bool (default true: the Filter toggle gets a section for every kind of sub-chip cards carry — entities, each axis — and picking chips dims the cards without them), line_filter?: bool (a "Lines" section in the Filter toggle that isolates one relation's lines; default true, set false for a story whose lines just follow characters), overview_html?, owner_name?, owner_email?}. Filters add canvas filter chips that dim non-matching nodes (they never navigate). Derived sources (entity/axis1/axis2/acts) mirror that dimension's values and assign nodes automatically; 'custom' declares its own values and each node picks one via its filters map in add_nodes. replace_nav makes a mirrored axis1/axis2 filter-only — nav chips, drawer section, legend dot, and per-node card chips are all suppressed (no reachable detail pages) — recommended when that axis has no authored detail sections. On source 'entity' it only swaps the nav chips. period_noun names the horizontal bands on the homepage tile ("Unit", "Act", "Era", …); omit it and the label is derived from the project kind (studying→Unit, writing→Act, research→Phase, default Unit). Entities are set separately via set_entities. Returns validation warnings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYes
project_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.5/5.0
Behavior5/5

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

Even with annotations present, the description adds substantial behavioral context: filters dim nodes and never navigate, replace_nav suppresses nav/drawer/legend/detail-page surfaces, hide_nav keeps card chips and detail pages, and mode changes how containment works. It also discloses that the tool returns validation warnings. No contradiction with the readOnlyHint/destructiveHint annotations is present.

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 most of the length is earned because the schema provides no property descriptions for the complex `brief` object. It is front-loaded with the primary action and uses structured, code-like line breaks to keep dense information scannable. It is heavier than a minimal description, but the complexity justifies the size.

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

Completeness5/5

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

Given an input schema with 0% description coverage and no output schema, the description is remarkably complete: it explains the main input object, defaults, constraints, sibling separation for entities, and even the return behavior ('Returns validation warnings'). An agent has enough information to understand what the tool does and how to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for parameters. It thoroughly documents the nested `brief` object: fields, defaults, constraints (e.g., acts 2-7, axes ≤2, filters ≤2), enums, and behaviors for each option. The only top-level parameter not described is `project_id`, but its meaning is clear from the name and schema.

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 and resource: 'Create a timeline draft from the build brief.' It also clarifies its draft nature and references a concrete source (Flow 2 §B–§I), which distinguishes it from sibling tools like build_timeline or publish_timeline.

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 description implies when to use the tool: when you have a build brief and need a timeline draft. It also notes that entities are set separately via set_entities, which is a useful sibling relationship. However, it does not explicitly contrast this tool with build_timeline or other alternatives, so the usage guidance remains implied rather than explicit.

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