Rhylthyme

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, openWorld=false. The description reinforces this with 'Pure computation' and adds genuine behavioral context that annotations don't convey: that history or program_id activates recorded-run duration prediction. It does not detail auth requirements or rate limits, so it does not reach 5.

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?

Four front-loaded sentences: outputs first, then the finishAt use case, then the computation/safety framing, then the optional prediction mode. Every sentence carries information, though the opening list is dense and could be trimmed slightly.

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 an 8-parameter tool with nested objects, an output schema (so return values need not be described) and full safety annotations, the description covers outputs, the key scheduling direction parameter, and the prediction path. The predictionContext field is deferred to an external guide, which is a minor gap but acceptable given its complexity.

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 baseline is 3, and the schema already documents finishAt, startAt, history, and program_id in detail. The description lifts above baseline by tying finishAt to a concrete user intent and explaining that history/program_id switches on prediction, adding semantic meaning beyond the field docs.

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?

Specific verb+resource ('analyze schedule timing') with the exact outputs enumerated: each step's start/end, total length, critical path and its gates, resource conflicts, slack per track. The phrase 'Pure computation' distinguishes it from visualization siblings like visualize_schedule and preview_timeline without needing to open a schema.

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?

Gives clear context: pass finishAt for backwards scheduling ('when do I start X so everything is ready at 6pm?') and supply history/program_id to enable duration prediction. However, it never names an alternative sibling or states when NOT to use this tool, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered; the description still adds real value by stating 'Saves nothing ... Nothing is saved either way' even with accept, and by disclosing the auth requirement ('Needs the user's Rhylthyme account'). It stops short of describing rate limits or failure behavior.

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, front-loaded with the action and its statistical defaults, followed by side effects and the account requirement. Dense but every clause carries information; 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 7-parameter, zero-required tool with nested objects and no output schema, the description covers the core behavior, the non-persistence guarantee, the auth need, and hints at the return contents (evidence per step, effect on total length). It could say more about how program vs program_id vs history interact, but the essentials are present.

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 all seven parameters are already documented in the schema. The description's mention of accept returning the calibrated program and of the median/P10–P90 basis adds mild meaning but largely repeats the schema, so the baseline of 3 applies.

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 gives a specific verb+resource ('Propose durations for a saved program from its recorded runs') and even specifies the statistical method (median default, P10–P90 range, at least as wide as the author's). It is clearly distinct from siblings like validate_program or review_program, but it never names or contrasts an alternative explicitly.

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?

Usage is implied by the verb and the input set (a saved program plus its runs), and the 'Saves nothing' clause signals the preview-style intent. However there is no explicit when-to-use/when-not statement and no routing to alternatives such as review_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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds context about the purpose of resourceConstraints (scheduling around shared equipment), which is useful. However, it does not disclose what happens if resourceConstraints is omitted, whether the tool validates constraints, or how the result is returned. With annotations covering the safety profile, a 3 is appropriate.

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 sentence that front-loads the core purpose and includes a concrete example ('one oven, two centrifuges, one stage'). It is efficient and readable, though the example could be seen as slightly verbose. No wasted words overall.

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?

The tool has 5 parameters, 3 required, no output schema, and low schema coverage. The description explains the central concept (resourceConstraints) and its purpose, but does not cover the other required parameters (name, type) or the optional ones. An agent would need to open the schema to understand what 'type' values are valid and what 'name' means. The description is adequate for the core use case but incomplete for full parameter understanding.

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%, so the description must compensate. The description explains the meaning of resourceConstraints (equipment limits) and its role in scheduling, which adds value beyond the schema's bare 'array' type. However, it does not explain the 'name', 'type', 'actors', or 'description' parameters, and the schema itself only documents 'actors'. The description partially compensates but leaves gaps.

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 ('Describe'), a resource ('a workspace's equipment limits'), and the output form ('as resourceConstraints to copy into a program'). It clearly conveys the tool's purpose. However, it does not explicitly distinguish itself from sibling tools like calibrate_program or validate_program, though the resourceConstraints focus provides some implicit differentiation.

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 usage context: it is for defining equipment limits so that steps sharing equipment are scheduled around each other. This gives a clear 'why' but no explicit 'when to use vs alternatives' or exclusions. The sibling list includes many program-related tools, but the description does not name any alternative or condition for choosing this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds useful non-obvious behavior: the payload is ~90 KB, Apache-2.0, dependency-free, and exposes Rhylthyme.renderTimeline(container, program). It does not mention caching or whether the source is versioned/pinned.

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?

A single dense sentence that front-loads the return value and packs license, size, dependency status and API surface 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?

With no output schema, the description adequately covers the return payload (source code, size, license) and how to consume it, which is everything an agent needs to call this no-argument tool 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 tool takes zero parameters, so the baseline is 4. The description does describe the arguments of the function it exposes (container, program), which is helpful context even though it is not tool input.

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 precise verb+resource (return the timeline renderer's JavaScript source) and adds distinguishing detail — license, size, dependency-free, and the exported API. It is clearly separable from siblings like preview_timeline or visualize_schedule, which render rather than ship source.

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?

Gives a concrete triggering condition: use it for an HTML page or artifact that cannot load external scripts. That is a clear when-to-use, though it does not explicitly name the alternative (e.g., fetching the script from a CDN or using preview_timeline) as a when-not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context the annotations lack: which actions require the user's Rhylthyme account, and that enrich kicks off parallel tracks consuming one model call capped per day. It is silent on error/partial-import behavior, but the incremental value over annotations is real.

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?

Dense and front-loaded: the core purpose leads, then source taxonomy, then action semantics, then auth and enrich. The telegraphic fragment style ('action: search (no account needed), import ...') is compressed but readable, and no sentence is 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 6-parameter, no-output-schema tool, the description covers purpose, source/action enums, auth prerequisites, and the enrich modifier, and notes the return ('Returns the program'). Remaining omissions (text parameter interplay, token handling) are covered by schema descriptions.

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?

At 67% schema coverage the schema does much of the work, but the description adds meaning beyond it: it groups the source enum values into recipes/lab/cooklang and ties query to the action ('query = URL or id'). text and token are left to the schema descriptions, and the description omits that action='import' can also draw from pasted 'text', a minor gap.

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 with scope: 'Import a recipe or protocol from a URL or service into a program,' and enumerates the external sources grouped by domain (recipes vs lab). It does not, however, distinguish itself from the sibling import_text (pasted-text path) or load_program, so the agent must infer the boundary.

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 spells out the three action modes and their conditions — search needs no account, import takes a URL or id, random is a discovery path — plus the account requirement for import/random/benchling. That is concrete when-to-use guidance for the tool's own modes, but it gives no guidance on choosing this tool over siblings such as import_text or search_public_recipes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavioral context beyond the annotations: a daily rate cap ('Capped per day'), the auth requirement, the four-turn cost profile, and the source-span provenance table. These are real operational facts an agent needs. The cap is not quantified, and its 'program on the server' phrasing sits in mild tension with readOnlyHint=true, though the separate save_program sibling makes a non-persisting read plausible.

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?

One dense sentence front-loads the core action and then appends the turn count, provenance table, cap and auth requirement — all of which earn their place. It is a long run-on that could be split, and the 'Rhylthyme' spelling looks off, but there is 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 five-parameter tool with full schema coverage, no output schema, and annotations present, the description covers output shape (validated program plus provenance table), auth, and rate limits. It is nearly complete; only the unquantified cap and lack of sibling routing keep it from a 5.

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 all five parameters (text, hints, token, deadline, environmentType). The prose adds no parameter-level detail (e.g., the valid environmentType values or deadline formats) beyond what the schema provides, matching the baseline 3.

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 (turn/import) and resource (pasted text → validated multi-track program) and gives concrete examples of source text (recipe, protocol, run sheet, training plan). The 'pasted text' framing implicitly distinguishes it from the sibling import_from_source, though it never names that alternative for an unambiguous comparison.

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?

Usage is only implied by the input type ('pasted text'); the description states the account prerequisite but gives no explicit when-to-use/when-not, nor does it route the agent to import_from_source for non-pasted sources or to save_program afterward. Adequate but leaves the selection decision to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the useful context that the user must have a Rhylthyme account, but it does not describe return format, pagination, or failure behavior. No contradiction with 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?

Two short sentences with no filler. The core action is front-loaded and the account requirement is stated succinctly. Every word 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 read-only list operation with one optional parameter and no output schema, the description is largely sufficient. It could mention what is exactly returned or that only the authenticated user's programs are included, but the title and wording already imply a list of saved programs.

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 fully documents the single token parameter (100% schema description coverage), including guidance to omit it when the account is connected. The description adds no additional parameter meaning, 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?

States a specific action and object: listing the user's saved programs. The possessive 'my' and 'saved programs' clearly separate it from sibling tools like list_runs or list_public_runs, even though it doesn't name them explicitly.

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 usage after the user is connected to their Rhylthyme account, and it is clearly intended for retrieving personal saved programs. However, it does not explicitly mention when to use this instead of alternatives or provide any exclusionary guidance, leaving some routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds genuine behavioral context: results are anonymous contributions from other users, no account is required, and 'newest first' ordering is disclosed. It does not state rate limits or result volume limits beyond the schema's own default.

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 compact sentences with no filler; the resource and scope lead, followed by the use case, the auth note, and the accepted inputs. Slightly clipped but every clause carries information.

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?

No output schema exists, and the description compensates by naming the returned fields (actual vs planned length, conditions), which is what an agent needs to decide relevance. Combined with the schema's parameter docs and annotations, it is complete enough, with only pagination/result-volume behavior left implicit.

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 goes slightly beyond by presenting `program` and `program_hash` as interchangeable alternatives ('Takes program or program_hash'), clarifying an either/or relationship the schema itself does not state. It adds no format detail for the hash beyond what the schema documents.

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 (list contributed/anonymous runs) plus the scope constraint of 'one exact program version' and what each record contains (actual vs planned length, conditions). The 'other people contributed' framing implicitly separates it from list_runs/list_my_programs, though no sibling is named explicitly.

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 phrase 'For "how long does this really take?"' implies the intended use case (real-world duration estimation) and 'No account needed' signals availability without auth. However, it never names an alternative such as list_runs for one's own runs or explains when NOT to use this tool, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 description doesn't need to repeat safety info. It adds semantic context about the content of runs (e.g., actual vs planned length) but doesn't disclose any further behavioral traits such as pagination or return format. Given the annotations cover the safety profile, a 3 is appropriate.

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, gets straight to the point, and front-loads the primary purpose. The second sentence about the account requirement is slightly redundant given the token parameter but not wasteful. It avoids unnecessary detail and is appropriately brief.

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 read-only list operation with full schema coverage and safety annotations, the description provides sufficient context: what it lists, the use case, and the account requirement. It doesn't specify the return format, but since there's no output schema, agents can reasonably infer a list of run objects. Minor gap but not critical.

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 provides full descriptions for both parameters (100% coverage), so the description adds no extra meaning. The description does not elaborate on token requirements or program_id handling beyond what the schema already states. Baseline 3 applies because the schema handles parameter documentation.

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 action 'List recorded runs' and specifies the resource 'of a saved program' with the kind of information returned (when, how it ended, actual vs planned length). It distinguishes itself from siblings like list_public_runs (public runs) and load_run (single run) by focusing on the user's own saved program runs.

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 a concrete use case, 'For how long did this take last time?', and notes the prerequisite of having the user's Rhylthyme account. It implies this is for personal runs rather than public ones, but does not explicitly name alternatives like list_public_runs. Still, the usage context is clear enough for an agent to decide when to call it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety. The description adds useful behavioral context beyond those annotations: it requires the user's account and specifies that the result is a summary plus live-timeline URL. No contradiction with 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 one compact sentence that front-loads the core action and resource, then gives the output and the account requirement. Every part earns its place, with no filler or repetition of schema details.

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 two-parameter read-only tool with rich annotations and full schema coverage, the description is complete enough. It explains what the tool returns, identifies the target resource, and notes the necessary account context. No critical information 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?

Schema description coverage is 100%, so the schema already documents program_id and token clearly, including the token's conditional omission and the program_id's source. The description adds little parameter-specific meaning beyond restating 'by id', so a baseline score 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?

Description states a specific verb ('Open'), a specific resource ('one of the user's saved programs'), a key selector ('by id'), and the expected result ('summary plus live-timeline URL'). This clearly distinguishes it from siblings like list_my_programs, load_run, and load_public_recipe without needing to open the schema.

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: this is for opening a saved program belonging to the user, and it notes the prerequisite that the user must have a Rhylthyme account. It does not explicitly name alternatives or exclusion conditions, but the intended use case is evident from the title and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new information by stating the return payload ('summary plus live-timeline URL') for a tool with no output schema, though it says nothing about auth or rate limits for public access.

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?

One compact sentence that front-loads the action, the resource, and the selection key, then appends the return value. No filler, no 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 single-parameter read tool with no output schema, the description covers the essential return content and the annotations cover safety and idempotency. What is missing is any statement of when to prefer this over load_program or list_public_runs.

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% and the single parameter is fully documented there, including its UUID format and provenance. The description only echoes 'by id' and adds nothing the schema does not already say; baseline 3 applies.

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 ('Open') and resource ('a public catalog entry by id') and says what comes back (summary plus live-timeline URL). The 'public' qualifier distinguishes it from load_program, but it never names that sibling explicitly, so the differentiation is inferential rather than stated.

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?

There is no when-to-use or when-not-to-use guidance; the only routing signal ('from search_public_recipes') lives in the schema's parameter description, not the tool description. An agent must infer that this is the public counterpart to load_program with no help from the text.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 description does not need to restate safety. It adds useful behavioral context beyond annotations by specifying what the run view contains (per-step timing, ending causes, pauses, drift) and that it requires the user's Rhylthyme account.

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 short sentences, front-loaded with the primary action and immediately followed by the distinguishing payload. Every clause earns its place; even 'Shows where a plan drifts' adds the practical purpose rather than repeating prior 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 read-only tool with well-covered schema and strong annotations, the description is largely complete: it names the resource, the displayed information, and the account prerequisite. It does not describe return format, but the absence of an output schema and the 'shows' wording make the behavior understandable enough 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 description coverage is 100%, with clear descriptions for run_id ('Run UUID from list_runs') and token ('Access token from the login tool. Omit when the account is connected.'). The description adds no parameter-specific semantics; the baseline of 3 is appropriate because the schema already carries the full parameter burden.

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 and resource ('Open one recorded run') and immediately clarifies the tool's distinctive content: planned vs actual timing, step outcomes, and pauses. It differentiates from siblings like list_runs (one run, not a list) and load_program (run execution data, not source). This is not a mere restatement of the title.

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 implies when to use the tool: when you need one recorded run's execution detail and plan drift. It does not explicitly name sibling alternatives or exclusion conditions, but 'Open one recorded run' and the content description give clear context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description reveals the two-step flow, the one-hour token lifetime, and the scope of what the login unlocks. It does not contradict the readOnly or idempotent hints.

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 short sentences front-load the purpose and then add only necessary constraints. There is no filler and no repetition of schema information.

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 helper with no output schema, the description covers the flow, the prerequisite, the scope, and the token lifetime. An agent has enough 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?

The schema already documents the token parameter, but the description adds the critical behavior of leaving it empty on the first call to obtain the URL. This makes the parameter's dual role explicit and actionable.

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 concrete two-step operation: returning a sign-in URL and accepting a pasted token. It clearly identifies the resource (Rhylthyme account) and distinguishes this auth tool from the program/run/recipe 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?

It explicitly states the condition for use: apps that cannot connect the account directly, and clarifies that only the user's own saved programs, runs, and imports require it while public content works without. This gives an agent clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations alone (readOnlyHint=false, idempotentHint=false, destructiveHint=true) are puzzling for a preview call, and the description supplies the key explanation: the image is served from a public share link, which accounts for the side effect and non-idempotency. It still does not explain the destructiveHint=true or whether repeated calls create new links, leaving one annotation unexplained.

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 short sentences, no filler: what is returned, how it is delivered, and how the optional parameter changes the output. Front-loaded with the outcome and the trigger phrases.

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 two-parameter image-producing tool with no output schema, the description covers the return artifact (static Gantt with caption), the delivery mechanism (public share link), and the effect of the optional parameter. It omits practical details like the returned URL field or whether the share link is permanent.

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 real meaning for `run` — that supplying a run record draws actual bars over the plan — which is more actionable than the schema's own "draws planned versus actual." The `program` parameter gets no elaboration beyond the schema pointer.

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 ("Return a static Gantt image of a program") and reinforces it with user-phrase triggers ("show me a preview", "a picture of the timeline"). It does not explicitly contrast itself with the adjacent siblings visualize_schedule, get_renderer_source, or analyze_schedule, so an agent still has to infer which of those produces an image versus an interactive view.

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?

Gives concrete invocation context via the quoted user utterances and explains the conditional case for the `run` parameter (actual bars over the plan). There is no explicit when-not guidance or named alternative, so an agent choosing between this and visualize_schedule gets no direct help.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnly, idempotent, and destructive hints, so the description earns credit for adding the auth requirement (needs the user's Rhylthyme account) and clarifying the output purpose (findings to show the user). 'Changes nothing' reinforces the read-only behavior without contradicting 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?

Three sentences, each earning its place: the action and examples, the side-effect/return behavior, and the auth prerequisite. The most important information is front-loaded in the first sentence.

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 review tool with a well-described input schema, the description covers purpose, non-mutation, auth, and the broad return type. It does not specify the structure of findings or the required relationship between program and source_url/source_text, but the annotations and schema cover most of the remaining operational context.

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 baseline is 3. The description hints that source_url/source_text are the comparison source, but it does not add parameter-level detail beyond what the schema already provides.

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: a model reads an imported program against its source and reports what looks wrong. Concrete examples (dropped steps, overlapping chains, disagreements) make the tool's function unambiguous and distinguish it from import/validate 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?

It gives context: use after import, with a source available, and requires the user's Rhylthyme account. It does not explicitly name alternatives like validate_program or state when not to use this tool, so the routing guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds that the same programId updates it (idempotent behavior) and requires an account, which is beyond the annotations. It does not detail destructive consequences beyond updating, but it doesn't contradict the annotations and adds meaningful context.

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 with no redundant words. It front-loads the core purpose, then adds the key update behavior and the account requirement. 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?

Given the tool has nested objects and no output schema, the description covers the essential context: it saves a program, updates if same programId, and requires an account. It doesn't mention error cases or return values, but those aren't required by the rubric when no output schema exists, and annotations cover safety hints.

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%, and both parameters are described in the input schema (token and program). The description adds no new parameter-level detail beyond mentioning 'programId', which is not a parameter itself. Since the schema fully covers the parameters, 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 uses a specific verb ('Save') with a clear resource ('a program to the user's account') and explicitly labels the intent ('save this for later'). It also mentions the idempotent behavior (same programId updates), which differentiates it from load_program and list_my_programs among the 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 gives a prerequisite ('Needs the user's Rhylthyme account') but does not explicitly state when to use this tool over alternatives, nor does it mention any when-not conditions. It implies usage for saving, but lacks explicit routing guidance compared to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description adds two things beyond them: the auth requirement ('no account needed') and the shape of the result set (ids, names, descriptions, URLs).

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. The core action and coverage come first, the auth and return-shape facts second. Every clause 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?

An output schema exists, so return values needn't be detailed, and the description still summarizes them. All three parameters are optional with defaults, but the description never mentions the default environment (kitchen) or limit cap, leaving minor gaps an agent must get from 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 description coverage is 67%, so the schema documents query semantics (name/description matching, empty = newest) and the environment enum. The description's 'by name or keyword' and content-type list roughly mirror the schema without adding format, matching rules, or default behavior.

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 gives a specific verb (search) and resource (the public catalog) and enumerates the content types covered: recipes, lab protocols, event templates, workouts. This cleanly separates it from siblings like load_public_recipe (fetch one by id) and list_public_runs.

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?

Usage is only implied: the agent can infer it should search when it lacks an id and load_public_recipe when it has one, but no alternative or exclusion is stated. The 'no account needed' note adds a useful precondition but is not when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces this with 'Pure computation' and adds the finding structure (code, message, suggested fix), which is genuine behavioral context beyond the annotations and is consistent with them.

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 full purpose, a concrete list of checks, the output finding structure, and a purity guarantee. No filler; the most decision-relevant content is front-loaded.

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 objects, many validation rules) and that an output schema exists, this description is adequate: it summarizes the checks, notes the finding format, and links to authoritative references (rhylthyme://guide/authoring, rhylthyme://schema/program) for deeper details. It does not leave critical decision-making gaps.

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%, with the program parameter already thoroughly documented (formats for durations, triggers, tracks, steps). The description adds no extra meaning about the parameter itself, so the baseline of 3 applies.

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 ('check') plus resource ('program') and enumerates the exact validation dimensions (ids, triggers, overlaps, resourceConstraints, durations, replicates/instances). It clearly conveys validation semantics and distinguishes from siblings like calibrate_program or analyze_schedule, though it does not explicitly contrast with review_program.

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 states when to use the tool ('before publishing or saving it') which gives a clear context. However, it does not name alternative tools or provide explicit 'when not to use' guidance, leaving the selection rationale mostly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds useful behavior beyond the annotations: it validates before publishing, refuses invalid programs with fix hints, and creates a public share link. The annotations already signal destructive/open-world behavior, so the description does not need to restate those; it could still mention the allowInvalid exception or permanence of publication, but the key behavioral traits are disclosed.

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 short sentences front-load the primary action and output, then give usage intent and validation behavior. Every sentence earns its place without repeating 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?

For a two-parameter tool with an output schema and annotations, the description is complete: it covers what the tool does, what it returns, when to use it, and how it handles invalid input. No critical selection or invocation detail 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 the schema already describes program and allowInvalid. The description adds context about validation and publishing intent but not new parameter-level meaning; 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?

States a specific verb and resource: 'Publish a program as a live, shareable timeline' and tells exactly what is returned (URL, ASCII Gantt, itinerary). This distinguishes it from sibling tools like preview_timeline, validate_program, and analyze_schedule, since publishing/sharing is a distinct action.

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 a clear target scenario: 'For a schedule the user wants to follow or share', with concrete user phrasings ('plan this so it all finishes at 6'). It does not explicitly name alternatives or state when not to use the tool, 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.