Loading ToolBench
MCP lab assignment: construction work scheduling against a weather forecast
BuildWindow defines 4 well-scoped tools with complete input schemas, clear descriptions, and proper enum constraints. All tools are READ_ONLY and deterministic. Naming follows verb_noun pattern (lookup_, validate_, estimate_, plan_). Descriptions are detailed (150 - 250 chars) and explain WHEN to use each tool. Parameters have types and descriptions. However, output schemas are not documented in the source, only inferred from descriptions. Error handling is mentioned in descriptions but not formalized in the schema. No tool annotations (readOnlyHint, etc.) are visible in the code.
Estimate how long a concrete or coating work type needs to cure under a given sequence of daily temperatures, using the Nurse-Saul maturity method. Use this when a work type has a curing stage and cold weather may extend it beyond the nominal duration. Returns the ready date, or capped=true when the supplied temperature sequence is too short to reach the required maturity. Fails with no_curing_stage for work types that have no curing stage at all.
Return the normative weather constraints for construction work types. Call this first when you need to know the temperature, wind, humidity or precipitation limits that apply to a work type, or to enumerate all work types in a category. Provide either a single work_code or a category, never both. Returns an empty list with matched_count=0 when the category contains no work types; this is a successful result, not an error.
Produce a feasible day-by-day schedule for several construction works across a weather forecast, honouring declared dependencies between works. Each work is placed in the earliest window where no day is prohibited. Returns both the scheduled works and the works that could not be placed, each with an explicit reason. Use this instead of repeated validate_work_window calls when planning more than one work.
Evaluate whether one construction work type may proceed during one specific day of weather. Returns a verdict of allowed, conditional or prohibited together with the exact constraints that were breached and by how much. Use this to check a single work-day; use plan_work_schedule when you need to place several works across a forecast. The verdict is computed by deterministic rules, not estimated — treat it as authoritative.
Output schemas not documented. Descriptions mention return structure (e.g., 'verdict of allowed, conditional or prohibited') but no formal JSON Schema for responses is visible in the source code. LLMs cannot reliably parse unstructured output.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema. All 4 tools are READ_ONLY and idempotent, these should be declared via annotations for agent safety.
Error handling not formalized in schema. Descriptions mention error cases (e.g., 'no_curing_stage' for estimate_curing_time, 'no_suitable_window' for plan_work_schedule) but no error response schema or recovery guidance is documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
plan_work_schedule accepts complex nested arrays (works with dependencies, forecast with 5 weather fields each). No pagination or result limits documented. Large forecasts (30+ days × many works) could produce verbose responses.
lookup_work_requirements parameter design: 'work_code' and 'category' are mutually exclusive but this is only stated in description ('never both'), not enforced via schema (e.g., oneOf). LLMs may pass both.