Skip to main content
Glama

ampl_sweep

Sweep a scalar parameter across a list of values, re-solve the AMPL model for each, and collect objective and custom expression results in a single call.

Instructions

Set a scalar parameter to each value, re-solve, and collect results.

Server-side so a twenty-point study is one call rather than forty round trips; AMPL re-presolves only what changed. Each run goes through the same shared core as ampl_solve (_solve_once), so it gets the same output-failure-marker scan, the same "solved AND has an objective" requirement for ok, and the same stable objective_name/objective_value shape - not a re-implementation that would silently reopen the holes Task 8 closed. objective, if given, is activated with an objective <name>; statement before the first solve (exactly like ampl_solve's own objective=) so every run actually optimizes that objective, not merely reports its value computed at some other objective's optimum; a bogus name is caught before any solve runs, the same way ampl_solve catches it. Omit objective to use whichever objective AMPL reports first, which on a model with more than one declared objective may not be the one actually active.

A value that fails to assign (wrong parameter name, wrong type, a value outside a declared domain) is recorded as its own failed run (ok False, with a message) and the sweep continues through the remaining values rather than aborting. collect names extra AMPL expressions evaluated with ampl.get_value after each solve; each is guard-checked exactly like a statement passed to ampl_eval, so collect cannot become another route to shell, and none may reuse a name this tool already uses for a run's own fields (value, ok, solve_result, ...) - doing so would silently overwrite that field instead of adding a new one. The overall ok is false if any run failed.

The parameter is left at whatever the LAST swept value was; this tool never restores the value it had before the call. A later ampl_solve() on the same session solves against that last value, not the model's original state - re-set the parameter first (e.g. via ampl_set_data) if that is not what is wanted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramYes
solverNo
valuesYes
collectNo
sessionNo
log_tailNo
objectiveNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/worc4021/ampl-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server