Whirrwork

Robot or ladder? (the Ladder Test)

robot_or_ladder

Read-onlyIdempotent

Does this job need a robot at all? Rule-based verdict from the Ladder Test (the same rules as whirrwork.com/tools/robot-or-ladder/): answer up to 6 questions yes / no / unsure and get ladder, robot, both or tossup, the reasons on each side with their points, what to find out first, and (with job) the sourced price and provider counts for that job. No numbers except our own counts; nothing is stored. Questions: ladder = could a competent person with a ladder do it in an afternoon?; risk = is it dangerous for a person (height, confined space, live wires)?; scale = is it big (many hectares, a whole facade, a warehouse)?; repeat = will it repeat often (weekly, daily)?; data = do you need measurements or records (maps, thermal, logs)?; hands = does it need hands-on fixing (repair, not just looking)? Examples: {"ladder":"yes","risk":"no","scale":"no","repeat":"no"}; {"ladder":"no","risk":"yes","scale":"yes","data":"yes","job":"roof-inspection-drone"}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "robot_or_ladder"
  }
}

Input Schema

Name	Required	Description
`job`	No	Optional job (use case) id from search_use_cases, to add its sourced price and provider counts
`data`	No
`risk`	No
`hands`	No
`scale`	No
`ladder`	No
`repeat`	No
`language`	No	Language for use-case text (machine-translated; English is authoritative). Default en.

Output Schema

Name	Required	Description
`of`	No
`job`	No
`url`	Yes
`tool`	Yes
`guide`	No
`label`	No	Rule-based verdict, not a measurement or a cost estimate
`rules`	No
`method`	No
`answers`	No
`reasons`	Yes
`verdict`	Yes
`version`	No
`answered`	No
`buy_hint`	No
`find_out`	No
`headline`	No
`language`	No
`questions`	No
`explanation`	No
`robot_points`	No
`person_points`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 27, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: the verdict is rule-based, output includes reasons with points and next checks, no numbers are invented except own counts, and nothing is stored.

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 purpose and output categories are front-loaded, and the question definitions and examples all add practical value. It is dense and semicolon-heavy rather than cleanly structured, but there is little pure filler.

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, the output schema, and the rich annotations, the description supplies enough context to call it correctly. It covers the decision questions, optional job enrichment, output categories, examples, and storage behavior without needing to duplicate the full return schema.

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

Parameters5/5

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

Schema description coverage is only 25%, and the description compensates by defining the six decision inputs ladder, risk, scale, repeat, data, and hands in plain language. It also explains the optional job parameter's effect and that answers are yes/no/unsure, covering nearly all decision semantics.

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 states a specific decision task: a rule-based Ladder Test verdict on whether a job needs a robot at all, returning ladder, robot, both, or tossup. It is clearly distinct from sibling tools such as compare_robot_vs_human or find_robots_for_job because it produces an early-stage go/no-go classification rather than a comparison or search.

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

Usage Guidelines4/5

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

It gives clear context for use: answer up to six yes/no/unsure questions and optionally add a job id to enrich the verdict with price and provider counts. It does not explicitly name alternative sibling tools or state when not to use it, so it falls short of full routing guidance.

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

All Whirrwork tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?