Rhylthyme MCP Server

Analyze schedule timing

analyze_schedule

Read-onlyIdempotent

Analyze program schedules: compute each step’s start, end, duration, critical path, resource conflicts, and slack. Work backward from finishAt or predict durations from run history.

Instructions

Put a program on the clock: each step's start and end, total length, the critical path and what gates it, resource conflicts, slack per track. Pass finishAt to answer 'when do I start X so everything is ready at 6pm?'. Pure computation. With history (run records) or program_id it also predicts durations from recorded runs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`token`	No	Access token from the login tool. Omit when the account is connected.
`history`	No	Recorded runs of this program (from load_run); adds predicted durations.
`program`	Yes	Program JSON; shape under validate_program.
`startAt`	No	ISO 8601 start datetime. Ignored with finishAt.
`finishAt`	No	ISO 8601 datetime everything must END at, e.g. '2026-11-26T18:00:00-05:00'. Start times are worked backwards from it.
`program_id`	No	Saved program UUID: loads the user's own recorded runs as the history.
`useDurations`	No	planned (default): analyse the program as authored. predicted: as the history says it will run.	planned
`predictionContext`	No	Optional: environmentId, userTags (variance factors), userId, programVersion, minIdentical, minModel, corrThreshold, verdicts. See rhylthyme://guide/tools.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes
`steps`	Yes
`tracks`	Yes
`inFlight`	No
`makespan`	Yes
`actorPeak`	Yes
`programId`	Yes
`wallClock`	Yes
`validation`	No
`criticalPath`	Yes
`durationsUsed`	No
`makespanSeconds`	Yes
`plannedMakespan`	No
`predictedMakespan`	No
`resourceConflicts`	Yes
`bindingConstraints`	No
`predictedCriticalPath`	No
`plannedMakespanSeconds`	No
`predictedMakespanSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 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 'Pure computation' reinforces that this mutates nothing. It also discloses the conditional behavior that predictions only occur when history or program_id is supplied. It adds no auth or rate-limit context, but the annotation burden is light here.

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?

Front-loads the core output list, then adds the finishAt scenario and the prediction condition. Dense but every sentence carries information; the colon-list style is efficient rather than padded.

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?

An output schema exists so return values need not be explained, and the schema plus the rhylthyme://guide/tools pointer cover the nested predictionContext. For an 8-parameter tool with only one required arg, the description supplies enough to call it correctly.

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

Parameters4/5

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

Schema coverage is 100% so the baseline is 3, but the description genuinely adds meaning: finishAt is framed as the reverse-scheduling input and it clarifies that program_id pulls the user's own recorded runs as history. That goes beyond restating 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?

States a specific verb (analyze) and enumerates the concrete outputs: per-step start/end, total length, critical path and its gates, resource conflicts, slack per track. That output list clearly separates it from visualize_schedule and preview_timeline, which render rather than compute timing.

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?

Gives a concrete usage scenario for finishAt ('when do I start X so everything is ready at 6pm?') and states that history/program_id unlocks predicted durations. It never names an alternative sibling or an explicit when-not, so it falls short of a 5.

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