ReliaSim

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

With no annotations, the description carries the full burden. It discloses that output is sim-derived with no interpretation drift, includes a strong anti-fabrication statement that deltas are computed and not estimated, and instructs to quote verbatim. This gives the agent critical behavioral guardrails.

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 information-dense with no filler. Each sentence serves a distinct purpose (definition, output nature, usage, anti-fabrication) and it is front-loaded with the core purpose. The length is justified by the critical content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (comparison of multiple metrics) and lack of output schema, the description provides everything needed: what it compares, that output is sim-derived, when to use it, and how to handle numbers. The schema covers parameter selection. No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100% with both parameters having descriptions and enums. The tool description adds context about what the comparison includes but does not further explain the parameter meanings. The schema already does the heavy lifting, so 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?

The description states the specific verb 'comparison' and the resource 'two chapters', listing the compared aspects (tracks, topology, OEE, throughput, headline bottleneck). This clearly distinguishes it from siblings like get_chapter_facts (single chapter) or explain_concept (concept discussion).

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 three explicit usage scenarios ('how does X compare to Y?', 'what's the difference between Constraint-Level and LEDS-Level?', 'what changes when we add buffers?'), which gives clear context. However, it does not include explicit when-not-to-use or alternative tool names, 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?

With no annotations provided, the description carries the transparency burden. It clearly discloses that output is 'bundled theory content, NOT interpretation of any specific simulation run,' which manages expectations about the tool's behavior. It lacks details on output format or side effects, but for a read-only conceptual explainer, this is sufficient.

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, highly efficient. It front-loads the core purpose, lists supported concepts, clarifies what it does NOT do, gives explicit usage scenarios, and points to alternatives. No wasted words.

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 simplicity (one enum parameter, no output schema), the description fully covers purpose, scope, exclusions, and alternative tools. It is complete for an agent to select and invoke the 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 input schema already provides 100% coverage including an enum and detailed description for the 'concept' parameter. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score 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?

Description states it is a 'Definitional primer' for specific framework concepts, with a clear verb ('explains') and resource (ReliaSim's framework concepts). It explicitly differentiates from sibling sim tools by clarifying it returns theory content, not simulation interpretation, making tool selection unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage context: 'Use for "what is X?" / "how does X work?" / "explain the framework" questions.' Also gives a clear exclusion and alternative: 'NOT interpretation of any specific simulation run' and 'For line-specific claims... call the sim tools instead.' This is textbook when/when-not 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?

With no annotations, the description carries the full burden. It discloses the critical behavioral trait that numbers are canonical reference values from real dys-cli runs, mandates verbatim quoting and forbids rounding/estimating, and clarifies that all eight chapters return verified numbers. This gives the agent strong ground truth expectations beyond what the schema provides.

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 front-loaded with the purpose and includes essential usage/anti-fabrication notes. It could be slightly more concise, but each sentence earns its place, especially the anti-fabrication instruction, which is critical for correct use.

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 low complexity (one parameter, no output schema), the description is quite complete: it explains what will be returned, emphasizes data provenance, and advises about follow-ups. It lacks information on return format/units, but the metrics are named, and the tool's simplicity does not require much more.

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 fully describes the 'chapter' parameter with enum values and formatting details. The description adds only generic context ('selected chapter') and does not deepen parameter semantics beyond the schema, so 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?

The description states a specific action ('bottleneck analysis') on a specific resource ('selected chapter') and lists concrete output metrics (availability, downtime split, throughput, OEE). It distinguishes from sibling tools by emphasizing 'Single Run' and per-chapter focus, making its purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates when to use: for single-chapter bottleneck analysis, and explicitly says to re-call this tool for follow-ups about the same chapter. However, it does not mention when not to use it (e.g., for cross-chapter comparison) or name alternative tools, so no explicit exclusions/alternatives.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a critical anti-fabrication behavior: rates/distributions are verified .aidos-file values and must be quoted verbatim, not estimated or replaced with training-data recall. This adds important context beyond a simple read operation.

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 concise (three sentences) and front-loaded: purpose, usage, and a critical behavioral rule. Every sentence adds value with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, no-output-schema tool, the description provides sufficient context: what facts are returned, when to use it, and how to handle the data (verbatim quoting). It is complete for its complexity and differentiates well from 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?

The input schema already provides 100% coverage of the 'chapter' parameter, including enum values, format, default, and the ct vs leds distinction. The tool description does not add any additional parameter-specific meaning beyond referring to the 'selected chapter,' so it stays at the baseline.

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 specifies the tool's function: returning structural facts (topology, rate limits, interrupt distributions, expected efficiency) for the selected chapter. It distinguishes from siblings like get_chapter_narrative by focusing on structural/configuration data rather than narrative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the usage trigger: 'Use when the user asks about the line's configuration.' It provides clear context but does not mention exclusions or alternatives, stopping short of a full when/when-not contrast.

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?

With no annotations provided, the description carries the full burden. It discloses that the output is 'pure prose' and that it is 'safe to summarize,' which addresses the output format and safety profile. It does not detail potential permissions or error scenarios, but for a read-only narrative tool this is reasonable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: purpose, usage trigger, and behavioral note. It is front-loaded and free of filler, making it easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description is sufficiently complete: it covers what the tool does, when to use it, and what the output will be. It could arguably mention whether the narrative can be generated for all chapters or if there are rate limits, but nothing suggests a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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

Schema coverage is 100%, with the single 'chapter' parameter fully documented (enum, default, format, and ct/leds distinction). The description adds no extra parameter information, 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 clearly states the tool's function: providing a 'long-form narrative' for a selected chapter, including what it adds to the complexity ladder and the key teaching point. This specific verb+resource pairing distinguishes it from siblings like get_chapter_facts (facts) and run_gain_loss (numerical analysis) through the 'pure prose, no numerical claims' contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use it: when the user asks 'walk me through this' or wants a conceptual primer. It also notes the tool is not for numerical claims, providing a when-not, but it does not name alternatives explicitly, so it falls just short of the highest score.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It goes beyond the basics by disclosing the sweep range (50→10,000 units), the per-chapter buffer mapping (three inline buffers with different placements), the constraint to bs4-* chapters, and the anti-fabrication rule that specific tradeoff numbers must be quoted verbatim and not recalled from training data. This is rich, safety-relevant context that structured fields do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph that front-loads the core purpose (sweep and measure) before diving into constraints and use cases. Every sentence earns its place: the sweep range, the chapter restriction, the buffer mapping, the comparison strategy, the trigger phrases, and the critical anti-fabrication warning. There is no fluff or repetition of schema descriptions.

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?

There is no output schema, so the description must explain what to expect from the tool. It mentions 'measure throughput gain' and 'Shows the diminishing-returns elbow,' and provides example percentages. It could be more explicit about the exact return structure (e.g., a table of capacities vs gains or a summary object), which is a minor gap. Overall, given the complexity and constraints, the coverage is strong.

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% for both parameters, so the baseline is 3. However, the description adds substantial semantic value: it defines the sweep range, explains how to pick the right buffer id based on the question ('the first inline buffer' = b3 on CT, b2 on LEDS), provides a concrete example (b3: CT +23.7% vs LEDS +64.2%), and warns that every buffer position has different math. This significantly enriches the parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Buffer Tradeoff experiment — sweep a buffer's capacity from 50 → 10,000 units, measure throughput gain.' This is a specific verb+resource+outcome, clearly distinguishing the tool from siblings like run_gain_loss or run_showcase by focusing on buffer-capacity sweeps and diminishing returns. It also names the exact output (throughput gain) and the scoop (diminishing-returns elbow), making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists trigger phrases: 'how big should the buffer be?', 'do buffers help on this line?', 'which buffer position gives the most gain?', and 'what's the diminishing-returns point?'. It also specifies valid chapters ('Only defined on bs4-ct and bs4-leds') and gives a comparison strategy (CT vs LEDS). However, it does not explicitly name alternative tools or state when NOT to use it, which would merit 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?

With no annotations, the description carries the full burden. It goes well beyond basic disclosure by explaining the counterintuitive Gain ≠ Loss interaction, emphasizing that numbers come from real dys-cli runs, and warning against fabrication ('ANTI-FABRICATION... Quote VERBATIM'). This gives the agent essential behavioral 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 well-structured with clear sections (purpose, availability, usage, anti-fabrication). Though longer than two sentences, every sentence adds value and the content is tightly packed without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description covers all necessary aspects: what it does, the key insight, when to use it, where it applies, and a critical caution about fabrication. It leaves no significant gaps for an agent to operate 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 provides a detailed description of the `chapter` parameter (100% coverage). The description adds important context by noting availability is restricted to four specific chapters (`bs1-leds`, `bs3-leds`, `bs4-ct`, `bs4-leds`), which is not obvious from the enum alone, giving extra semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'disable each interrupt one at a time, measure production recovered.' It also distinguishes itself from siblings by explaining the Gain ≠ Loss concept and specifying the exact use cases ('what if we fixed X?', 'which interrupt matters most if we actually fixed it?', 'show me the Pareto'), making it unique among the sibling tools.

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?

Explicit when-to-use guidance is provided: 'Use when the user asks...' and specific chapter availability is stated. However, it does not mention alternative tools or explicit when-not-to-use scenarios, so it stops 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?

With no annotations provided, the description fully discloses behavioral traits: it is a live experiment, output is not a verified reference, should not be blended with curated numbers, and figures must be quoted verbatim. These details go well beyond the schema and inform the agent about the nature and limitations of the tool.

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 substantial but every sentence earns its place: it defines the tool, states its unique compute nature, delivers a critical warning about non-canonical status, and offers alternative tools. The IMPORTANT marker structures the warning clearly, with no redundant or filler 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 tool with no output schema, the description adequately explains the return envelope categories (metadata, execution stats, metrics, details) and the experimental nature. It covers the essential use case, limitations, and alternatives. Sibling tools are clearly distinguished, making the description complete for an agent to select 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%, so the baseline is 3. The description adds context about using duration_days universally and buffer capacities on bs4 demos, but this information is already present in the knobs object's schema. No additional semantic value beyond emphasizing the live configuration.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'run a bottling-line demo against the real ReliaSim engine' and get its 'verbatim run envelope'. It explicitly differentiates from siblings by claiming it is the only tool that COMPUTES fresh output, contrasting with curated reference tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use and when-not-to-use guidance. It warns that run_showcase results are not verified reference numbers, instructs labeling as experiment results, and directs users to find_bottleneck / run_gain_loss / run_buffer_tradeoff for canonical values. Also specifies to quote figures verbatim and not to derive.

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