Moltline Optimize

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

Discloses optimization objective (minimises cost/count), solver behavior (proves optimality or returns FEASIBLE plan), and error behavior (never raises protocol error, returns error object). This goes well beyond the readOnly and idempotent 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?

One dense paragraph with no filler: example input/output, solver behavior, size limit, alternative tool, error handling, and safety. Every sentence 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?

For a 4-parameter tool with no nested objects and an output schema, the description covers input format, return shape, optimization semantics, error behavior, and retry safety. Nothing essential for correct invocation is 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?

Schema covers 100% of parameters with useful descriptions, so the baseline is high. The description adds a concrete input example clarifying stock/parts/kerf structure and explains cost/count semantics, though time_limit_s is left entirely to the schema.

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

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

Description opens with 'Least-waste cut plan for bars, pipes or boards from stock lengths', clearly stating what the tool produces. It also distinguishes itself from cutting_stock_2d, making the 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?

Gives explicit guidance: 'Use for a cut list of up to 200 pieces' and 'Not for sheets: use cutting_stock_2d.' This provides both an inclusion criterion and a named alternative, so an agent can route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint; the description reinforces these and adds a detailed error contract: invalid input never raises a protocol error but returns an error object with guidance. It also discloses the heuristic nature, the guillotine-cut constraint, and the grain/rotate override behavior. This goes well beyond the structured 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 front-loaded with the core function, then uses a compact example to convey input/output shape, followed by constraints, use cases, limitations, and error handling. Every sentence contributes distinct information, and the length is 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?

The tool has a rich output schema, so return-value details do not need to be repeated. The description covers the key operational facts: read-only and idempotent behavior, error handling, optimality caveat, guillotine constraint, and grain semantics. Nothing essential for an agent to select and invoke the tool correctly is 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds concrete meaning through the typical input example, including kerf as a numeric value, parts with quantities, and the resulting layout structure. It also explains the grain rule and per-part rotate override, which adds behavioral context to the parameters.

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 opening sentence states the operation and resource: building guillotine cut layouts for rectangular parts from sheets, with kerf and grain. The 'guillotine' and '2D' qualifiers distinguish it from siblings like cutting_stock_1d and pack_bins. Example input/output further clarifies the exact scope.

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 names target use cases: cabinet, sign, and sheet-metal cut lists. It also flags the tool as a best-fit shelf heuristic and 'not proven optimal,' signaling when it may not be suitable. It does not explicitly name sibling alternatives or exclusions, but the usage context is 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?

The description goes well beyond the readOnlyHint/idempotentHint annotations by detailing the exact error behavior: 'it returns {"error": "<what is wrong and how to fix it>"}' and never raises a protocol error. It also explicitly states that every call is read-only, idempotent, and safe to retry, which adds actionable behavioral context not present in the annotations alone.

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?

Every sentence earns its place. The description uses a clear opening statement, a concrete example, usage guidance, exclusion from road routing, and error behavior. It is dense but well-organized and does not waste 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?

For a tool with an output schema, the description still covers all necessary invocation details: input shape, example, units, limit, error responses, and retry safety. An agent has everything needed to select and call this tool correctly without additional inference.

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

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

Schema coverage is 100%, so all parameters are documented structurally. The description adds meaning by providing a complete typical input/output example, clarifying the points format ({id, lat, lon}), the unit options, the 200-point limit, and the shape of the returned matrix. This is far beyond the schema's minimal descriptions.

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 precise statement: 'Straight-line (great-circle) distance matrix from coordinates,' which clearly identifies the computation and resource. It further distinguishes itself from road routing by stating 'Not road routing: real driving distances are longer.' This makes it unmistakable relative to sibling tools like route_plan.

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?

Explicit guidance is provided: 'Use when you have no road matrix and a straight-line approximation is acceptable, or to sanity-check one.' It also states what the tool is not for: 'Not road routing.' This gives an agent clear selection criteria among the sibling 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?

Annotations already declare readOnly, idempotent, and non-destructive hints; the description adds value by explaining error behavior: it 'never raises a protocol error' and instead returns a structured error object. It also clarifies that input is recognized by fields across multiple solver tools, and that retrying after correction 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 longer than average but every sentence earns its place: purpose, cost, example, accepted input sources, use case, exclusions, error behavior, and retry guidance. Key information is front-loaded, with the core purpose stated first.

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 only one parameter and rich annotations, this description is fully complete. It covers what the tool accepts, what it returns with a representative example, how errors manifest, and why retrying is safe. There is no missing information an agent would need to invoke it 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 schema only says the `solution` parameter is a result object from a solve tool. The description substantially expands this by naming the exact solver tools whose outputs are accepted, providing a concrete example input and output, and explaining that the object is recognized by its fields.

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: 'Plain-language summary of a solution from this server and the constraints that bind.' It clearly differentiates itself from solve tools by stating 'Not a re-solve' and by listing the exact solver result types it recognizes.

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 states when to use it: 'Use to turn solver output into a message for a dispatcher or a shop floor.' It also gives a clear exclusion, 'Not a re-solve,' and tells the agent that invalid input yields a fixable error so retry is safe.

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, idempotentHint, and destructiveHint. The description adds valuable behavior beyond that: it never raises a protocol error and instead returns an error object, and it explicitly says retrying is safe after correcting input. 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?

