DiscreteRate

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 safety profile is covered. The description adds behavioral context by specifying the content of the write-up (history, teachings, expected output), which explains what the user gets. This goes beyond the minimal annotation coverage.

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 filler. The first sentence front-loads the core purpose and content, the second gives usage context. 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 tool with one enum parameter, the description is complete: it explains what the tool returns, when to use it, and implicitly how it fits among siblings (run_*, explain_*, list_drs_demos). The rich annotations and full schema coverage leave no significant 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% for the single 'demo' parameter, including the enum and a pointer to list_drs_demos. The tool description does not add additional parameter-level semantics, so it stays at the baseline for well-documented schemas.

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 explicitly states it provides a 'full per-demo write-up' covering history, teachings, and expected run_* output, which clearly distinguishes it from sibling explain_* tools (conceptual) and run_* tools (simulation execution). The verb 'describe' matches both the tool name and the resource (demo).

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 direct usage guidance: 'Use this to ground the user before triggering a sim run, or to explain WHY the demo exists when the user asks a conceptual question about it.' This implies the contrast with run_* (for executing) and explain_* (for general concepts), and the schema's reference to list_drs_demos covers catalog lookup. No exclusions are needed.

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 safety is covered. The description adds the useful behavioral trait 'Deterministic text' and specifies that it returns a focused write-up, which tells the agent what kind of output to expect. This goes beyond the annotations without contradicting 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?

Three sentences, each earning its place: the first states the return value and content, the second gives the usage trigger, and the third notes determinism. It is front-loaded and free of 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?

Despite lacking an output schema, the description fully specifies what the tool returns (a focused write-up with exact numbers) and when to use it. For a no-parameter, read-only explanation tool, this is complete and actionable.

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 has zero parameters, so the baseline is 4. There is nothing to explain about inputs; the description still clarifies that the output includes the worked Fast-Slow Drain numbers, adding contextual meaning to the empty 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 uses a specific verb ('Return') and resource ('event-count complexity differences between DES and DRS') with concrete worked numbers (Continuous ~thousands vs DES ~500 vs DRS 10 events). This clearly distinguishes it from sibling tools like explain_discrete_rate_simulation or explain_three_primitives by focusing on the DES-vs-DRS 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?

The description explicitly says 'Use this when the user wants the practitioner-visible payoff of DRS', giving clear guidance on when to invoke. It does not name alternative sibling tools or state when not to use it, so it misses the full 'when-not/alternatives' bar, but the context is unambiguous.

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?

The description adds behavioral details beyond annotations: 'Deterministic text — no engine call, no RNG.' This tells the agent that the tool has no side effects, no randomness, and produces a stable textual output. Annotations already indicate read-only, idempotent, and non-destructive, but the deterministic and no-engine-call details are extra context. It does not contradict 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 three sentences, each serving a distinct purpose: (1) content scope, (2) usage context, (3) behavioral guarantee. It is front-loaded with the primary action and resource, and every sentence earns its place without fluff or 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?

Given the tool's simplicity (zero parameters, no output schema, read-only annotation), the description provides sufficient context: what it does, when to use it, and its deterministic behavior. It could mention the output format (e.g., plain text vs. markdown) but that is a minor gap. Overall, it is adequately complete for an AI 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?

The tool has zero parameters, and the input schema confirms an empty object. According to the rubric, 0 params gets a baseline of 4. The description does not need to explain parameter semantics since there are none, and it adds no misleading information.

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 with a specific verb ('Return') and resource ('textbook-tier explainer of Discrete Rate Simulation'). It enumerates the content areas (differences from DES/CT, three primitives, paradigm integration) and provides usage examples ('what is DRS?', 'how is this different from DES?'), which effectively distinguishes it from sibling tools that focus on deep-dive explanations of specific subtopics.

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 gives usage guidance: 'Use this for ... style questions' listing three concrete question types. This provides clear context for when the tool is appropriate. However, it does not mention when not to use it or name alternative sibling tools for more specialized queries, so it stops short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety and mutability profile. The description adds 'Deterministic text,' which reinforces the idempotent nature but does not introduce new behavioral details such as output structure or length. Some content context is added, but it's more about purpose than 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?

The description is two concise sentences. The first states the action and topic; the second gives explicit usage guidance. There is no redundancy or vague language—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?

For a zero-parameter, deterministic text explainer, the description sufficiently covers what it returns, when to use it, and the topic content. Annotations cover safety. There is no output schema, but the description's mention of 'explainer' and the specific content provides adequate context for a tool of this simplicity.

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?

