Rhylthyme MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_programA | Check a program before publishing or saving it: ids, dangling or cyclic triggers, steps overlapping in a track, tasks with no resourceConstraint, durations, replicates/instances misuse. Every finding has a code, a message and a suggested fix. Pure computation. |
| analyze_scheduleA | 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 |
| visualize_scheduleA | Publish a program as a live, shareable timeline (a public share link) and return its URL, with an ASCII Gantt and an itinerary. For a schedule the user wants to follow or share ('plan this so it all finishes at 6', 'when do I start each thing'). Validates first and refuses an invalid program with fix hints. |
| import_from_sourceA | Import a recipe, protocol or run of show into a program. source: spoonacular, themealdb (recipes); protocolsio, opentrons, benchling (lab); cooklang (.cook URL); ontime (run of show). action: search (no account needed), import (query = URL or id), random. import, random and benchling need the user's Rhylthyme account. |
| import_textA | Turn pasted text (a recipe, protocol, run sheet or training plan) into a validated multi-track program on the server, in four model turns, with a table of the source span each step came from. Capped per day. Needs the user's Rhylthyme account. |
| create_environmentB | Describe a workspace's equipment limits (one oven, two centrifuges, one stage) as resourceConstraints to copy into a program, so steps that share equipment are scheduled around each other. |
| loginA | For apps that cannot connect the Rhylthyme account directly: returns a sign-in URL, then accepts the pasted token. Only the user's own saved programs, runs and imports need it; everything public works without. Tokens last about an hour. |
| list_my_programsA | List the user's saved programs. Needs the user's Rhylthyme account. |
| load_programA | Open one of the user's saved programs by id: summary plus live-timeline URL. Needs the user's Rhylthyme account. |
| list_runsA | List recorded runs of a saved program: when, how it ended, actual against planned length. For 'how long did this take last time?'. Needs the user's Rhylthyme account. |
| review_programA | A model reads an imported program against its source and reports what looks wrong: a default duration on "simmer for an hour", a step the importer dropped, steps chained that could overlap, a total that disagrees with the source. Changes nothing; returns findings to show the user. Needs the user's Rhylthyme account. |
| load_runA | Open one recorded run: planned against actual timing per step, what ended each step, pauses. Shows where a plan drifts. Needs the user's Rhylthyme account. |
| calibrate_programA | Propose durations for a saved program from its recorded runs: median as the default, P10 to P90 as the range, at least as wide as the author's, with the evidence per step and the effect on total length. Saves nothing; with |
| list_public_runsA | List anonymous runs other people contributed for one exact program version: actual against planned length, and their conditions. For 'how long does this really take?'. No account needed. Takes |
| search_public_recipesA | Search the public catalog of recipes, lab protocols, event templates and workouts by name or keyword. Returns ids, names, descriptions and URLs; no account needed. |
| load_public_recipeA | Open a public catalog entry by id: summary plus live-timeline URL. |
| save_programA | Save a program to the user's account ('save this for later'); the same programId updates it. Needs the user's Rhylthyme account. |
| preview_timelineA | Return a static Gantt image of a program with a caption, for 'show me a preview' or 'a picture of the timeline'. The image is served from a public share link. Planned versus actual: with |
| get_renderer_sourceA | Return the open-source timeline renderer's JavaScript (Apache-2.0, about 90 KB, no dependencies) for an HTML page or artifact that cannot load external scripts; it defines Rhylthyme.renderTimeline(container, program). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan_schedule | Turn a goal ("Thanksgiving dinner for 8 with one oven, ready at 6pm"), or a source text, into a validated Rhylthyme program and a live timeline URL. Four turns: read the source back, confirm the program model, extract the steps with the words each came from, then assign tracks and triggers and run validate → analyze → visualize. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| program-schema | The full JSON Schema for Rhylthyme program files: tracks, steps, durations, start triggers (incl. compound and choice-gated), replicates, resource constraints, metadata. |
| authoring-guide | One-page cheat-sheet: program shape, the rules validate_program enforces, every trigger type, how to make tracks finish together, repeated work (replicates, per-instance `instances` chains, barriers and `maxInFlight`), choice branching, and the recommended tool workflow. |
| tool-guide | The long form of every tool description: when to use it, what it returns, and the arguments the tool list only names (analyze_schedule's predictionContext, calibrate_program's options). |
| extraction-guide | The four-turn structure the plan_schedule prompt sends — read-back, model check, step extraction with source spans, then tracks and triggers — as prose with each turn's expected output shape, for hosts that cannot run a multi-message prompt. |
| example-breakfast_schedule | Coordinated breakfast preparation schedule for scrambled eggs, bacon, and toast — complete, valid program (3 tracks, environment kitchen). |
| example-lab_experiment | Simple laboratory experiment workflow for protein analysis — complete, valid program (2 tracks, environment laboratory). |
| example-stir_fry_with_choice | A veggie stir fry where you choose your protein — chicken, tofu, or shrimp — complete, valid program (4 tracks, environment kitchen). |
| example-hiit_cardio_workout | High-intensity interval training with alternating cardio exercises — 4 rounds of 4 minutes each — complete, valid program (1 tracks, environment fitness). |
| example-corporate_presentation | 45-minute keynote presentation logistics coordination: AV setup, slide testing, speaker prep, audience management, Q&A facilitation, and post-event activities f — complete, valid program (7 tracks, environment event). |
| example-cookies_three_trays | Three trays of cookies bake one after another in a single oven, onto a rack that holds two. Each tray starts cooling the moment it comes out (instances: "each") — complete, valid program (1 tracks, environment kitchen). |
TDQS
Scored across 19 tools
Most tools target distinct resources and actions, and descriptions carefully separate public vs. account-scoped variants (list_public_runs vs list_runs, load_public_recipe vs load_program). A few pairs risk confusion: validate_program vs review_program (structural checks vs model reading against source), and analyze_schedule-with-history vs calibrate_program both derive durations from recorded runs, while visualize_schedule and preview_timeline both produce timeline imagery.
Names follow a clean snake_case verb_noun pattern throughout (list_runs, load_program, validate_program, save_program, preview_timeline). The only deviation is the bare 'login', which lacks a noun but is a widely understood special case.
19 tools is on the heavy side, but the domain genuinely spans public catalog browsing, imports, validation/analysis, visualization/rendering, and run-based calibration, so most tools earn their place. It is slightly over what a single-purpose server needs but not bloated.
The program lifecycle is well covered: import (source/text), validate, analyze, save/update, load, list, review, calibrate, plus run listing/inspection and rendering. Gaps exist—no explicit delete/remove program and no tool to record a run (only list/load runs), which agents must work around.