ReliaSim

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so excellently. It states that output is sim-derived with no interpretation drift, clarifies that per-chapter values are real reference values, and explains that the delta is computed rather than estimated. The explicit 'Quote VERBATIM' instruction also guides output fidelity.

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 compact and front-loaded: purpose, output nature, example usage, and anti-fabrication guidance all appear in a short, high-signal paragraph. Every sentence adds value, and the 'Quote VERBATIM' instruction reinforces the most important behavior without being 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?

Despite having no output schema and no annotations, the description is complete for a low-complexity tool with two enum parameters. It names the comparison metrics, clarifies that results are simulation-derived and non-interpreted, and provides example questions that map directly to likely user intents. An agent has enough information 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?

Schema description coverage is 100%, so the input schema already documents both chapter_a and chapter_b, including defaults and an especially detailed explanation for chapter_b. The description itself does not add parameter-level meaning beyond the schema, which is acceptable given the high schema coverage. The default baseline of 3 is appropriate here.

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 purpose: side-by-side comparison of two chapters with specific metrics like tracks, topology, OEE, throughput, and headline bottleneck. It also gives concrete example questions, which helps an agent understand what the tool is for. However, it does not explicitly differentiate from sibling tools such as run_gain_loss or run_buffer_tradeoff, so it stops short of full sibling 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 provides explicit use cases: comparison questions, Constraint-Level vs LEDS-Level differences, and buffer-addition changes. It does not mention when not to use this tool or name alternatives from the sibling list, so exclusions and alternative routing are absent. Still, the context is clear enough for an agent to identify the appropriate scenario.

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 behavioral burden and does meaningful work: it declares that all chapters return verified dys-cli sales-prototype numbers and adds an anti-fabrication rule to quote verbatim, not round, estimate, or recall from training data. It also exposes the re-call behavior for repeat questions. It does not discuss side effects, but this is an analysis tool and none are implied.

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 core purpose is front-loaded and the anti-fabrication warning is placed close behind it, so the most important selection info appears first. The only waste is the slight redundancy between 'All eight chapters return verified numbers' and the longer ANTI-FABRICATION 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 one-parameter tool with a descriptive schema and no output schema, the description gives the response contents and post-call behavior, which is mostly sufficient. But it says 'All eight chapters' while the schema enumerates ten valid chapters. The schema also claims format bs<1-5> while only bs1-4 plus two cmp- values are present. That inconsistency leaves the agent slightly unsure about the full valid scope.

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 chapter parameter's enum, default, and format are already fully documented. The description only refers to 'the selected chapter' and 'all eight chapters', adding little 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 a concrete action and object: 'Single Run bottleneck analysis for the selected chapter' and lists the exact metrics returned (availability, downtime split, throughput, OEE). It is clear about what find_bottleneck does, though it does not explicitly differentiate it from sibling tools such as compare_chapters or run_gain_loss.

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 establishes that the tool targets one selected chapter and instructs users to re-call it for follow-ups on the same chapter, so the context of use is implied. However, it never states when not to use it or mentions an alternative sibling, leaving routing guidance 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?

With no annotations, the description carries the behavioral burden and does so strongly. It states values are verified .aidos-file values, requires verbatim quoting, and explicitly forbids estimation or training-data recall. This materially shapes how the agent should source and present the returned facts.

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 tight sentences front-load the core purpose, then add the usage trigger, then the anti-fabrication constraint. No wasted words; 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?

The tool has a single optional parameter with a fully documented schema, no annotations, and no output schema. The description supplies enough operational context: what facts are returned, when to call it, and how to handle the output (verbatim quoting). Nothing critical is missing 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%, so the schema fully documents the chapter parameter, including enum values, default, format, and the ct/leds distinction. The description adds only the generic phrase 'selected chapter', which does not improve on the schema's explanation.

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 identifies the resource ('structural facts of the selected chapter') and enumerates the content: topology, rate limits, interrupt distributions, and expected efficiency. It does not use an explicit action verb like 'retrieves' or 'returns', but the tool name and 'Use when...' make the operation clear. It distinguishes this from sibling narrative/explanation tools implicitly via 'structural facts' and 'configuration'.

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 specific trigger: use when the user asks about the line's configuration. It does not explicitly name sibling tools as alternatives or state when not to use it, so it stops short of a 5, but the trigger is concrete and scoped enough for an agent to select 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?

