Rhylthyme

Real-time multi-track schedules for cooking, lab protocols, events and workouts.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

    What data it sees

    Do you need an account

    No: the server works without sign-in

    Real-time multi-track schedules for cooking, lab protocols, events and workouts. Validate and share.

    How to connect

    How to connect Rhylthyme to Claude

    The server address to paste into Claude settings:

    https://mcp.rhylthyme.com/mcp

    1. Open Claude (claude.ai or the desktop app).
    2. Go to Settings → Connectors.
    3. Click Add custom connector.
    4. Paste the server address copied below into Remote MCP server URL and click Add.
    5. In a chat, click + → Connectors and switch the new connector on.

    Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

    Authorization

    After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

    How to connect Rhylthyme to ChatGPT

    The server address to paste into ChatGPT settings:

    https://mcp.rhylthyme.com/mcp

    1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
    2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
    3. Open Settings → Connectors and click Create.
    4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
    5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
    6. In a new chat open + → Apps/Connectors and enable the connector.

    OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

    Authorization

    On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

    How to connect Rhylthyme to Cursor

    The server address to paste into Cursor settings:

    https://mcp.rhylthyme.com/mcp

    Fastest: click Open in Cursor below and confirm the prompt.

    Manually:

    1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
    2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
    3. Save the file. The server appears in the MCP list; authorize it there if asked.

    Authorization

    If the service needs sign-in, an authorize button appears next to the server in the MCP list.

    Server tool list (18)

    Raw names from tools/list. Only developers need these.

    validate_programCheck a Rhylthyme program for structural and scheduling errors BEFORE visualizing or saving it: missing/duplicate ids, dangling afterStep references, dependency cycles, steps that overlap within a track, tasks with no resourceConstraint, unparseable durations, invalid choice references, and schema 0.3.0-alpha `instances`/`replicates` misuse (E_INSTANCES_ON_SINGLE, E_EACH_WITH_REPLICATES, E_EACH_COUNT_MISMATCH, E_INFLIGHT_GT_COUNT, E_INFLIGHT_NO_CHAIN). Every finding has a `code`, a `message` and a `fix` hint — apply the fixes and re-run until `valid` is true. Warnings (e.g. tracks that finish far apart, W_UNBARRIERED_CHAIN) are advisory; `info` notes (I_IMPLICIT_BARRIER: a replicated step referenced without `instances`) suggest making a barrier explicit. Pure computation: no network, no side effects, safe to call repeatedly.
    analyze_scheduleResolve a Rhylthyme program onto the clock and report what the live runner will do: every step's start/end (seconds from start and, if you pass `finishAt` or `startAt`, ISO wall-clock times), total makespan, the critical path, `bindingConstraints` (what gates each critical-path edge — an in-flight cap, a saturated task, an offset, or a plain dependency), resource conflicts tagged `kind: "maxConcurrent"` (more steps claim a task than its maxConcurrent allows) or `kind: "inFlight"` (more instances of a replicated step are between it and its barrier than `replicates.maxInFlight` allows), `inFlight` windows per replicated step, peak concurrency vs. declared actors, and per-track slack (instances get their own sub-track rows, tagged with `parentTrackId` / `instanceOf`). Use it to answer 'when do I start the potatoes so everything is ready at 6pm?' (pass finishAt), to find why a schedule is longer than expected (critical path and binding constraints — e.g. the cooling rack, not the oven), or to check equipment contention before visualizing. Pure computation; also returns validation findings so you can fix problems in the same turn. **Analysing against real history.** Pass `history` (run records from **load_run**, or from `rhylthyme runs` on disk) and every step with enough measurements gains `predicted: {seconds, low, high, basis, n}` beside its planned duration, plus top-level `predictedMakespan` and `predictedCriticalPath`. `basis` is `"identical"` (runs of the same program version, environment and variance factors — their median), `"model"` (a per-step regression on the factors that correlate) or `"none"` (no usable measurement). Simpler still: give `program_id` (a UUID from **list_my_programs**) plus `token` and the tool loads the caller's own recorded runs of that program for you. `useDurations: "predicted"` then recomputes the makespan, itinerary, critical path and conflicts from the predicted durations instead of the authored ones; the default stays `"planned"` so
    visualize_scheduleRender a multi-step parallel schedule as a live timeline (cooking, lab protocols, event run-of-show, training). **Call this for ANY schedule you produce — imported, catalog match, or built freehand.** A schedule belongs in a visualization, never in prose. The program is validated first (same checks as validate_program); invalid programs are refused with fix hints instead of being published. Returns a markdown preview (cover photo if any, equipment list, ingredient list, ASCII Gantt timeline, chronological itinerary, schedule check) and a shareable rhylthyme.com URL with the interactive view.
    import_from_sourceImport a recipe or lab protocol from an external source into a Rhylthyme program. Sources: spoonacular (recipes, preferred), themealdb (recipes, fallback), protocolsio (lab protocols), cooklang (.cook recipe URL — action must be 'import', query is the URL; GitHub blob URLs are auto-converted), opentrons (Opentrons Protocol API v2 .py — pass URL as query, or paste source via text; action must be 'import'), benchling (the user's connected library). Actions: search (no login needed), import and random (need the user's Rhylthyme token from **login**). After import, run the returned program through **visualize_schedule**. Pass `enrich: true` with action='import' to split the import into parallel tracks with cross-track triggers (one model call, capped per day; inferred steps are marked `metadata.inferred`).
    import_textTurn a block of pasted text — a recipe, a lab protocol, a run-of-show, a training plan — into a validated multi-track Rhylthyme program. Use when the user pastes the steps themselves and no structural importer fits (no URL, no supported service, a photo they transcribed, a PDF they copied out of). Runs four model turns server-side: read-back, schema check, step extraction with the exact source span each step came from, then tracks and triggers. Needs the user's Rhylthyme token from **login**; costs a model call per turn and is capped per day. Returns the program plus a step→span table, so you can show the user which words each step came from and which steps were inferred.
    create_environmentCreate a Rhylthyme environment definition with resource constraints for a workspace (lab, kitchen, bakery, etc.). Returns environment JSON; copy its resourceConstraints into the program (or reference it by environmentId) before calling **visualize_schedule**.
    loginSign in to your Rhylthyme account so you can list and save your schedules and import from external sources. Opens a browser page where you log in (Google, Apple, or email). After signing in, copy the token displayed on the page and provide it here. Tokens expire after about an hour; if a later call reports an auth error, call login again for a fresh one.
    list_my_programsList your saved Rhylthyme schedules. Requires a login token from the login tool.
    load_programLoad a specific saved program by ID. Returns a markdown summary plus a live-timeline URL.
    list_runsList the recorded executions of one saved program, newest first: when it ran, how it ended, and the actual makespan against the planned one. A run record is written whenever the live timeline is played (or the terminal runner is used); it is what makes the planned durations checkable against reality. Requires a login token; runs are private to whoever ran them.
    load_runOpen one recorded execution by run id: planned versus actual start, end and duration for every step, what ended each step (a person, a timer, an abort), time the clock was paused, and the recorded variance factors. Use it to see where a plan drifts from reality. Requires a login token.
    calibrate_programPropose new durations for one of the user's saved programs from its recorded runs, with the evidence. For every non-fixed step with enough runs a person ended by hand: the median becomes the proposed default, the 10th/90th percentiles the proposed min/max, widened so the author's own range is never narrowed. A fixed step that consistently overruns gets a "consider variable" note and no number, because only the author can decide that. The result is a per-step table (n, median, IQR, current, proposed, delta) plus what accepting the lot would do to the makespan and the critical path. **It never saves anything**: pass `accept` to get the calibrated program back — each changed duration carrying `calibratedFrom` — and then save_program if the user wants it kept. Requires a login token; the runs are private to whoever ran them.
    list_public_runsList the runs other people have contributed for one exact program version: when each ran, how it ended, actual against planned total, and the variance factors that run was recorded with. Contribution is opt-in per run and contributed records carry no user id and no step notes, so this is anonymous, aggregate evidence about how long a program really takes. **No login needed.** Identify the program either by `program_hash` (`sha256:<hex>`, as `programVersion` in a run record) or by passing the `program` JSON, which is hashed here.
    search_public_recipesSearch the public Rhylthyme catalog of cookable recipes, lab protocols, event templates, and workouts. Returns up to 50 matching programs (id, name, description, view URL) — no sign-in required. The catalog is split by environment: pass environment='kitchen' (default), 'laboratory', 'event' or 'gym' to pick the collection. Pass an id to **load_public_recipe** for the full schedule (its result already includes the live URL).
    load_public_recipeLoad a single public recipe / protocol / workout / event template by id. Returns a markdown summary plus a live-timeline URL (no visualize_schedule call needed).
    save_programSave a Rhylthyme program to your account. If a program with the same programId already exists, it will be updated. Requires a login token.
    preview_timelineRender a Rhylthyme program as a static Gantt-chart image so the user can SEE what the live timeline looks like, without committing to opening the live URL. Use this when the user asks for a 'preview' or 'picture' of the timeline, or when you have just built a freehand program and want to give the user a visual before they commit. The tool returns ONLY an image plus a one-line caption — no recipe prose, no ingredient list, no copyright concerns. Just the structural visualization of which step runs when on which track. Pair with **visualize_schedule** when the user wants the full shareable interactive URL too. This tool is for the visual-only quick preview case. **Planned versus actual.** Pass `run` — a recorded run of the same program, as **load_run** returns it in `run` — and the picture becomes a comparison: each step's real bar over a thin ghost bar at its planned position, outlined green where it finished early and amber where it ran late. That is the fastest way to show a person where a plan drifted. **Rendering option for HTML-artifact-capable clients (Claude.ai etc.):** Claude.ai's artifact sandbox blocks external scripts from non-cdnjs sources, so a `<script src="https://kitchen.rhylthyme.com/...">` tag will fail. To render the timeline yourself with the official Rhylthyme look, call **get_renderer_source** first to fetch the renderer's full source as a string, then embed that source verbatim inside a `<script>…</script>` block in your HTML artifact, followed by your program JSON and a call to `Rhylthyme.renderTimeline(document.getElementById('t'), program)`. The renderer is open-source (Apache-2.0), zero-dependency, ~9KB.
    get_renderer_sourceReturns the source code of the open-source Rhylthyme timeline renderer (Apache-2.0, ~9KB, zero dependencies). Use this when you're building an HTML artifact and the artifact sandbox blocks external scripts (e.g., Claude.ai's CSP only allows cdnjs.cloudflare.com). The returned text is plain JavaScript with a UMD wrapper — paste it verbatim inside a `<script>…</script>` block in your artifact, then call `Rhylthyme.renderTimeline(container, program)` where `program` is the Rhylthyme program JSON. After this call, the global `Rhylthyme` object exposes: `renderTimeline(container, program)`, `renderTimelineSvg(program)`, `computeStepTimings(program)`, `parseSeconds(value)` and `stepDurationSeconds(step)`.