Skip to main content
Glama

Rhylthyme

by com.rhylthyme
OverviewDiscussionsAdmin

Propose durations from recorded runs

calibrate_program
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kNoMeasurements a step needs before it gets a proposal (default 5). A step under it is reported as skipped with its statistics, not silently dropped.
sinceNoOnly runs started on or after this date (YYYY-MM-DD or ISO), e.g. to calibrate on the last month's cooks only.
tokenNoYour Rhylthyme access token from the login tool
acceptNoStep 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.
historyNoRun records to use instead of the ones stored against `program_id` (`runs` schema 0.1.0-alpha).
programNoThe program JSON to calibrate. Omit it and `program_id`'s saved JSON is used, so the usual call is just an id.
program_idNoLibrary program UUID (from list_my_programs). Names the program whose recorded runs are the evidence, and — with no `program` — the JSON to calibrate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description 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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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