This tool has zero parameters, so the schema is fully complete. The description does not need to explain parameter meanings, and the baseline for no-parameter tools is 4. There is nothing to add 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 clearly states the action ('Return an explainer') and the specific topic (paradigm integration via F2I/I2F primitives), which distinguishes it from sibling tools like explain_three_primitives and run_valdez_tanker. It includes a specific verb and resource, making the purpose 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?

It explicitly states when to use the tool: when the user asks about Valdez-Tanker-style mixed-paradigm systems or 'how do flows and items coexist'. This provides clear trigger conditions. It does not explicitly mention when not to use it or name alternatives, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'Deterministic text,' which is a useful behavioral trait beyond the annotations, indicating the output is stable and predictable. 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 two sentences, front-loaded with the primary function and immediate informative detail about the three primitives. Every sentence earns its place; 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 simple no-parameter explanation tool, the description fully specifies what it returns (write-up of three named primitives), when to use it (user asks about modeling primitives), and that it is deterministic. Annotations cover safety, and no output schema is needed for a text-returning tool. It is complete for its purpose.

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 has zero parameters, so the input schema is empty and there is no parameter semantics to explain. Baseline for 0 params is 4, and the description correctly focuses on the tool's content and usage rather than inventing parameter details.

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 returns a focused write-up of the three DRS modeling primitives, explicitly naming Constraint, Buffer, and Interrupt. This specific verb+resource distinguishes it from sibling explanation tools like explain_des_vs_drs_event_complexity or explain_discrete_rate_simulation.

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 an explicit usage condition: 'Use this when the user asks specifically about modeling primitives or how to spell a system in DRS.' This effectively tells the agent when to select this tool and implicitly when to consider alternatives among the explanation-focused 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about the contents (the seven demos) and their reproducibility, but does not disclose additional behavioral traits such as return format or pagination. Since annotations cover the main risks, a score of 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 highly concise, two sentences that immediately state the action and list the exact demos. It avoids fluff and front-loads the most critical information (what the tool does and when to use it).

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 zero-parameter discovery tool, the description is complete. It names all seven demos, explains how they relate to run_* tools, and provides usage guidance. Even without an output schema, the description clearly tells the user what they will get (a list of the seven named demos), so the tool is fully understandable.

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?

With zero parameters, the tool has no parameter information to clarify, and the baseline for parameter semantics is 4. The description focuses on the tool's purpose rather than parameters, which is sufficient given there are none.

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 ('List') and resource ('the seven DRS demos') with explicit names, making the tool's function unambiguous. It clearly distinguishes itself from sibling tools like describe_demo and run_* tools by focusing on discovery/listing rather than describing or executing.

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 'Use this to discover what's available before calling describe_demo or a run_* tool,' providing direct guidance on when to use it and naming the alternative tools it should precede. This is clear and actionable.

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 readOnlyHint and destructiveHint annotations, the description adds significant behavioral detail: it explicitly states that the tool runs a real Plant Builder engine and includes an anti-fabrication directive to quote numbers verbatim. It also discloses the internal system mechanics (DES schedules campaigns/injects failures, DRS solves continuous flow, bridge couples them), which the annotations do not cover.

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 efficiently structured: it opens with the primary action, follows with a concise breakdown of the three-system series, lists the specific return data, and ends with an important behavioral note. Every sentence adds value without redundancy, keeping the description compact yet comprehensive.

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 that there is no output schema and no parameters, the description carries the full burden of explaining what the tool returns and what it does. It thoroughly specifies the plant rollup metrics, per-product attainment, and per-system timelines, making it complete for an agent to decide on invocation and interpret results.

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?

With zero parameters in the schema, the baseline is 4 per the rubric. The description correctly implies that no inputs are needed and does not need to add parameter details. It also indirectly confirms this by focusing entirely on the run and its outputs.

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 verb 'Run' and the target resource 'Chocolate Processing (CHOC) demo', distinguishing it from sibling run_* tools by detailing the DES↔DRS bridge topology and its three-system series. It also enumerates the specific outputs, leaving no ambiguity about what the tool does.

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 clear context by explaining the demo's focus on the joint DES↔DRS bridge and that it exercises all 7 controllers + Goal blocks, which implies when to use this tool (when a comprehensive chocolate process demo is needed). However, it does not explicitly name alternatives or state when not to use it, 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 mark this as read-only and non-destructive, and the description adds important behavioral context: it returns engine output with event counts, tank-level trace, and cycle summary. The ANTI-FABRICATION note telling the agent to quote verbatim and not recall from training data is a valuable disclosure beyond the 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 compact: two main sentences plus a brief anti-fabrication note. It front-loads the core purpose and returns structure without waste. Every sentence earns its place, including the critical anti-fabrication instruction.

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 compensates by listing return components (event counts, tank-level trace, cycle summary). Given the tool's moderate complexity and strong annotations, the description provides sufficient context. It doesn't mention the parameter but the schema handles that.

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% for the single simulation_minutes parameter, which already includes default and range. The description adds no parameter-specific detail, but the schema fully covers it, 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 clearly states the tool runs the Fast-Slow Drain (FSD) demo with a specific citation (Damiron-Nastasi 2008) and identifies its purpose as the canonical DRS-vs-DES event-count demonstration. This specific verb+resource combination distinguishes it from sibling demo tools like run_hamburger_duo or run_valdez_tanker.

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 implies when to use the tool: when you need the canonical demonstration comparing DRS and DES event counts. While it doesn't explicitly name alternatives or exclusion criteria, the context is strong enough to guide selection among sibling run_* tools.

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?

The description adds useful behavioral context beyond the annotations: it returns engine output for the side-by-side run and warns that numbers come from a real engine run and must be quoted verbatim. This complements the readOnly and non-destructive hints without contradicting 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?

The description is compact and front-loaded: the first sentence conveys the core purpose, the second states the return value, and the third provides a critical anti-fabrication warning. Every sentence earns its place with no redundancy or 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?

Given the tool's simple interface (one optional parameter fully documented in the schema) and the presence of annotations, the description is mostly complete. It states what is run, why, what is returned, and the quoting requirement, though it does not detail the output format in the absence of an output schema.

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

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

Schema coverage is 100% because the sole parameter, simulation_days, has a full description including default, range, and meaning. The tool description adds no parameter-specific information, but the schema carries the entire semantic load, 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 states the specific action ('Run the Hamburger Duo (HAM) demo') and identifies the unique resource: Andy Siprelle's 5-stage finite-source line, with both DES and DRS implementations. It clearly distinguishes this from sibling run_* demos by naming the specific demo and its dual-implementation purpose.

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 when to use the tool: when you need to compare event-count and throughput numbers between DES and DRS implementations on the same model. However, it does not explicitly mention alternatives or when not to use it, leaving the usage guidance implicit 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 declare readOnlyHint=true and openWorldHint=true, which the description complements by emphasizing that output is a live experiment, not a verified reference, and by instructing users to quote figures verbatim. This adds important context about the output's nature and variability beyond the annotations, though it does not contradict 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?

The description is a dense but well-structured paragraph that front-loads the key message ('LIVE EXPERIMENT') and uses clear formatting (caps, bold) to highlight critical warnings. Every sentence adds value, though it is somewhat longer than strictly necessary; the structure makes it scannable.

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 absence of an output schema, the description adequately explains what the tool returns (run envelope with metadata, execution stats, metrics, details) and how to interpret it. It also covers the essential distinction from reference tools and provides presentation guidance, making it sufficiently complete for the tool's complexity.

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

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

The input schema covers both parameters thoroughly (100% coverage), including per-demo knob ranges and validation behavior. The description adds examples ('stop_time', MTBF/MTTR knobs) but these are already present in the schema's knob description, so the description provides little additional semantic value beyond emphasizing the 'live' aspect.

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 live experiment runner for DRS demos, explicitly stating it returns a 'verbatim run envelope' and is 'the only tool that COMPUTES fresh output.' It distinguishes itself from sibling run_* tools that return curated reference values, making the purpose 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?

The description provides explicit when-to-use guidance: use when you want live, parameterized results from the real engine, not verified reference numbers. It names the alternative run_* tools that return curated canonical values and warns strongly not to blend outputs, making the usage context clear.

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 and destructiveHint=false, and the description adds meaningful behavioral context: a single 5-machine line run, per-SKU returns (OEE ~55%, indexed output swings, pacing machine), and the anti-fabrication directive to quote verbatim because numbers are anonymized from a real engine run. This goes beyond the annotations without contradiction.

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 uses three sentences to pack essential details: the demo setup, the return shape, and the anti-fabrication instruction. Every sentence adds value, but it is slightly longer than the minimal two-sentence ideal.

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?

