Zovo Weekly Schedule Maker

Generate weekly schedule

generate_weekly_schedule

Read-onlyIdempotent

Use this when the user wants a weekly schedule maker, class schedule maker, college schedule builder, time blocking template or work schedule template: a printable week grid PDF from a list of recurring blocks (title, days, start-end time, optional location and colour), with each overlap listed (day and minutes overlapped), hours per title and per day, free gaps of 30+ minutes, and an .ics calendar file with one weekly repeating event per block (term start to term end, time zone aware, skip dates). Accepts sloppy text such as "Calc MWF 9-10:15am" or "Gym Tuesdays and Thursdays 7-8am". Does not handle alternate-week or one-off events, does not read files or screenshots, and does not plan shift rotations between people.

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": {
      "blocks": "<blocks>"
    },
    "name": "generate_weekly_schedule"
  }
}

Input Schema

Name	Required	Description
`clock`	No	Time format: 12h (default, 9:00 AM) or 24h (09:00), e.g. 24h. Default follows the input style.
`paper`	No	Paper size for the PDF: letter (default in the US and Canada) or A4, e.g. A4.
`title`	No	Heading on the printout, e.g. Fall 2026 classes. Default: Weekly schedule.
`blocks`	Yes	The weekly blocks: classes, shifts, workouts, focus time. Either one line per block as text, e.g. "Calculus MWF 9-10:15am Room 204\nBiology Lab Tue 2-5pm\nGym Tuesdays and Thursdays 7-8am", or a list of objects like {"title":"Calculus","days":"MWF","start":"9:00","end":"10:15am","location":"Room 204","color":"blue"}. Days accept MWF, M/W/F, TTh, TR, Tue Thu, Tuesdays and Thursdays, weekdays, Mon-Fri, weekends, daily. Times accept 9-10:15am, 9am to 10.15, 14:00-15:30, noon-1pm, 10pm-6am (overnight).
`day_end`	No	Optional end of the day window used for free time, e.g. 6pm. Default: the latest block end.
`term_end`	No	For the calendar file: last day of the term, e.g. 2026-12-11. Each block repeats weekly until this day. Default: repeats with no end date.
`day_start`	No	Optional start of the day window used for free time, e.g. 8am. Default: the earliest block start.
`time_zone`	No	For the calendar file: the time zone or city of the schedule, e.g. America/New_York or Chicago. Default: floating local times (no zone).
`days_shown`	No	Which days get a column: auto (default: Mon-Fri, plus the weekend when a block falls on it), weekdays, or all, e.g. all.
`skip_dates`	No	Dates with no sessions (holidays, breaks), left out of the calendar file, e.g. "Nov 25 - Nov 27, Sep 7" or ["2026-11-26","2026-11-27"].
`term_start`	No	For the calendar file: first day of the term or schedule, e.g. 2026-08-24 or Aug 24 2026. Default: today.
`week_start`	No	First day of the week in the grid: Monday (default) or Sunday, e.g. Sunday.
`orientation`	No	Page orientation: landscape (default) or portrait, e.g. portrait.

Output Schema

Name	Required	Description	Default
`paper`	Yes
`title`	Yes
`blocks`	Yes
`summary`	Yes
`calendar`	Yes
`warnings`	Yes
`conflicts`	Yes
`downloads`	Yes
`free_time`	Yes
`days_shown`	Yes
`week_start`	Yes
`assumptions`	Yes
`hours_shown`	Yes
`orientation`	Yes
`totals_by_day`	Yes
`totals_by_title`	Yes
`total_busy_hours`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavior beyond that: the concrete deliverables (overlap minutes per day, hours per title and per day, gaps of 30+ minutes, one weekly repeating event per block bounded by term start/end), plus tolerance for messy input. It stops short of stating limits such as block caps, failure modes, or what happens when a block cannot be parsed.

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

Conciseness3/5

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

The content is front-loaded and the negative constraints land at the end where they belong, but the first sentence is a single ~120-word run-on seeded with near-duplicate search phrases ("weekly schedule maker, class schedule maker, college schedule builder..."). Those synonyms add noise rather than selection value for an agent, and the dense clause chaining makes the core purpose harder to extract than it needs to be.

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?

For a 13-parameter tool with an output schema and full annotations, the description covers the remaining burden: what is generated, which inputs are required, accepted input formats, and explicit out-of-scope cases. An agent has enough to decide to call it and to construct a valid `blocks` payload without further inference.

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 schema already documents every parameter with examples and defaults; that sets the baseline at 3. The description adds only marginal meaning on top, mainly that `blocks` accepts free-form sloppy text like "Calc MWF 9-10:15am" and that term/skip parameters feed the .ics file specifically — useful framing, but the per-parameter details are all in the 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 names a concrete verb and resource — build a printable week-grid PDF plus an .ics calendar file from a list of recurring blocks — and enumerates the artifacts produced (overlap list, hours per title/day, free gaps, repeating events). Despite the keyword-stuffed opening, an agent can tell exactly what comes out of this tool, and no sibling tools exist to disambiguate against.

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 opens with an explicit trigger condition ("Use this when the user wants a weekly schedule maker...") and closes with hard exclusions: no alternate-week or one-off events, no reading files or screenshots, no shift-rotation planning between people. That is both a when-to-use and a when-not-to-use statement, which is the strongest form of routing guidance.

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

All Zovo Weekly Schedule Maker 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?