Skip to main content
Glama

Find flip

find_flip
Read-onlyIdempotent

Finds where an outcome changes, and gives the run on each side. request is a run_trajectory or solve request written out, its domain and card or its solver by the name find_model or the lists give, with no from, readout or example; vary is the place of the one number to change, such as "segments[0].load.current_a", "initial.soc", "dt_s" or "parameters.load_n"; low and high are the two ends of the span, in either order: the smaller is taken as low. The span is halved to the place where the outcome or the stop name changes or, with level, where a published quantity of the final state (of a solve: of result) crosses a value or a flag turns. When both ends give the same, 7 values between them (3 for solves) are run to find a band, and the answer says so. The answer gives the run on each side as a request ready to send again, with its outcome, its stop name and sentence and the run_seal or solution_seal that request has when sent alone, the two values in decimals and exact hex, and the width between them. A side that stops before computing has no proof. The same request gives the same pair. A search is bounded, and names the bound that stops it: 64 runs (FLIP_MAX_RUNS), 1000000 steps in all (FLIP_MAX_STEPS), or 64 solves (FLIP_MAX_SOLVES), the ends included, and no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS); the pair it gives, sent back as the span, narrows it further. On this open connection a search is long work whenever it varies a solve or its runs may take more than 10000 steps together. One address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

Input Schema

NameRequiredDescriptionDefault
lowYesOne end of the span. low and high may come in either order; the smaller is taken as low.
highYesThe other end.
varyYesThe place of the one number to vary: "segments[0].load.current_a", "segments[*].load.current_a" for every segment, "initial.soc", "dt_s", "segments[0].steps", "parameters.load_n". A count is varied in whole numbers.
levelNoOptional. {"quantity": <a published quantity>, "value": <number>}: the span is halved to where that quantity of the final state (of a solve: of result) crosses the value. {"quantity": <a flag>}: to where a true-or-false value of it turns.
requestYesA run_trajectory or solve request as that tool takes it. A search of solves makes no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS), each at the time describe_solver states for one solve of its solver (open_connection), and always makes at least 3, both ends and one value between them: a count, not a clock, so the same request stops at the same solve on any machine. A search of runs is held by its steps (FLIP_MAX_STEPS).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / request / description
      Previous value: -"A run_trajectory or solve request as that tool takes it."New value: +"A run_trajectory or solve request as that tool takes it. A search of solves makes no new solve once those made are counted at 20 s (FLIP_MAX_SECONDS), each at the time describe_solver states for one solve of its solver (open_connection), and always makes at least 3, both ends and one value between them: a count, not a clock, so the same request stops at the same solve on any machine. A search of runs is held by its steps (FLIP_MAX_STEPS)."
  2. Changed2 schema fields changed
    • addedInput schema / properties / level / description
      Added value: +"Optional. {\"quantity\": <a published quantity>, \"value\": <number>}: the span is halved to where that quantity of the final state (of a solve: of result) crosses the value. {\"quantity\": <a flag>}: to where a true-or-false value of it turns."
    • changedInput schema / properties / vary / description
      Previous value: -"The place of the one number to vary."New value: +"The place of the one number to vary: \"segments[0].load.current_a\", \"segments[*].load.current_a\" for every segment, \"initial.soc\", \"dt_s\", \"segments[0].steps\", \"parameters.load_n\". A count is varied in whole numbers."
  3. First observed

TDQS

A4/5.0
Behavior5/5

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

With readOnlyHint/idempotentHint already covering safety, the description still adds substantial operational context: concurrency limits (one physics permit at a time, long work serialized), the exact error text 'Too many concurrent physics tasks.' and its no-wait behavior, a 60-second wait cap, and concrete bounds (FLIP_MAX_RUNS 64, FLIP_MAX_STEPS 1000000, FLIP_MAX_SOLVES 64, FLIP_MAX_SECONDS 20 s). It also discloses determinism ('The same request gives the same pair') and that a stopped side 'has no proof'.

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

Conciseness3/5

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

Purpose is front-loaded in the first sentence, but the remainder is a dense run-on block mixing parameters, algorithm, return shape, and limits without paragraph or bullet separation. Nearly every clause carries information, so it is not padded, but the idiosyncratic phrasing makes it slow to parse.

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?

For a complex, nested-parameter tool with no output schema, the description is remarkably complete: it explains the return payload (a re-sendable request per side, outcome, stop name/sentence, run_seal or solution_seal, decimal and hex values, width), the bisection fallback when both ends match, and all bounding/limit conditions. An agent has what it needs to invoke and interpret results.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: request must be written out 'with no from, readout or example', level resolves against a published quantity of the final state (of a solve: of result), and count-valued vary targets are varied in whole numbers. These constraints genuinely extend the parameter definitions.

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

Purpose4/5

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

The opening clause states a specific verb and resource: 'Finds where an outcome changes, and gives the run on each side' — an agent can tell this is a bisection/boundary-search tool over a parameter span, distinct from solve, run_trajectory, or compute_step. The peculiar grammar ('gives the run on each side') slightly obscures it, but the operation is identifiable.

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

Usage Guidelines3/5

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

It implies usage by specifying that request must be a run_trajectory or solve request, that vary names the single number to change, and that low/high bound the span. It also notes the returned pair can be sent back to narrow further. However, it never explicitly says when to choose this over solve or run_trajectory, nor 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources