Skip to main content
Glama

Rhylthyme

by com.rhylthyme
OverviewDiscussionsAdmin

Preview timeline image

preview_timeline

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runNoOptional 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.
programYesRhylthyme program JSON (same shape visualize_schedule accepts).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Rhylthyme toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources