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

The description adds a useful behavioral detail—removal of the workdir if the server created it—which goes beyond a mere 'close' verb. However, with no annotations, it does not disclose whether the operation is reversible, what happens to unsaved data, or whether calling it on an already-closed session is safe.

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

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

The description is a single sentence of 11 words, front-loaded with the primary action. Every word earns its place, and it is appropriately sized for the tool's simplicity.

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 session lifecycle context and lack of annotations, the description omits critical information: the meaning of the 'name' parameter, when to invoke this tool vs. sibling session tools, and the consequences of disposal. The presence of an output schema does not compensate for these 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?

The sole parameter 'name' is entirely undocumented. The schema shows only its type (string or null) with a default of null, and the description does not mention it. With 0% schema description coverage, the description fails to clarify whether 'name' identifies the session or something else.

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 'Dispose the engine, removing the workdir if the server created it' clearly identifies this as a session teardown operation. It distinguishes the tool from siblings like ampl_init_session (creation), ampl_use_session (selection), and ampl_restart_session (restart).

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 offers no explicit guidance on when to use this tool versus alternatives. It does not state that it should be called when finished with a session, nor does it exclude usage during active work or mention any prerequisites.

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?

No annotations are provided, so the description carries the full burden. It discloses what the tool outputs (status, message, violated constraints) but does not mention whether it is read-only, how it handles sessions, or any side effects. This leaves some ambiguity.

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 long, front-loaded with the purpose, and contains no filler. Every word adds value.

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 is simple, and an output schema exists to document return values. The description explains the core function and when to use it. However, it omits any mention of the session parameter and any potential dependency on a prior solve, so it is not fully complete.

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 has one optional 'session' parameter, but the description never mentions it. With schema description coverage at 0%, the description provides no parameter guidance. The param name is somewhat self-explanatory, but the description fails to compensate for the lack of schema 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 'Explain the last solve: status, message, and violated constraints', using a specific verb and resource. This distinguishes it from sibling tools like ampl_solve or ampl_display, which have different functions.

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 says 'Call this after an infeasible or unbounded result rather than guessing at the model', providing clear when-to-use guidance and an exclusion (don't guess). This is direct 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?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly warns that file-loading statements are permitted but executed WITHOUT guard-checking, and that AMPL output redirection is not confined to the session working directory. It also clarifies the path guard scope, which is critical safety-relevant context. These disclosures go well beyond what any annotation would typically 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 compact and well-structured: one clear opening sentence followed by two focused paragraphs of essential warnings. Every sentence adds value, and the text avoids repetition or unnecessary elaboration. The security caveats are important and are presented succinctly without padding.

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 description covers the key behavioral risks (file loading, output redirection, guard scope) and mentions the warnings list in the result. With an output schema present, return values do not need explanation. However, the description lacks guidance on when to use the tool and does not explain parameter semantics, leaving some contextual gaps for an agent to operate effectively.

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

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

The input schema provides zero description coverage for the three parameters, so the description must compensate. However, the description only mentions 'expr' indirectly in the context of file-loading warnings and does not explain the meaning, format, or expected values of 'expr', 'limit', or 'session'. This is insufficient for agents to construct correct parameter values, especially for 'limit' and 'session'.

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+resource statement: 'Evaluate an arbitrary AMPL display expression.' The phrase 'reach-anything tool' signals broad scope. However, it does not explicitly differentiate itself from the sibling tool ampl_eval, which likely also evaluates AMPL expressions, leaving some ambiguity about when to choose this specific tool.

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

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

Usage context is only implied through phrases like 'reach-anything tool' and the warnings about file-loading and output redirection. There is no explicit statement of when to use this tool versus alternatives (e.g., ampl_eval, ampl_read_files), nor any 'do not use when' exclusions. The behavioral note about guard-checking suggests this tool is for powerful but risky operations, but that guidance is not made 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?

With no annotations, the description fully carries the burden and does so thoroughly. It discloses failure semantics, empty-input handling, file-loading behavior, and the important safety caveat that loaded files are executed without guard-checking. This is exactly the kind of behavioral nuance an agent needs.

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 despite its length; every sentence provides necessary operational or safety information. It front-loads the core purpose, then layers in examples and caveats in a logical order without 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 complexity and lack of annotations, the description covers most critical contexts: execution order, error handling, input validation, and unsafe file loading. The only notable omission is how the `session` parameter is resolved (e.g., default vs. explicit), but the output schema likely mitigates some of this.

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 description gives substantial semantics for `statements`, including non-empty requirements and the argument_error for whitespace-only input, which goes beyond the schema. However, the optional `session` parameter is never mentioned, leaving a gap in parameter understanding for a tool with 0% schema description 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 opens with a specific verb and resource: 'Run AMPL statements in order, returning per-statement output and errors.' This clearly distinguishes ampl_eval from siblings like ampl_solve or ampl_display, which target narrower operations.

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 for how to use the tool: statements run in order, failures stop the batch but preserve the session, and empty/comment-only input is an error. It does not explicitly name alternative tools or when not to use this one, but the behavioral context is strong enough for an agent to decide when it is appropriate.

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?

Since no annotations are present, the description carries the full burden and excels: it discloses parameter-side-effect behaviors, AMPL lazy evaluation, completeness-check behavior (notes and ok: false), and validation errors for invalid names and limits. It even clarifies why sets/constraints/objectives are not subject to row-count checks, providing non-obvious behavioral details beyond any structured annotation.

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 long but every sentence earns its place. It is front-loaded with a one-sentence summary and then organized into focused paragraphs covering suffix rules, side effects, completeness checks, and validation requirements. No fluff or restatement of schema fields 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?

For a tool with six parameters, no annotations, and complex AMPL behavior, the description is remarkably complete. It covers side effects, error conditions, output hints (entity_rows, notes/ok), and limitations for non-row entities. The presence of an output schema further reduces the need to describe return values, so the overall context is sufficient.

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 has 0% property descriptions, so the description must compensate. It does so for the most critical parameters: name (bare entity name, interpolation risk), suffix (allowed values, at-most-one), and limit (page size, minimum 1). It omits explicit semantics for offset, to_csv, and session, which is a gap, but the coverage of error-prone parameters is substantial.

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

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

The description opens with a specific verb and resource: 'Read an entity's values as records.' It further explains that suffix selects val/dual/rc/slack/lb/ub, which clearly distinguishes this tool from siblings like ampl_display or ampl_eval by scoping its purpose to structured reads of entity values.

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 on when to use the tool—for reading entity values with suffix options—and provides important avoid-conditions, such as not reading parameters whose data dependencies are still changing. It does not explicitly name alternative tools for similar reads, but the guidance is sufficient to choose this tool for record-oriented retrieval.

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 full responsibility for disclosing behavior. It goes beyond expectations by explaining workdir defaults, path-resolution rules and escape refusal, and explicitly warns that the tool is not a sandbox with concrete examples of how AMPL expression text can write outside and include can read outside. This level of transparency is exemplary.

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 core purpose ('Start an AMPL engine') followed by essential operational details. The lengthy caveat about path protection and sandboxing is justified given its security implications and is well-structured. Every sentence adds value, and there is no filler.

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

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

The description comprehensively covers purpose, workdir behavior, and critical security caveats, making it highly usable for initialization. However, it omits explanations of the name and solver parameters and does not discuss return values or error behavior (though an output schema exists). These gaps prevent a perfect completeness score.

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 has 0% description coverage for its three parameters. The description only explains workdir (default behavior and path resolution) but says nothing about the name or solver parameters. Since the schema provides no semantics, the description needed to compensate for all parameters but only covers one, leaving the other two ambiguous.

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 'Start an AMPL engine,' a specific verb and resource, and clarifies that 'No engine exists until this is called.' This distinguishes it from sibling tools like ampl_use_session, ampl_restart_session, and ampl_close_session, 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?

The description clearly implies this is the initialization step before using any other AMPL tool ('No engine exists until this is called'). It also gives practical guidance on when to pass a workdir ('pass a path to work against a real project'). However, it does not explicitly name alternative tools or state when not to use this tool, so it does not fully reach the explicit-exclusion level.

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 implies a read-only discovery operation ('List declared entities', 'map of what has been built') but does not explicitly state that it is non-destructive, since annotations are absent. It adds useful context about what the tool returns (shape and built state), but no deeper behavioral details.

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 extremely concise, front-loading the core purpose in the first sentence and adding practical guidance in the second. Every word 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?

The tool has an output schema, which reduces the need to explain return values, and the description covers purpose and usage well. However, parameter semantics are entirely absent, and with no annotations, the description alone is slightly incomplete for a fully informed 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 input schema has two parameters (kind, session) with 0% description coverage, and the tool description does not explain either parameter. With no guidance on what 'kind' filters or how 'session' is used, the agent is left to infer semantics from parameter names alone.

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 ('List') and resource ('declared entities') and clarifies the purpose with 'with their shape' and 'map of what has been built.' This clearly distinguishes it from sibling tools like ampl_list_sessions.

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 the agent when to use this tool ('Call this when unsure what exists rather than guessing at names'), providing clear usage context. It does not explicitly name alternatives, but the when-not guidance is present.

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 transparency. It clearly indicates a read-only listing operation with no side effects. It does not mention return format, but the output schema likely covers that. No contradictions exist.

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, well-formed sentence that immediately states the action and purpose. No fluff or redundant 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 no parameters and the presence of an output schema, the description is sufficient for an agent to understand what the tool does. It could mention that it returns a list or the format, but the output schema covers that. For a simple listing tool, it is complete enough.

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 description does not need to explain any. Baseline for 0-param tools is 4, and the description adds no unnecessary parameter detail.

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 ('List') and identifies the resource ('live sessions') plus the key distinguishing detail of identifying the current session. This clearly separates it from sibling session-management tools like init, use, or close.

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

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

No explicit when-to-use or alternative guidance is provided. However, the wording implies it is for inspecting session state, and the sibling tool names (init/use/restart/close) make the intended use obvious. It lacks explicit exclusions but is adequate for a simple listing tool.

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 and excels: it discloses that unknown option names produce an argument_error on both get and set, explains the rationale (AMPL creates options on first assignment), and notes the <solver>_options exception. It also states the value parameter must be a string when provided.

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 sized but every sentence earns its place: the main function, error behavior, exception, and value constraint are all essential. It is well-structured and free of redundant wording.

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 description covers the core functionality, error handling, and value type, and the output schema handles return values. However, the unexplained `session` parameter is a completeness gap, preventing a perfect score.

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 description adds meaning for `name` (errors for unknown options) and `value` (must be a string), but the `session` parameter is not mentioned at all. With 0% schema description coverage, this leaves a significant gap, so it only partially compensates for the lack of parameter documentation.

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

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

The description clearly states the tool's dual function: 'Get an AMPL option, or set it when `value` is given.' This specifies both the verb (get/set) and the resource (AMPL option), distinguishing it from sibling tools like ampl_eval or ampl_display.

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 the tool is for reading or modifying AMPL options, with clear context about error behavior and the special <solver>_options exception. However, it does not explicitly name alternatives or state when not to use this tool, 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses critical security behavior: direct file contents are guard-checked, but nested includes/libraries execute unchecked and are reported in a 'warnings' list, plus it details failure return structure with 'message' and 'detail'. This is exceptional transparency that goes well beyond a typical tool description.

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: it starts with the primary purpose, then layers essential security caveats and failure reporting behavior. There is no filler, repetition, or ambiguity, and the structure front-loads the most important information.

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

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

Given the tool's high-complexity security profile, the description is self-sufficient: it covers file resolution, guard-checking, nested-file execution risk, warnings, and error detail. It also aligns with the output schema by referencing 'warnings', 'message', and 'detail', so explicit return-value documentation is unnecessary.

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 has 0% description coverage, so the description must compensate for parameter meaning. It maps .mod/.dat/.run to file types, which partially clarifies model/data/run parameters, but it does not explain the 'session' parameter or individual parameter semantics. The parameter names are self-evident, but the description does not fully fill the schema coverage gap.

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

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

The description opens with a specific verb and resource: 'Load .mod/.dat/.run files by path, resolved inside the session workdir.' It also distinguishes itself from sibling ampl_eval by noting files are guard-checked 'exactly like a statement passed to ampl_eval,' making clear this tool is for file loading rather than inline evaluation.

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

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

The description clearly establishes the tool's use case: loading files by path within a session workdir, with explicit file types (.mod/.dat/.run). It does not explicitly name alternative tools or give when-not-to-use conditions, but the context is sufficient to differentiate from inline evaluation and other session management 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 discloses the key destructive behavior: 'discarding all model state.' However, with no annotations provided, it fails to mention other important behavioral aspects such as whether the session is closed, if data/files need reloading, or any side effects on other resources. It is minimally transparent.

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 extremely concise: one sentence plus a brief phrase. It front-loads the action ('Restart the engine') and adds a clarifying effect ('discarding all model state'). Every word adds value with no 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 destructive operation with no annotations and an unexplained parameter, the description is incomplete. It does not explain recovery steps, prerequisites, or full consequences (e.g., what state is exactly lost). The output schema might help, but the description alone leaves crucial context missing.

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

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

The schema has one optional 'name' parameter with 0% description coverage. The description does not mention this parameter at all, leaving its purpose and allowed values completely unexplained. Since schema coverage is low, the description should have compensated but did not.

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 explicitly states 'Restart the engine, discarding all model state' – a specific verb (restart) and resource (engine), with the effect clearly described. This distinguishes it from sibling tools like init/close/eval by focusing on restarting rather than creating or modifying.

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

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

The phrase 'The recovery path' implies use for recovery scenarios, but there is no explicit guidance on when to use this tool vs alternatives (e.g., close_session + init_session) or prerequisites like having an active session. It hints at usage but does not state it clearly.

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?

Since no annotations are provided, the description carries the full burden. It discloses input format flexibility (scalar, mapping, list), the declaration requirement, and potential error condition (non-bare name triggers argument_error). It doesn't mention side effects or return details, but the output schema likely covers return values. Overall, strong disclosure for a mutation 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 efficiently structured with a clear one-sentence purpose, followed by specific details on values, scope limitation, and error behavior. Every sentence adds value, and the use of code examples aids clarity without unnecessary length.

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 annotations, the description covers the key contextual aspects: accepted value shapes, prerequisite (parameter must exist), scope (parameters only), and error semantics. It also references ampl_eval for sets, which helps integration. The omission of session behavior is minor given sibling tools, and the output schema handles return values. Overall, quite complete for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It richly explains `values` (scalar/mapping/list of records) and `name` (bare entity name, interpolated into AMPL). However, the `session` parameter is not explained at all, leaving a gap in parameter understanding. The description adds meaning beyond the schema for two of three parameters, but incomplete coverage keeps it at a 3.

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

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

The description clearly states the tool assigns a parameter from JSON, avoiding hand-written .dat syntax. It specifies the verb (assign), resource (parameter), and input format, and distinguishes itself from ampl_eval (which handles sets). This is a specific and differentiated 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 explicitly says this tool handles parameters only, and instructs to use ampl_eval for sets with a concrete example. It also states that the parameter must already be declared, providing a clear prerequisite. This gives explicit when-to-use and when-not-to-use guidance with 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 present, the description carries the full transparency burden and does so exceptionally. It explains the bounded tail behavior, the strict `ok` condition, and the edge cases where AMPL reports 'solved' without actually running a solver, providing deep insight beyond the schema.

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 tightly structured, front-loaded with the main action, and every sentence earns its place. The third sentence is dense but packed with necessary edge-case detail, with no 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 complexity and the absence of annotations, the description provides strong behavioral coverage including output constraints and error conditions. However, it omits guidance for the five parameters and does not fully integrate with sibling tools beyond the duals mention, leaving some invocation ambiguity.

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 0%, and the description does not compensate for the five parameters. `solver`, `options`, `session`, `objective`, and `log_tail` are never individually explained; only vague references like 'bounded tail' and 'objective' give partial 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 specific verb and resource: 'Solve the current model and summarise the outcome.' This clearly distinguishes ampl_solve from siblings like ampl_eval or ampl_get_data by stating exactly what it acts on and what it returns.

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 use after a model is set up and explicitly recommends ampl_get_data for retrieving duals and reduced costs, which gives useful alternative guidance. It does not state explicit exclusions or when not to use the tool, but the context is clear enough.

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 fully carries the transparency burden and does so extensively: it discloses server-side iteration, shared core with ampl_solve, failure handling (failed runs recorded, sweep continues), collect guard checks and name collision avoidance, overall-ok semantics, and the crucial side effect that the parameter is left at the last swept value. This goes far beyond basic mutability or safety hints.

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

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

The description is long but every sentence adds operational detail; it is structured into logical paragraphs (purpose, solve semantics, failure/collect behavior, parameter state). It is front-loaded with the core action and then follows with necessary caveats. Slightly verbose but justified by the tool's complexity.

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 (sweep, collect, failure handling, objective activation, state persistence), the description covers all critical aspects needed for correct invocation: what happens on failure, how collect is guarded, how objective is activated, and the non-restoration of the parameter. An output schema exists, so return-value detail is not required, and the description doesn't waste space on it.

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 0%, so the description must compensate. It explains `param`, `values`, `objective` (including bogus-name precheck), and `collect` (guard-checked, name-collision rules) in meaningful detail. However, `solver`, `session`, and `log_tail` are not described, though they may be standard across sibling tools. The coverage is substantial but not complete.

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 'Set a scalar parameter to each value, re-solve, and collect results,' which is a specific verb+resource statement that clearly distinguishes it from sibling tools like ampl_solve (single solve) and ampl_eval (expression evaluation). It also adds scope ('Server-side' and 'twenty-point study is one call rather than forty round trips') that reinforces its unique 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 explicitly positions this as the server-side sweep alternative to repeated solve calls ('one call rather than forty round trips'), and contrasts its behavior with ampl_solve and ampl_eval (shared core, guard checks). It also gives concrete guidance on when to omit `objective` and warns about parameter state after the sweep, offering a mitigation ('re-set the parameter first'). This provides clear when/why-to-use context.

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, but it only states the action without disclosing side effects, failure modes, or persistence. It does not explain what 'current session' means operationally or whether it affects other tools.

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 front-loaded with the core action, but it is under-specified. While every word is used, it lacks supporting context, making it minimal rather than efficiently complete.

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 signature, the description is still incomplete. It omits error handling, requirements for the session to exist, and the effect of switching, which is critical for an agent to 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 0%, and the description only identifies 'name' as the session name, which is already evident from the parameter name. It adds no format, constraints, or examples, so it barely compensates for the gap.

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

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

The description 'Make `name` the current session' uses a specific verb and resource, clearly indicating the tool switches the active session. It distinguishes from siblings like init, close, or list by focusing on selecting an existing session as current.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the verb alone.

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 and excels. It discloses that no session is required, explains the behavior of ampl_version being None without a live session, and notes that the result shape remains consistent. This goes beyond simple 'report' semantics and covers edge cases.

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 in the first sentence, followed by usage guidance and a nuance paragraph. Every sentence earns its place, and the structure is logical and easy to scan.

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 zero-parameter schema and the presence of an output schema, the description fully covers the necessary context: session independence, payload detail, and a practical failure scenario. It is complete and leaves no obvious 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?

The input schema has zero parameters, so the description does not need to explain parameter details. The baseline for 0-param tools is 4, and the description adds context about the session-dependent behavior which is more relevant than any param 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 begins with the specific verb 'Report' and lists the exact resources (server build, AMPL versions, licence tier, installed solvers), making the tool's purpose immediately clear. This clearly distinguishes it from sibling session-management or evaluation 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 when-to-use guidance: 'Call this first when anything is unexplained' and gives a concrete scenario (demo licence behavior). It also names the alternative action ('Call ampl_init_session first if you need it') for a specific case, showing strong usage direction.

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