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

Annotations already declare readOnly/idempotent/non-destructive, and 'Pure computation' reinforces that this mutates nothing. It also discloses the conditional behavior that predictions only occur when history or program_id is supplied. It adds no auth or rate-limit context, but the annotation burden is light here.

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?

Front-loads the core output list, then adds the finishAt scenario and the prediction condition. Dense but every sentence carries information; the colon-list style is efficient rather than padded.

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 need not be explained, and the schema plus the rhylthyme://guide/tools pointer cover the nested predictionContext. For an 8-parameter tool with only one required arg, the description supplies enough 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?

Schema coverage is 100% so the baseline is 3, but the description genuinely adds meaning: finishAt is framed as the reverse-scheduling input and it clarifies that program_id pulls the user's own recorded runs as history. That goes beyond restating 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?

States a specific verb (analyze) and enumerates the concrete outputs: per-step start/end, total length, critical path and its gates, resource conflicts, slack per track. That output list clearly separates it from visualize_schedule and preview_timeline, which render rather than compute timing.

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 usage scenario for finishAt ('when do I start X so everything is ready at 6pm?') and states that history/program_id unlocks predicted durations. It never names an alternative sibling or an explicit when-not, so it falls short of a 5.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real context beyond them: account prerequisites for import/random/benchling, the parallel-track behavior of enrich, and a daily model-call cap. That rate-limit and auth detail is the kind of thing annotations cannot express.

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?

Purpose is front-loaded and the remaining lines are dense, telegraphic clauses that each carry information (sources, actions, auth, enrich). No filler, though the clipped phrasing occasionally forces re-reading.

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 tool with no output schema, it covers sources, actions, account requirements, enrich semantics, and states the return value ("Returns the program"). Minor gaps remain around the text-paste path and how it relates to the import_text/load_program siblings.

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 description meaningfully supplements the schema by mapping each source to its domain, defining what query means per action, and explaining enrich's parallel-track behavior. The token parameter's usage (omit when connected) is left mostly to the schema, keeping it below 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?

Opens with a specific verb and resource set ("Import a recipe, protocol or run of show into a program") and then enumerates the valid sources grouped by domain. It does not explicitly distinguish itself from close siblings like import_text, load_program, or load_public_recipe, so a 4 rather than a 5.

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 conditional guidance per action (search needs no account, import takes a URL or id, random) and names which paths require the Rhylthyme account. It stops short of naming sibling alternatives for each case, so it is clear context without explicit exclusions.

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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds two pieces of context not in the structured data: the public/unauthenticated access model and the returned fields (ids, names, descriptions, URLs). It does not cover pagination or result-count 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, zero filler. The purpose and scope lead, and the access/return information follows compactly.

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 an output schema present, the description needn't explain return values, and annotations carry the safety profile, so what remains (purpose, scope, auth model, catalog mapping) is covered. Minor gap: no mention of how limit/pagination behaves or how empty-query results are ordered, though the schema notes the latter.

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%, so baseline is 3, and the description goes slightly beyond it: the four catalog content types named map onto the environment enum values (kitchen, laboratory, event, gym), clarifying what each enum branch actually searches. It still doesn't explain limit bounds, which the schema carries.

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 (Search) and resource (public catalog of recipes, lab protocols, event templates, workouts) with the matching scope (by name or keyword). An agent can distinguish this from load_public_recipe (loads one item) and list_public_runs (different resource) without opening 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?

'No account needed' tells the agent this is usable pre-authentication, which is genuinely useful routing context versus login-gated siblings. However, it never states when to use this search versus load_public_recipe or the list_* tools, so the when-to-use guidance remains 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, 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?

Annotations already declare the write/external/irreversible profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=true); the description adds real value on top by disclosing that publication creates a public share link, that validation runs first and refuses invalid programs with fix hints, and what the payload contains. It does not cover link permanence/revocation or re-publish behavior, which is the main residual 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?

Front-loads the verb, resource and public-share constraint in the first clause, then adds usage cues and the validation gate. Two sentences with quoted examples are efficient, though the stacked parentheticals ('a public share link') and example list make it slightly denser than needed.

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?

Covers purpose, side effect, validation behavior and usage context, and an output schema exists so return values need not be spelled out. Combined with annotations that carry the destructive/open-world profile, an agent has what it needs to decide and invoke 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%, with 'program' and 'allowInvalid' both documented (including the 'only when the user explicitly wants an imperfect draft shared' caveat), so the baseline is 3. The description's 'validates first and refuses an invalid program' lightly reinforces the allowInvalid semantics but adds no format or shape detail beyond the schema pointer to validate_program.

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 (a public share link)' — plus what it returns (URL, ASCII Gantt, itinerary). The 'public share link' framing implicitly separates it from local-render siblings like preview_timeline, but no sibling is named explicitly, so it stops short of a 5.

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 clear when-to-use cue with concrete user phrasings ('plan this so it all finishes at 6', 'when do I start each thing'), tying the tool to shareable/followed schedules. It never states when NOT to use it or names the alternative (preview_timeline, analyze_schedule) for non-published inspection, so it falls short of explicit routing.

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