The description is front-loaded with the core purpose and includes a compact example, dynamic resource explanation, use cases, exclusions, and error behavior. Each section earns its place, though 'FREE.' is a minor digression and the overall text is 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 the tool's flexible additionalProperties schema, the description covers the key invocation details: constrained resources, multiplicity via qty, error behavior, retry safety, and appropriate use cases. The output schema exists, so the return structure in the example and solver_status is sufficient for an agent to understand what to expect.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantic detail beyond the schema by explaining that any numeric item field named in limits becomes a constrained resource and that qty allows an item to be taken multiple times. The worked example further clarifies how items and limits map to the selected output.

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 first sentence states a specific verb and resource: 'Choose the items that maximise value under one or more capacity limits.' It clearly identifies the knapsack problem and distinguishes it from sibling tools by saying it is for budgets, cargo, campaign, or feature selection and not for dependencies between items.

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 explicit use cases ('Use for budgets, cargo, campaign or feature selection') and an explicit exclusion ('Not for dependencies between items'), but it does not name an alternative sibling tool. This is clear context without fully specifying what to use instead when dependencies exist.

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 (read-only, idempotent), the description discloses crucial behavioral details: it never raises protocol errors and instead returns an error object, it is a heuristic rather than optimal, fragile items carry nothing, and min_support defaults to 0.6. It also explicitly confirms read-only and idempotent behavior, making retries safe. This is exceptional transparency.

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 information-dense, and the useful details (example, rotation rules, error behavior, heuristic status) each earn their place. The example JSON is heavy but instrumental for correct invocation. Slight deduction for the trailing 'FREE.' being low-value and the overall length being near the upper bound.

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 packing tool with nested objects and non-obvious constraints, the description is nearly complete: it covers input semantics, output shape via example, error format, retry safety, heuristic limitations, and special rules. The presence of an output schema reduces the need to explain return values, and the description still supplies a concrete example. Nothing critical is 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?

Although the schema already covers 100% of parameters, the description adds substantial meaning: a full example input/output, the meaning of 'rotation per item' (any/upright/fixed), the 'rules.min_support' default, the interpretation of 'fragile', and that containers are 'used in the order given'. This goes well beyond the schema's brief property descriptors.

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 first sentence states a specific verb and resource: 'Place up to 20 boxes into containers or pallets with rotation, weight and support rules.' It also scopes the tool by the size cap and adds a concrete decision purpose ('decide pallet or carton count before booking freight'). This clearly distinguishes it from siblings like pack_bins_large even without naming them.

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 a clear use case: 'Use to decide pallet or carton count before booking freight.' It also warns that the algorithm is a 'first-fit-decreasing heuristic' and not proven optimal, which helps set expectations. However, it does not explicitly state when not to use this tool or mention pack_bins_large as the alternative for larger problems, so it falls just short of full alternative 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?

Beyond the readOnly and idempotent annotations, it adds important behavior: invalid input returns an error object instead of raising a protocol error, results are not proven optimal, and retrying after correction is safe. This gives an agent actionable expectations beyond what annotations alone provide.

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 denser but each section earns its place: capacity, example, output shape, use cases, algorithm caveat, error behavior, and retry safety. The read-only/idempotent sentence slightly repeats annotations, but it also adds practical retry guidance, so the cost is minor.

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?

It covers capacity limits, typical input, returned shape, intended use, algorithmic limitations, error handling, and idempotency. Given the schema and annotations, an agent has what it needs to select this tool and invoke it correctly without 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 schema already covers all three parameters, so the baseline is 3. The description adds a concrete JSON example showing how to structure items and containers, which helps construct a valid call. It does not discuss the rules parameter in detail, but the schema already documents it.

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 identifies this as a bin-packing tool via 'Same packer as pack_bins' and clarifies the larger scale with 'up to 300 item units and 200 containers.' Its typical input and output shape make the resource and result clear, but the core action is expressed through comparison to pack_bins rather than an explicit 'packs items into containers' statement.

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 gives clear selection context: use this for order consolidation and load planning, and the capacity bound differentiates it from pack_bins. It does not explicitly state when not to use it or name a smaller-input alternative, though the capacity phrasing implies the boundary.

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 mark the tool read-only and idempotent, and the description reinforces this with 'Every call is read-only and idempotent.' It also adds significant behavioral detail not in annotations: error handling never raises a protocol error, returns an error object, and the objective prioritization rules. This transparency is valuable for an optimization 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 long but densely packed: purpose, example, objective, scale, limitations, error behavior, and safety all earn their place. It is front-loaded with the core purpose. The example is somewhat verbose but justified for a complex nested-input tool.

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, the description covers scope, constraints, objective prioritization, failure behavior, and retry safety. The output example plus the presence of an output schema make the return contract clear. Nothing critical is missing for correct invocation.

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

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

