Skip to main content
Glama
Sign In

tokyo-futuro

by io.github.TokyoFuturo
OverviewDiscussionsAdmin

prepare_vehicle_heist_launch

Vehicle heist: prepare (unsigned) a heist on a vehicle held by victim, with a squad of 2 to 5 (you first; role 1 Driver required, 2 Hacker optional, 3 Muscle, 4 Face, 5 Inside Agent; the target is the vehicle token itself). An aircraft (helicopter or jet) brought as usedToken must be held by, or approved to, the Driver, or the launch reverts (PilotNotHolder); the air Driver bonus (+250) needs that real pilot, otherwise the Driver gets the ground +150. Role bonuses and the one-use items (itemMask) work only if the admin switches are on (city_state.switches says; the pipeline turns them on for the next testnet round, mainnet stays closed), and itemMask is refused by the contract while items are off. You pay the kit (and the scout fee if scouted); the result is a drand round about 30 s later (then prepare_vehicle_heist_resolve).

Input Schema

NameRequiredDescriptionDefault
rolesYesOne role number per member, same order. Role ids differ per game (see this tool's description).
victimYesThe wallet that holds it right now.
walletYesYour own 0x wallet address. Nothing is sent from it; it is used to read your balance and allowance and to simulate.
membersYesCrew wallets, YOU first (each other member must have called prepare_approve_leader for you). Omit to go alone where the game allows. The size limit is per game: night_run 1-4, convoy 1-5, ledger 2-5, vehicle_heist 2-5, raid 2-4.
scoutedNoPay the scout fee for better odds.
tokenIdYesThe vehicle token to steal.
itemMaskNoOne-use items to burn: 1 plates, 2 fare, 4 forgery (add them). Default 0. The heist items are refused (any non-zero mask) until the contract has them switched on: check city_state.switches.
usedTokenNoA vehicle of ANOTHER model one of the squad holds (bonus), or 0.
minOddsBpsNoRevert instead of launching if the odds would be lower than this (0 = no check).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / members / description
      Previous value: -"Crew wallets, YOU first (each other member must have called prepare_approve_leader for you). Omit to go alone where the game allows. The size limit is per game: night_run 1-4, convoy 1-5, ledger 2-5, vehicle_heist 3-5, raid 2-4."New value: +"Crew wallets, YOU first (each other member must have called prepare_approve_leader for you). Omit to go alone where the game allows. The size limit is per game: night_run 1-4, convoy 1-5, ledger 2-5, vehicle_heist 2-5, raid 2-4."
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it names a concrete revert path (PilotNotHolder), explains bonus economics (+250 air vs +150 ground), the switch-gated itemMask refusal, who pays the kit and scout fee, and the ~30 s drand settlement window.

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, but the rest is a dense run-on paragraph with heavy parenthetical nesting, and the testnet/mainnet pipeline aside is tangential to actually calling the tool.

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 9-parameter, 5-required mutation with no annotations or output schema, it covers costs, timing, preconditions, and failure modes well. It leaves the return payload shape and how the wallet parameter is used for simulation to the schema, a minor gap.

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 baseline 3, but the description earns more: the schema's roles field explicitly defers to 'this tool's description' for role ids, and the description supplies the full 1-5 role mapping plus that 'the target is the vehicle token itself.' minOddsBps and scouted are left to the schema, so not a 5.

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?

States a specific verb and resource ('prepare (unsigned) a heist on a vehicle held by victim') with scope (squad of 2-5) and names the follow-up sibling prepare_vehicle_heist_resolve, so an agent can tell exactly what this does and where it sits in the pipeline.

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?

Gives clear sequencing ('the result is a drand round about 30 s later (then prepare_vehicle_heist_resolve)') and preconditions such as the aircraft-holder rule for usedToken and the member approval requirement. It does not explicitly compare against other launch-type siblings like prepare_raid_launch, keeping it from a 5.

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

All tokyo-futuro toolsInspect
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