With no annotations provided, the description itself discloses important behavior: the output is 'pure prose' and makes 'no numerical claims,' which tells the agent what to expect and avoid in the response. The phrase 'safe to summarize' adds a light safety/read-only signal, though it is somewhat ambiguous compared to an explicit read-only statement.

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 and front-loads the core purpose before giving usage guidance. Every clause earns its place: what the tool returns, how the user might ask for it, output style, and a safety hint.

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 tool with one optional parameter and full schema coverage, the description provides sufficient context about content, format, and usage triggers. It does not describe return structure or pagination, but the 'long-form narrative' phrase makes the expected output clear enough, and no output schema exists to carry that burden.

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 schema already explains the chapter enum, the ct/leds distinction, defaults, and fallback behavior. The description references 'the selected chapter' but adds no parameter-level meaning beyond what the schema provides, so the 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?

The description opens with 'Long-form narrative for the selected chapter — what the chapter adds to the complexity ladder and the key teaching point,' which clearly identifies the specific verb, resource, and content scope. It distinguishes itself from siblings like get_chapter_facts and explain_concept by framing the output as a conceptual narrative rather than facts or a standalone explanation.

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 says to use it when the user asks 'walk me through this' or wants a 'conceptual primer,' providing clear context for when this tool is appropriate. It does not explicitly state when not to use it or name alternative tools, but the usage triggers are concrete enough to route an agent correctly.

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 and does so well: it discloses the sweep range, the measured output, the chapter limitation, and a critical anti-fabrication rule that tradeoff numbers are sweep-derived reference values to quote verbatim. This is especially valuable for preventing hallucinated percentages.

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 dense but every sentence earns its place: action, scope, comparison pattern, trigger questions, and critical warning. The anti-fabrication note is appropriately emphasized and placed at the end where it reinforces the output handling without distracting from the core purpose.

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 no output schema, the description tells the agent what the sweep does, what it returns (throughput gain/percentages), which chapters support it, and how to handle the returned numbers. An agent has enough context 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?

Schema description coverage is 100%, so the baseline is 3. The description adds useful context beyond the schema by explaining that the buffer id selects among three inline buffers with different placements and gives a concrete CT vs LEDS example (b3) to anchor the parameter's meaning.

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 clear verb and resource: 'sweep a buffer's capacity from 50 → 10,000 units, measure throughput gain.' It names the specific output ('diminishing-returns elbow') and the scope ('Only defined on bs4-ct and bs4-leds'), making it easy to distinguish from generic chapter 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?

It provides explicit trigger phrasings ('how big should the buffer be?', 'do buffers help on this line?', 'which buffer position gives the most gain?', 'what's the diminishing-returns point?') and a clear scope exclusion: 'Only defined on bs4-ct and bs4-leds.' This gives the agent both when-to-use and when-not-to-use signals.

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 behavioral disclosure burden. It usefully reveals the Gain ≠ Loss interaction, states that numbers come from real dys-cli runs, and warns against fabricating figures. It doesn't discuss side effects or output shape, but the provenance warning is valuable 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 compact and well structured: definition, key interaction, availability, usage triggers, and a critical anti-fabrication warning. Every sentence earns its place and the most important information 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?

For a single-parameter tool with no output schema, the description covers purpose, use cases, and data provenance reasonably well. The conflicting availability list, especially excluding the schema default, leaves an unresolved ambiguity that prevents the description from being fully dependable for 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?

The schema already documents the `chapter` parameter fully, so the baseline is 3. However, the description's 'Available on' list contradicts the schema: it omits the default `bs1-ct` while the enum includes many values not listed. This conflicting guidance hurts rather than helps parameter interpretation.

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 identifies the tool as a Gain/Loss experiment that disables interrupts one at a time and measures recovered production. It also highlights the Gain ≠ Loss interaction, which distinguishes it from ordinary bottleneck or explanation 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?

The description gives concrete 'Use when' triggers with user phrasing and a list of applicable chapters. It does not name an alternative sibling tool or explicitly say when not to use it, but the usage context is clear enough for an agent to select it.

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