Real-time multi-track schedules for cooking, lab protocols, events and workouts. Validate and share.
Scored across 18 tools
Most tools target distinct resource-action pairs: list_* vs load_* vs search_* are clearly separated, and analyze/validate/preview/visualize are different presentation modes. The closest boundary is import_from_source vs import_text, and analyze_schedule vs visualize_schedule could cause some initial confusion, though the descriptions separate them clearly.
All tool names follow a consistent lowercase snake_case verb_noun pattern: analyze_schedule, validate_program, list_runs, load_public_recipe, save_program. The only deviation is login, but as a single-verb auth action it fits naturally and does not break the overall convention.
18 tools is slightly above the ideal 3-15 range, but each tool serves a recognizable purpose within the scheduling domain: import, authoring, validation, visualization, run analysis, calibration, and public discovery. The count feels heavy but not bloated, and most tools earn their place.
The core workflow is well covered: import or create, validate, visualize, save, load runs, analyze, and calibrate. However, there is no delete_program/delete_run tool, and environment support is effectively create-only, so lifecycle management is not fully closed.
Resolve 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 a program is analysed on what it says.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Your Rhylthyme access token from the login tool. Only needed with `program_id`, to load your recorded runs; analysis itself needs no login. | |
| history | No | Recorded runs of this program (`runs` schema 0.1.0-alpha documents, as load_run returns them in `run`). Supplying them adds `predicted` per step and `predictedMakespan` / `predictedCriticalPath` to the result. Only runs that measure the executor count — completed, wall clock, speed 1 — and within them only steps a person ended, unpaused. | |
| program | Yes | Rhylthyme program JSON (any shape — validation errors come back in the result, not as a schema rejection). | |
| startAt | No | ISO 8601 datetime the program STARTS at. Ignored when finishAt is given. | |
| finishAt | No | ISO 8601 datetime the whole program should END at (e.g. '2026-11-26T18:00:00-05:00'). Start times are computed backwards from it. | |
| program_id | No | Library program UUID: with `token` and no `history`, the caller's own recorded runs of this program are loaded and used as the history. | |
| useDurations | No | Which duration set the makespan, wall-clock itinerary, critical path, conflicts and slack are computed from. "planned" (default) analyses the program as authored; "predicted" analyses it as history says it will actually run. Needs `history` (or `program_id` + `token`) to differ. | planned |
| predictionContext | No | How to condition the prediction. Everything is optional; with none of it the lookup uses the program's own hash and the factors each run recorded. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| steps | Yes | |
| tracks | Yes | |
| inFlight | No | |
| makespan | Yes | |
| actorPeak | Yes | |
| programId | Yes | |
| wallClock | Yes | |
| validation | No | |
| criticalPath | Yes | |
| durationsUsed | No | "planned" or "predicted": which duration set the makespan, itinerary, critical path and conflicts above were computed from. |
| makespanSeconds | Yes | |
| plannedMakespan | No | |
| predictedMakespan | No | |
| resourceConflicts | Yes | |
| bindingConstraints | No | |
| predictedCriticalPath | No | |
| plannedMakespanSeconds | No | |
| predictedMakespanSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, and the description reinforces this with 'Pure computation.' It adds substantial behavioral context: validation errors are returned in the result rather than as schema rejections, history loading adds predicted durations and changes analysis mode (planned vs. predicted), and the prediction model's basis (identical/model/none) is disclosed. No contradiction with annotations; the description enriches understanding of side-effect-free behavior and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: the core purpose and output summary come first, followed by a clearly delimited 'Analysing against real history' section for the advanced history-based prediction. While longer than typical, every sentence carries informational weight—no filler. The structure supports scanning, though it could be slightly tighter, hence a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, nested objects, and an output schema, the description covers the essential behavior: what is computed, what history does, how prediction works, and that validation findings are included. The output schema handles return structure, so the description does not need to spell it out. All relevant scenarios—timing questions, critical path diagnosis, contention checks—are addressed, and the prediction context is fully described. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter has a schema description. The tool description goes beyond that by clarifying the interplay between parameters: how history and program_id+token load runs, how finishAt vs. startAt are prioritized, how useDurations depends on history, and the semantics of predictionContext fields like userTags and verdicts. This adds meaningful context, though it does not individually elaborate on every parameter, so it stops short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise, action-oriented statement: 'Resolve a Rhylthyme program onto the clock and report what the live runner will do,' enumerating specific outputs (step timings, makespan, critical path, binding constraints, conflicts, slack). It further distinguishes itself from siblings like visualize_schedule by explicitly framing itself as the analysis step before visualization, and from validate_program by noting it returns validation findings as part of its computation. This makes the tool's purpose unmistakable and clearly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: answering schedule timing questions, diagnosing why a schedule is longer than expected, checking equipment contention before visualizing. It also references sibling tools (load_run, list_my_programs) for history and clarifies when to use history vs. program_id. However, it does not explicitly contrast with validate_program or preview_timeline, so an agent might not know when to prefer this over those, leaving a slight gap in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose 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.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Measurements a step needs before it gets a proposal (default 5). A step under it is reported as skipped with its statistics, not silently dropped. | |
| since | No | Only runs started on or after this date (YYYY-MM-DD or ISO), e.g. to calibrate on the last month's cooks only. | |
| token | No | Your Rhylthyme access token from the login tool | |
| accept | No | Step ids to accept, or "all". The result then also carries the calibrated program with `calibratedFrom` beside each written duration. NOTHING IS SAVED either way — pass that program to save_program if the user wants it kept. | |
| history | No | Run records to use instead of the ones stored against `program_id` (`runs` schema 0.1.0-alpha). | |
| program | No | The program JSON to calibrate. Omit it and `program_id`'s saved JSON is used, so the usual call is just an id. | |
| program_id | No | Library program UUID (from list_my_programs). Names the program whose recorded runs are the evidence, and — with no `program` — the JSON to calibrate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that nothing is saved, runs are private to their runner, fixed overruns only get a 'consider variable' note, and author ranges are never narrowed. It also describes the per-step table and makespan/critical-path effects, giving an agent a clear model of behavior and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, algorithm, output shape, side-effect warning, save workflow, and auth/privacy. It front-loads the core purpose and keeps critical caveats near the relevant behavior, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 7-parameter tool with no output schema, the description is unusually complete. It covers what triggers a proposal, how percentiles and widening work, what a fixed overrun gets, what the output table contains, what accept does, that nothing is saved, and that authentication and privacy constraints apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaningful relationships: the program/program_id fallback, the meaning of accept for returning a calibrated program with calibratedFrom, the k threshold behavior for skipped steps, and the token source. These go beyond the schema's individual field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Propose new durations for one of the user's saved programs from its recorded runs.' It clearly distinguishes this from sibling tools by focusing on calibration from recorded runs and producing evidence-based proposals, not analysis, rendering, or saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: requires a login token, never saves anything, and instructs the agent to pass the result to save_program if persistence is wanted. It does not explicitly name alternatives or exclusions among siblings, so it misses the top score, but the workflow guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create 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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| actors | No | How many people can work at once (default 1). | |
| description | No | ||
| resourceConstraints | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Create a Rhylthyme environment definition' while annotations declare readOnlyHint: true, which is a direct contradiction: creation implies a write or state change, not a read-only operation. The additional return-value guidance cannot compensate for this serious inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the purpose, the return value, and the required follow-up action. No filler words or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 20% schema coverage, and no output schema, the description is under-specified for correct invocation. It provides the return shape at a high level but omits guidance on required fields and constraint semantics, and the read-only contradiction further undermines trust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description does not compensate. It mentions 'resource constraints' and workspace examples like 'lab, kitchen, bakery' but does not explain key parameters such as maxConcurrent, actors, or how resourceConstraints items are structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Create') and resource ('a Rhylthyme environment definition'), and ties it to a concrete downstream workflow with 'visualize_schedule'. No other sibling tool creates an environment, so the purpose is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: the returned environment JSON should be used by copying resourceConstraints into the program or referencing environmentId before calling visualize_schedule. It does not list exclusions or alternatives, but none are needed given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns 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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the returned text is plain JavaScript with a UMD wrapper, the global Rhylthyme object exposes specific functions, and the source is open-source with zero dependencies. It doesn't contradict annotations. Minor gap: no mention of potential size/format edge cases, but the description is quite transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose and then provides usage details. It's longer than strictly necessary but every sentence adds value: license/size/dependencies, when to use, how to use, and what the returned object exposes. Slightly verbose but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description is remarkably complete. It tells the agent what the tool returns, why it exists, when to use it, how to invoke the returned code, and what API the returned code exposes. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete (100% coverage). The description doesn't need to explain parameters. It instead explains the return value and usage, which is the meaningful semantic content. Baseline 4 for zero params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns'), a specific resource ('source code of the open-source Rhylthyme timeline renderer'), and adds distinguishing details (Apache-2.0, ~9KB, zero dependencies). It clearly differentiates from siblings like preview_timeline or visualize_schedule by focusing on obtaining the renderer source for embedding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: '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)'. It also provides concrete usage steps: paste verbatim inside a <script> block and call Rhylthyme.renderTimeline(container, program). This is strong, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import 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).
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Raw source text (Opentrons .py) when the user pasted it instead of a URL. | |
| query | No | Search keywords (search), or the URL / id to import (import). | |
| token | No | User's Rhylthyme access token from the **login** tool. Required for action='import' and action='random' on every source, and for anything with source='benchling'. Not needed for action='search' on public sources. | |
| action | Yes | ||
| enrich | No | Split the import into parallel tracks with cross-track triggers (action='import' only). Runs the relationship turn of the plan_schedule prompt server-side against the imported step list: steps, durations and resources are kept as imported, tracks and start triggers are inferred, and any step the model adds is marked `metadata.inferred`. Costs a model call and is capped per day; if it fails you still get the un-enriched program. | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial context beyond these: token authentication needs, a per-day cap on the enrich feature, fallback behavior if enrich fails ('if it fails you still get the un-enriched program'), and automatic conversion of GitHub blob URLs. This goes well beyond the annotation hints and gives the agent a clear behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence carries necessary information: purpose, sources, actions, auth, enrich behavior, and post-import step. It is front-loaded with the purpose and then systematically covers each aspect. It could potentially be condensed, but given the complexity (6 parameters, multiple sources, and modes), the verbosity is justified. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, seven sources, three actions, and a special enrich mode, the description covers all necessary operational details: source-specific constraints, token prerequisites, per-day limits, failure fallback, and a recommended follow-up tool. There is no output schema, but the description clarifies that a program is returned and suggests visualize_schedule. The agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema covers 67% of parameters with descriptions, the description adds significant meaning to all six: it explains the source enum values (spoonacular, themealdb, protocolsio, cooklang, opentrons, benchling, llm-text) with usage notes, clarifies action semantics (search vs import vs random), explains token requirements per action, and details the enrich flag's behavior. This goes far beyond the bare enum and type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action ('Import a recipe or lab protocol from an external source into a Rhylthyme program') and enumerates specific sources and actions, distinguishing it from siblings like import_text (which handles text input) and search_public_recipes (which only searches). It is unambiguous about scope and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: lists preferred vs fallback sources, specifies when token is required vs not, explains action-specific requirements (e.g., cooklang and opentrons require action='import'), and directs the agent to run the returned program through **visualize_schedule** after import. It also details the enrich option and its conditions, leaving no ambiguity about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn 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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The source text itself: the recipe, protocol, run sheet or plan, as the user wrote or pasted it. Paste all of it — turn 1 reads it back and a long source is extracted in chunks. | |
| hints | No | Equipment and people limits in the user's own words, e.g. 'one oven, two burners, one cook'. Used as the scenario prompt's environment and as the resource constraints to expect. | |
| token | No | User's Rhylthyme access token from the **login** tool. Required: this import runs model calls on the server. | |
| deadline | No | When everything must be finished, if the user said: "18:00", "dinner at six", an ISO datetime. | |
| environmentType | Yes | Where the work happens: kitchen, lab, events, gym, or generic. Fills the scenario prompt's environment slot and becomes the program's environmentType. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several behavioral traits beyond annotations: it runs four model turns server-side (read-back, schema check, step extraction, tracks and triggers), provides step→span table for provenance, requires a token, costs a model call per turn, and is capped per day. This is rich context that annotations do not provide, and no contradiction with readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, covering purpose, usage, behavior, and requirements in about five sentences. It front-loads the primary purpose and usage context early, then details the process and constraints. It is slightly dense but each sentence adds value. Not overly verbose, but could be slightly more succinct in unessential details like 'read-back' enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step import with server calls, token requirement, cost and quota, output with step span), the description is nearly complete. It explains the output (program plus step→span table) despite lacking a formal output schema, and provides enough usage guidance. The only minor gap is not specifying the exact format of the step→span table or how errors are surfaced, but the description is sufficiently complete for an agent to decide to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100% and every parameter has a description, the tool description adds value by explaining how parameters are used in the import flow: for example, 'hints' is used as the scenario prompt's environment and resource constraints, 'environmentType' fills the scenario prompt's environment slot and becomes the program's environmentType. The description also explains that 'text' is read back in turn 1 and extracted in chunks. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting pasted text into a validated multi-track programUTE. It uses specific verbs ('Turn', 'import') and a clear resource ('block of pasted text' converting to a 'Rhylthyme program'), and distinguishes itself from import_from_source by specifying that it is for pasted text with no URL or supported service. This differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: when the user pastes steps themselves and no structural importer fits (no URL, no supported service, a photo transcribed, PDF copied out). It also implies when not to use it (when a structural importer fits), providing clear context and alternatives. It also mentions external requirements (user's token from login) and cost implications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your saved Rhylthyme schedules. Requires a login token from the login tool.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Your Rhylthyme access token from the login tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint, and destructiveHint already present, the annotations cover the safety profile. The description adds a meaningful behavioral requirement — authentication via the login tool — which the agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the primary action and resource front-loaded. The prerequisite is stated immediately after the main purpose, making the description efficient to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only, non-destructive list operation, the description is essentially complete: what it lists, whose data it shows, and what credential is required. No output schema exists, but 'List ... schedules' sufficiently implies the response form for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the token parameter with 100% coverage, so the description does not need to re-explain it. The description's 'Requires a login token' line reinforces the dependency but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('your saved Rhylthyme schedules'), so the core operation is immediately clear. It does not name a sibling tool or an explicit differentiation path, but the 'your saved' scope makes it distinguishable from list_public_runs and list_runs in practice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition: the user needs a login token from the login tool. It does not explicitly state when to prefer this tool over siblings such as list_public_runs or load_program, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many contributed runs to return, newest first (default 50). | |
| program | No | The program JSON to look up instead of a hash; it is hashed here with the same canonical hash the runtimes record. | |
| program_hash | No | Canonical program hash, "sha256:" plus 64 hex characters — the programVersion field of a run record, or programs.program_hash. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint annotations, the description reveals important behavioral traits: contribution is opt-in, records carry no user id or step notes, results are anonymous, and program JSON is hashed locally with the canonical hash. It also describes the returned data fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the purpose and returned data, then covers privacy and authentication, and closes with parameter guidance. The bold 'No login needed' is a useful, scannable signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with rich annotations and full schema coverage, the description covers what the tool returns, the privacy characteristics, the authentication requirement, and the two accepted identifier forms. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by specifying the program_hash format ('sha256:<hex>') and clarifying that the program JSON is hashed with the same canonical hash used by runtimes, which helps agents choose between the two identifier parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: lists runs contributed by other people for one exact program version. It clearly differentiates itself from sibling tools like list_runs by emphasizing 'other people', 'contributed', and anonymous aggregate evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it for contributed, anonymous run evidence and explicitly notes no login is needed. It does not name alternative tools or state when not to use it, but the scope is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Your Rhylthyme access token from the login tool | |
| program_id | Yes | The program UUID from list_my_programs or the program's URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it requires a login token, runs are private to the runner, and it returns makespan vs planned duration. It doesn't describe pagination or exact response shape, but with no output schema and these annotations, the description carries a reasonable burden and mostly fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first defines the resource and output, the second explains when records are created, the third covers auth and privacy. Front-loaded with the core action and scope. No redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 2 well-documented parameters and no output schema, the description is nearly complete. It covers the trigger for record creation, the privacy model, and the comparison value. The only minor gap is not describing the response format (e.g., fields returned per run), but the description does mention 'when it ran, how it ended, and the actual makespan against the planned one', which gives a good sense of the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both parameters (token and program_id). The description adds context that program_id refers to a saved program and that token comes from the login tool, but this largely mirrors the schema. Baseline 3 is appropriate because the schema does the heavy lifting and the description doesn't add significant new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('recorded executions of one saved program'), and a clear scope ('one saved program', 'newest first'). It also distinguishes itself from the sibling list_public_runs by emphasizing privacy and the specific program context. The title and description align well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when runs are recorded ('whenever the live timeline is played or the terminal runner is used') and why they matter ('makes the planned durations checkable against reality'). It implies this tool is for private runs, contrasting with list_public_runs, though it doesn't explicitly name the sibling or say 'use list_public_runs for public runs'. This is clear context but lacks an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a specific saved program by ID. Returns a markdown summary plus a live-timeline URL.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Your Rhylthyme access token | |
| program_id | Yes | The program UUID from list_my_programs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by disclosing the output: a markdown summary and a live-timeline URL, which is beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the action, input, and return format without any filler. The key scoping constraint ('by ID') is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only tool, the description is complete: it names the input, the action, and the return values. Since there is no output schema, the explicit mention of the markdown summary and live-timeline URL covers the critical missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 both token and program_id sufficiently. The tool description adds no additional parameter meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Load') and resource ('a specific saved program by ID'), clearly distinguishing it from siblings like save_program, load_public_recipe, and load_run. It also states the return type, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for loading a saved program by ID, which is a distinct use case among the siblings. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a single public recipe / protocol / workout / event template by id. Returns a markdown summary plus a live-timeline URL (no visualize_schedule call needed).
| Name | Required | Description | Default |
|---|---|---|---|
| program_id | Yes | Program UUID (from search_public_recipes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the non-destructive, read-only, idempotent, open-world behavior, so the bar is lower. The description adds behavioral value by stating the output shape (markdown summary plus live-timeline URL) and by telling the agent that a separate visualize_schedule call is unnecessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler. The first sentence states what loads and how it is identified; the second states the return value and the key workflow hint about avoiding visualize_schedule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with rich annotations and no output schema, the description covers the essential context: what it operates on, how to identify the recipe, what is returned, and the most important integration note. Nothing critical is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter, including the type and provenance ('Program UUID (from search_public_recipes)'), so the description adds no meaningful parameter detail beyond 'by id'. Baseline 3 is appropriate because the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Load'), a resource class ('single public recipe / protocol / workout / event template'), and the lookup key ('by id'). The 'public' qualifier and return description distinguish it from siblings like load_program or load_run, and the input schema reinforces that the ID comes from search_public_recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended workflow: after searching public recipes, load a single one by id. It explicitly tells the agent not to call visualize_schedule because the response already contains a live-timeline URL. However, it does not explicitly say when to prefer this over load_program or load_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open 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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Your Rhylthyme access token from the login tool | |
| run_id | Yes | The run UUID from list_runs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral details beyond annotations: the exact data contents returned and the need for a login token. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, then a colon-delimited list of returned data, then usage context and a requirement. Every phrase earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with two parameters and no output schema, the description adequately explains what data will be returned and the prerequisite token. It does not cover error cases or edge scenarios, but for a simple retrieval operation, this is not critical. The description is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (token and run_id) are already fully documented in the schema. The description's mention of 'Requires a login token' reinforces the token requirement but adds little beyond the schema. Since coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: opening a single recorded run by ID, and enumerates the specific data returned (planned vs. actual timings, step endings, pauses, variance factors). This distinguishes it from list_runs (which lists runs) and load_program (which loads a program), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Use it to see where a plan drifts from reality.' It implies that run_id comes from list_runs (via the schema) and mentions the login token requirement. It doesn't explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign 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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Paste the access token shown on the login page after you sign in. Leave empty on the first call to get the login URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it opens a browser page, requires the user to copy a token, and notes token expiration (~1 hour) and the need to re-login on auth errors. This goes beyond the annotations and helps the agent manage the auth lifecycle. Minor gap: it doesn't state what happens if the token is invalid or expired, but the auth-error guidance covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, the login flow, and token expiration/re-login guidance. It's front-loaded with the main purpose and then provides necessary operational details. No fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter auth tool with no output schema, the description covers the essential flow: how to initiate login, how to provide the token, and what to do on expiry. It doesn't describe the output/return value (e.g., what a successful login returns), but since there's no output schema and the tool is primarily a state-changing auth step, this is a minor gap. The description is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the token parameter. The description adds meaning by explaining the two-step usage: leave empty on first call to get the login URL, then paste the token. This is essential context that the schema alone doesn't provide, so the description compensates well. Slight deduction because the description doesn't specify the token format or what 'empty' means exactly (e.g., empty string vs omitted), but the schema's 'Leave empty' is clear enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: signing in to a Rhylthyme account to enable listing/saving schedules and importing from external sources. It uses a specific verb ('Sign in') and resource ('Rhylthyme account'), and the title 'Connect Rhylthyme account' aligns well. It distinguishes itself from siblings by focusing on authentication, which none of the sibling tools do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use it first to authenticate, and call it again if a later call reports an auth error because tokens expire after about an hour. It also explains the two-step flow (leave token empty first, then provide token). This is clear and actionable, though it doesn't explicitly name alternatives—but there are no real alternatives for login among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render 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.
| Name | Required | Description | Default |
|---|---|---|---|
| run | No | Optional recorded run of the SAME program (`runs` schema 0.1.0-alpha — the `run` object from load_run). Draws planned-vs-actual: the actual bars over ghost bars at the planned positions, coloured by the sign of each step's end deviation. | |
| program | Yes | Rhylthyme program JSON (same shape visualize_schedule accepts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses the return shape ('ONLY an image plus a one-line caption') and the planned-vs-actual color behavior (green early, amber late), which annotations do not cover. However, annotations indicate readOnlyHint=false and idempotentHint=false, and the description does not clarify whether rendering has side effects or resource implications, leaving a small transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose and usage are front-loaded, and bolded section headings make the structure easy to scan. The artifact-sandbox workaround is valuable but lengthy, pushing the description past a truly minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description tells the agent exactly what to expect (image plus one-line caption), documents optional run behavior, distinguishes sibling tools, and provides an artifact-rendering path. For the tool's complexity, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds useful concrete detail—explicit green/amber color semantics and the 'same program' constraint—but much of the run explanation restates the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Render a Rhylthyme program as a static Gantt-chart image.' It also differentiates itself from siblings by labeling this as the 'visual-only quick preview case' and naming visualize_schedule as the interactive-URL counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions: 'Use this when the user asks for a preview or picture of the timeline.' It also names alternatives and when to prefer them, such as pairing with visualize_schedule for a shareable interactive URL and calling get_renderer_source for HTML-artifact embedding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a Rhylthyme program to your account. If a program with the same programId already exists, it will be updated. Requires a login token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Your Rhylthyme access token | |
| program | Yes | Rhylthyme program JSON. Read rhylthyme://guide/authoring for the rules. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful context beyond those hints by spelling out the upsert behavior and the authentication requirement. There is no contradiction between the description and the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each carrying information: the save action, the upsert behavior, and the auth requirement. The key verb and object are front-loaded with no filler or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the very rich input schema and the annotations, the description covers the essential behavioral points: persistence target, upsert behavior, and authentication. It omits return/error details, but with no output schema and a fully documented input schema, this is a minor gap for a straightforward save operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with token documented as 'Your Rhylthyme access token' and program described as 'Rhylthyme program JSON. Read rhylthyme://guide/authoring for the rules.' The description adds little beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb 'Save' and a specific resource: 'a Rhylthyme program to your account,' so an agent immediately knows the action and target. It also clarifies upsert semantics ('if a program with the same programId already exists, it will be updated'), which distinguishes it from generic imports or loads. This is unambiguous even among the sibling tool list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: save is for persisting a program to the caller's account, and it states the prerequisite 'Requires a login token.' It does not explicitly name alternatives or when-not-to-use cases, but the save-to-account framing is sufficient to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 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).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Keyword to search (matches name and description). Empty returns the most recent entries. | |
| environment | No | Which catalog to search. Defaults to "kitchen"; use "laboratory", "event" or "gym" for the other collections. | kitchen |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| query | Yes | |
| results | Yes | |
| environment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: no sign-in required, up to 50 results, environment-based catalog splitting, and a pointer to the follow-up tool for full schedules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The main purpose is front-loaded, return information is included, and the environment guidance plus follow-up tool reference are both immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with an output schema, the description covers purpose, auth requirements, result shape, environment selection, and the next logical step. An agent has everything needed to invoke it correctly and decide what to do with the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (limit lacks a description), but the description adds meaning by explaining the environment parameter maps to distinct catalog collections and by clarifying the result cap of 50. It slightly under-specifies by omitting the 'events' enum variant, but the schema itself still lists it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), a specific resource ('the public Rhylthyme catalog'), and the exact categories included (recipes, lab protocols, event templates, workouts). It also states the return fields, making it easy for an agent to know what this tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says this searches the public catalog with no sign-in required, and it directs the agent to pass an id to load_public_recipe for the full schedule. It does not explicitly discuss when not to use this tool versus list_public_runs or list_my_programs, but the public-vs-personal distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check 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.
| Name | Required | Description | Default |
|---|---|---|---|
| program | Yes | Rhylthyme program JSON (any shape — validation errors come back in the result, not as a schema rejection). |
| Name | Required | Description |
|---|---|---|
| info | No | |
| stats | Yes | |
| valid | Yes | |
| errors | Yes | |
| warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly/idempotent/destructive), the description discloses no network, no side effects, safe to call repeatedly, and explains that validation errors are returned in the result rather than as schema rejections. It also defines the semantics of findings (code/message/fix), warnings (advisory), and info notes, which is exactly the behavioral context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, and every sentence earns its place: purpose and timing are front-loaded, error categories are concrete, result semantics are explicit, and the safety note is valuable. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with a rich output schema and one flexible input, the description covers the purpose, timing, result contract, warning/info semantics, and safety profile. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, program, has 100% schema description coverage, including the crucial 'any shape — validation errors come back in the result' behavior, so the tool description does not need to compensate. The description itself does not add much about the parameter beyond referring to the program, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific action and object: 'Check a Rhylthyme program for structural and scheduling errors' and positions it temporally 'BEFORE visualizing or saving it', which separates it from sibling tools like visualize_schedule and save_program. It also enumerates concrete error categories, so an agent knows exactly what domain this validation covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it ('BEFORE visualizing or saving it') and that it is pure computation safe to call repeatedly. It does not name alternatives such as analyze_schedule or calibrate_program or give explicit when-not-to-use conditions, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render 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.
| Name | Required | Description | Default |
|---|---|---|---|
| program | Yes | Rhylthyme program JSON. Read rhylthyme://guide/authoring for the rules. | |
| allowInvalid | No | Publish even if validation reports errors. Only use when the user explicitly wants an imperfect draft shared; the live page may show wrong timings. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| shareId | Yes | |
| imageUrl | Yes | |
| warnings | Yes | |
| makespanSeconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-readonly, non-destructive write operation. The description adds valuable behavioral context: validation is performed first (same checks as validate_program), invalid programs are refused with fix hints, and the output is a markdown preview plus a shareable URL. This goes beyond the annotations and informs the agent of side effects and outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it leads with the core purpose, then a bolded usage directive, then behavioral notes, then output details. It avoids filler and front-loads the most important information. It is longer than minimal but earns its length with specific, non-redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested program object, validation rules, publishing side effects) and the existence of a detailed output schema, the description covers the essentials: purpose, usage rule, validation behavior, and output format. It also points to a guide for authoring rules. No critical information for an agent to call it correctly is missing, though it could mention the allowInvalid parameter more explicitly (but that's in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both parameters (program and allowInvalid). The description does not add parameter-specific semantics beyond referencing validation and output, which is more about tool behavior. It mentions the program must be valid by default, but that's also implied by the allowInvalid default. Baseline 3 is appropriate since the schema already documents the parameters thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Render a multi-step parallel schedule as a live timeline') and clarifies scope ('Call this for ANY schedule you produce — imported, catalog match, or built freehand'). It also implicitly distinguishes from siblings like validate_program (validation is done inside) and preview_timeline (publishes a live timeline, not just a preview).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit 'when to use' directive ('Call this for ANY schedule you produce') and a rule of thumb ('A schedule belongs in a visualization, never in prose'). It mentions that invalid programs are refused, implying you don't need a separate validation call, but it doesn't explicitly name alternatives or when NOT to use it. Still, the guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_schedulecalibrate_programcreate_environmentget_renderer_sourceimport_from_sourceimport_textlist_my_programslist_public_runslist_runsload_programload_public_recipeload_runloginpreview_timelinesave_programsearch_public_recipesvalidate_programvisualize_scheduleShared countdown timers that stay in sync on every screen — no account, any number of viewers.
Meeting agenda timer for AI assistants: build agendas in chat, share a live synced countdown.
Free no-signup group scheduling (a modern When2meet): share one link, find a time for everyone.
Turn any goal with a deadline into a private, gamified, evidence-based execution calendar.
Add one secure layer between your agents and this server.