Without an output schema, the description fully covers return values (per-SKU OEE, indexed real output with example numbers, pacing machine) and the interpretive takeaway. It also addresses the openWorldHint by stressing that numbers from the sim-foundation run must be quoted verbatim. This is complete for a zero-parameter demo tool.

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 per the rubric. There are no parameter details to document; the schema is empty, and the description correctly omits any parameter information.

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: 'Run the Bottling Line / SKU-capacity (SKU) demo'. It specifically distinguishes this tool from sibling run_* demos by naming the exact demo and its teaching point. It also outlines the return values, making the purpose 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?

The description implies when to use the tool — to demonstrate that per-SKU capacity cannot be read off OEE — but it never explicitly contrasts it with sibling tools like run_chocolate_processing or provides when-not-to-use guidance. The context is enough to infer usage but without explicit 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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds beyond these by detailing the exact return values (throughput percentages, binding bottleneck, converter/storage detail) and includes an explicit anti-fabrication directive ('quote verbatim'), which is a valuable behavioral caveat.

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 moderately detailed but every sentence adds value: line composition, decision set, output specification, interpretive insight, and a data-source warning. It is front-loaded with the action verb and specific percentages, though slightly longer than strictly necessary.

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 there is no input schema (0 parameters) and no output schema, the description fully covers the tool's behavior: it states what is returned (throughput percentages, bottleneck, detail) and includes a behavioral rule. This makes it self-contained for a demo tool.

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?

With zero parameters, the baseline is 4. The description clarifies that the three 'strategic decisions' are internal scenarios, not inputs, and the empty schema requires no additional 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 opens with 'Run the Tissue Line (TIS) demo' — a specific verb and resource. It further specifies the line configuration (Reel supply → Converter → Winder) and the three strategic decisions, distinguishing it from sibling demo tools like run_chocolate_processing or run_valdez_tanker.

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 identifies the demo's focus ('sim-foundation parameter-set example') and describes the decision scenarios. The concluding insight ('invest at the constraint') suggests when this tool is pedagogically useful, but there is no explicit statement of when to use this over other run_* 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?

Beyond the annotations (readOnlyHint, etc.), the description adds crucial behavioral details: outputs include tanker events and tank-level trace, and the anti-fabrication warning that numbers come from a real engine run and must be quoted verbatim. This significantly exceeds structured data.

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 and well-structured: it names the tool, explains the simulation model, describes the return value, and adds the anti-fabrication note. Each sentence has a distinct purpose with 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?

Despite having no output schema, the description specifies what is returned (tanker events, tank-level trace). It also provides the model's historical/contextual significance and the simulation's hybrid nature. This is complete for a complex demo tool with good annotations.

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 full documentation for the single parameter 'simulation_days' (default, min, max, description). The description adds no additional parameter context or semantics, which is acceptable given 100% schema coverage.

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 action: 'Run the Valdez Tanker (VALD) demo' and identifies the specific model (Koelling-Remy 1983 Alaska Pipeline). This distinguishes it from sibling run_* tools by naming the unique demo and its role.

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 about what the demo models (continuous flow, discrete arrivals, F2I/I2F transitions) and its purpose as the 'paradigm-integration motivator', implying when it would be relevant. However, it does not explicitly contrast with other run_* tools or state when not to use 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?

The description adds behavioral context beyond the annotations by explaining the internal model and the DRS solver that splits and rebalances flow. It also includes an ANTI-FABRICATION note stating that numbers come from a real Plant Builder engine run and should be quoted verbatim, which is useful behavioral guidance. The readOnlyHint and destructiveHint annotations are consistent with the description, so no contradiction exists.

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, front-loaded with the core action and model context. It efficiently covers the model architecture, expected returns, and the anti-fabrication note. No redundant or filler content is present.

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 lack of an output schema, the description compensates by listing the return values (plant rollup, per-product goal attainment, campaign timelines, surge-bin/delivered levels). It also provides enough context about the model and its operation. The description is sufficiently complete for a demo-run tool, especially with annotations covering safety traits.

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 has zero parameters and the schema coverage is 100% (empty object). Per the rubric, a 0-parameter tool receives a baseline score of 4. The description adds no parameter-specific semantics because there are none to describe.

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: "Run the Vegetable Plant (VEG) demo," and specifies it is a Plant Builder distribution-control model. It provides enough detail (two Making lines, five Packing lines, eight surge bins, DRS solver) to distinguish it from sibling demo-run 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 implies when to use the tool: when you need to run the VEG demo. However, it does not explicitly state when to use this tool over alternatives like run_chocolate_processing or run_tissue_line, nor does it provide any exclusions. This is implied usage, not explicit guidance.

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