The schema has 100% coverage, so baseline is 3. The description adds value beyond the schema with a complete typical input example, a returned output example, and clarification of preferences via 'staff.prefer / staff.avoid shift ids.' This helps the agent construct correct nested inputs.

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: 'Assign staff to shifts under availability, skills, hour caps and rest gaps.' It clearly identifies the tool's domain and distinguishes it from sibling optimization tools by focusing on shift rostering rather than routing, packing, or cutting.

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

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

The description gives concrete usage context: 'Use for weekly rotas of up to 60 staff and 150 shifts' and explicitly warns it is not legal compliance advice. It does not name sibling alternatives, but the scope and example are strong enough for an agent to select this tool appropriately.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond that: the tool never raises a protocol error but returns a structured error object with corrective guidance, and it documents capacity-check behavior when demand and vehicle_capacity are used. No annotation 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 front-loaded with the core purpose and a concrete example, then covers limits, use cases, exclusions, error behavior, and idempotency. Each section earns its place, and the length is justified for an optimization tool with non-obvious input expectations.

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 an output schema present, return values are already structured, yet the description still provides a illustrative response. It covers the stop limit, matrix constraints, depot handling, capacity checks, route_plan_fleet distinction, distance matrix sourcing, error behavior, and retry safety. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description genuinely adds meaning by explaining that the matrix must be square, the depot should be at index 0 unless the depot parameter says otherwise, units are user-defined, and optional demand plus vehicle_capacity triggers a capacity check. This goes beyond the schema.

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

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

The description opens with a specific verb and resource: 'Order up to 12 stops into the shortest single-vehicle route on your distance matrix.' It distinguishes itself from route_plan_fleet by explicitly calling out single-vehicle routing, making the tool's scope 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?

It provides explicit when-to-use guidance ('Use for one driver's day or a courier's loop') and explicit when-not-to-use guidance ('Not for several vehicles or time windows: use route_plan_fleet'), including a named alternative for distance input (distance_matrix_haver sin). This is strong routing to 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?

Beyond the annotations, it discloses that invalid input never raises a protocol error but returns an error object, that unsterved stops are listed, that zero-demand stops are always dropped, that units are minutes and demand units, and that calls are safe to retry. These behavior details go well beyond readOnlyHint/idempotentHint and add real value.

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 well-structured and front-loaded, with purpose, example, units, usage guidance, and edge cases in logical order. It is slightly longer than necessary because it restates read-only/idempotent behavior already present in annotations and contains a self-correcting zero-demand edge case, but it is not bloated.

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 7-parameter solver with an output schema, the description covers purpose, I/O shape, units, defaults, error protocol, edge cases, and sibling routing. An agent has everything needed to decide whether to call it, construct input, interpret output, and recover from failures.

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?

Although schema coverage is 100%, the description adds substantive meaning: windows and service times are minutes from the start of the day, travel time comes from the matrix, returned loads are in demand units, max_distance absent means unlimited, and window [0, 1440] means anytime. The worked input/output example maps parameter names to concrete values.

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 opening sentence names a specific operation: 'Capacitated, time-windowed routing for a fleet over up to 200 stobs.' It later clarifies scope ('This tool only otimizes the routes for a fixed fleet') and explicitly distinguishable from route_plan and pack_bins, so an agent can tell it apart from siblings without opening the schema.

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 gives explicit when-to-use guidance: use pack_bins or pack_bins_large to build a fleet, use route_plan for a single uncapacitated route, use validate_problem for solver errors, and use explain_solution to explain output. This is model guidance on alternatives and conditions.

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 idempotentHint, it discloses cost ('FREE'), the important invalid-input behavior (never raises a protocol error; returns an error object), and the guarantee that it does not invoke the solver. This is exactly the behavioral context an agent needs and goes well beyond 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?

Dense but well-organized: purpose, cost, typical request/response, type list, usage timing, non-solve guarantee, error contract, retry safety. Each sentence carries distinct information and key points are front-loaded.

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

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

Given the output schema exists and annotations cover safety, the description still supplies the missing operational context: how to interpret errors, that it is read-only/idempotent for retries, and how the problem object maps to sibling tools. Nothing an agent needs to call it correctly is absent.

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 100% schema coverage the baseline is 3, and the description adds genuinely useful meaning: 'problem' uses the same fields as the matching solver tool, and the typical-input example shows the nested shape for route. This exceeds baseline but does not need to enumerate every subtype.

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?

States a specific action ('check a problem's shape and obvious feasibility') on a clear resource, enumerates the accepted problem types, and explicitly differentiates itself from solver siblings with 'Not a solve: it never calls the solver.' An agent can immediately distinguish it from route_plan, pack_bins, etc.

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?

Directs agents to use it first when they have assembled a problem from other data and frames it as a pre-solve gate ('before spending solver time'). It says what it is not (not a solve) but does not name specific alternatives for when validation is unnecessary, though the sibling list makes the contrast clear.

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