Zovo Timeline

Generate timeline

generate_timeline

Read-onlyIdempotent

Use this when the user wants a timeline chart, a chronology or a history graphic from dated events, with a file to download. Places events to scale by day count (or at even gaps), stacks labels in rows so they do not overlap, draws spans as bars and eras as bands, and returns SVG, PDF (Letter or A4) and CSV links. Reads YYYY, YYYY-MM, YYYY-MM-DD, month names and BC years. Up to 200 events and 20 eras. Does not convert Julian calendar dates, does not research dates, and refuses ambiguous slashed dates unless date_order is given. Do not use for project schedules with task dependencies.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "events": "<events>"
    },
    "name": "generate_timeline"
  }
}

Input Schema

Name	Required	Description
`scale`	No	to_scale (default) places each date by its day count, so gaps are true to time. even puts events at equal gaps in date order.
`title`	No	Chart title, e.g. "Space race".
`events`	Yes	1 to 200 events in any order, e.g. [{"date":"1957-10-04","label":"Sputnik 1"},{"date":"1969-07-20","label":"Moon landing"}].
`periods`	No	Optional eras drawn as shaded bands along the axis (up to 20), e.g. [{"label":"Cold War","start":"1947","end":"1991"}].
`page_size`	No	PDF paper size: letter (default) or a4.
`date_order`	No	Only for slashed dates such as 03/04/2025: month_first reads March 4, day_first reads 3 April. Without it such dates are refused as ambiguous.
`orientation`	No	horizontal (default, landscape PDF) or vertical (time runs down the page, portrait PDF). Vertical suits long lists.

Output Schema

Name	Required	Description	Default
`scale`	Yes
`title`	Yes
`events`	Yes
`warnings`	Yes
`downloads`	Yes
`last_date`	Yes
`page_size`	Yes
`pdf_pages`	Yes
`span_days`	Yes
`categories`	Yes
`first_date`	Yes
`label_rows`	Yes
`event_count`	Yes
`orientation`	Yes
`period_count`	Yes
`label_overlaps`	Yes
`leader_crossings`	Yes
`events_preview_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already establish read-only, non-destructive, idempotent, closed-world behavior. Beyond that, the description discloses important behavioral details: output formats, date parsing rules, limits of 200 events and 20 eras, ambiguous slashed-date refusal unless date_order is supplied, and no Julian calendar conversion or date research. These are operational constraints an agent needs before calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary use case, then moves through output behavior, date handling, limits, unsupported cases, and exclusions. Despite covering many details, every sentence adds useful context for a relatively complex chart-generation tool. There is no filler or redundant padding.

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?

An output schema exists, so the description does not need to detail return value structure, and it still usefully names SVG, PDF, and CSV outputs. With 7 parameters, 4 enums, and nested event objects, the description covers the important limits, date parsing rules, and exclusions. An agent has enough information to decide when and how to call the tool correctly.

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 the input schema already documents all seven parameters, including enums, date formats, and limits. The description reinforces key semantics such as accepted date formats and the 200-event and 20-era limits, but mostly restates what the schema already provides. The baseline of 3 is appropriate when the schema carries the parameter documentation.

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 states a specific verb and resource: generating timeline charts, chronologies, or history graphics from dated events. It clearly distinguishes the output and scope, including downloadable SVG, PDF, and CSV files. No sibling tools exist, so no further differentiation is needed.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance with 'Use this when the user wants a timeline chart, a chronology or a history graphic from dated events.' It also names a clear exclusion: project schedules with task dependencies. It additionally explains date ambiguity handling and refuses unsupported cases such as Julian calendar conversion or date research.

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

All Zovo Timeline tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?