RoboSelect360 - Independent Humanoid Robot Intelligence

Pilot decision file (G.R.O.U.N.D., paid)

build_pilot_decision_file

Read-onlyIdempotent

Paid follow-up of prepare_pilot. From the buyer's dossier (as returned by prepare_pilot) and 1 to 5 robots chosen by the buyer (robot_ids, from list_robots), returns the full pre-pilot decision file in markdown: decision memo, the robots' announced facts, an evidence matrix per robot and per task with every dated observation behind it (failures included, with source, control mode and power), the gaps to close and who can close them, operating conditions and integration, the pilot specification, the questions to ask the manufacturer and the integrator, and the pilot self-assessment grid. Never recommends, ranks or chooses a robot, and computes no cost: the buyer decides. Requires the decision file access right, separate from robot access; without it the call returns a refusal with the link to request it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dossier": "<dossier>",
      "robot_ids": "<robot_ids>"
    },
    "name": "build_pilot_decision_file"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No
`dossier`	Yes
`robot_ids`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, closed-world), the description discloses genuinely non-obvious behavior: the call is paid, it requires a decision-file access right separate from robot access, and failure returns a refusal containing a link to request that right. It also states two hard behavioral constraints — it never recommends, ranks or chooses a robot and computes no cost — which prevent the agent from misrepresenting the output.

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?

It is a single dense paragraph, but it is front-loaded with purpose, then prerequisites, then return contents, then constraints and failure mode, in a logical order. The long enumeration of file sections is verbose but each item is a distinct deliverable, so little could be cut without losing information; the run-on construction is the main stylistic cost.

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

Completeness4/5

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

For a complex tool with a nested dossier object, no output schema and no parameter documentation, the description covers the return payload in detail and covers the authorization failure path. The remaining hole is the undocumented 'lang' parameter and the absence of any statement about the dossier's required internal shape, which an agent would have to infer from prepare_pilot's output.

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 carry the load, and it does for two of three parameters: 'dossier' is defined as what prepare_pilot returned, and 'robot_ids' carries the cardinality constraint of 1 to 5 plus its source in list_robots. The 'lang' parameter is left completely unexplained in both schema and description, which is the only gap.

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 a specific verb and resource ('build ... the full pre-pilot decision file in markdown') and explicitly positions it as the 'Paid follow-up of prepare_pilot', so the agent can distinguish it from that sibling without opening either schema. It then enumerates the file's actual contents (decision memo, evidence matrix, gaps, pilot spec, self-assessment grid), removing any ambiguity about what is produced.

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?

Usage context is clear: it must follow prepare_pilot, it takes the dossier that prepare_pilot returned, and it takes 1 to 5 robots chosen from list_robots, which names the upstream tool to call first. What is missing is an explicit 'when not to use' or what to do if the buyer has not yet run prepare_pilot, but the prerequisite chain is strong enough for correct selection.

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

All RoboSelect360 - Independent Humanoid Robot Intelligence 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.