Skip to main content
Glama

do_in_world

Have something in the physical world made true — a sign hung, a parcel collected and delivered, a filter swapped, a slab poured — by whoever can do it: a person, a crew, a contractor, a drone, a machine. Comes back with proof it happened.

Money leaves your person's balance when you post this. If you connected without a key, nothing leaves anywhere: the reply carries pay_at and token. Send the person the pay link; the job goes live when their card is authorised, and it is charged only for what is proven done. Keep the token — it is how you follow the job. Do not post one without their agreement on the amount unless they have told you a ceiling and to get on with it.

Call check_feasible first if you have not already. Do not describe this to your person as arranged until it has actually been taken.

Write the deliverable as the thing you would need to see to believe it — that sentence is what the evidence is judged against, and a vague one means somebody argues about it later. Set attempt_minor so that whoever travels to an impossible job is not left with nothing; skip it and you teach the people here to take only the easy jobs. Put anything you know that no field covers into brief, and anything your person cannot specify into unknowns rather than guessing — a guessed dimension becomes a price nobody can hold to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNo
lonNo
areaNocoarse locality shown on the open board, e.g. a neighbourhood or town; never put the exact address here
briefNoanything else about this job, in your own words, carried to whoever does it exactly as written and never interpreted. Put here whatever matters that no other field fits — the slope of the ground, when the owner is away, what the neighbour agreed. This is how you tell their agent what you know
whereNothe exact address; released only to whoever takes the job, never published
accessNohow to get in: gate code, where the key is, alarm sequence. Released only to whoever takes the job. Never put this in instructions or brief — those are published on the open board and a job containing entry details is refused
skillsNoqualifications required, e.g. hvac, electrical, plumbing, refrigerant, locksmith, drone, cdl, notary, ladder, vehicle, lifting, cleaning, assembly, photography
stagesNocut a long job into pieces that are each evidenced and paid as they are finished. Their pay must add up to fee_minor
plan_byNowho decides how this job breaks into stages: "buyer" (default, you supply stages) or "supplier" (the winning bidder proposes the breakdown and you accept it). Use supplier for trade work you do not know how to decompose — a homeowner does not know what a binder course is, and guessing produces a schedule the crew is then judged against
site_idNoa location from your site list, instead of typing an address
radius_mNohow far from that point the evidence may be taken
unknownsNowhat your human cannot specify — how wide they want the driveway, the footprint of the barn. Say so rather than guessing: a bid then has to state what it priced on and whether that price holds, and that assumption is what the finished work is judged against. Guessing instead produces a number that means nothing and an argument on site
direct_toNosend this to one of your approved vendors instead of the open board. No auction, no strangers, invisible to everybody else
fee_minorYespaid on completion, in minor units
predicateYeswhat should be true once the job is done. Shown on the open board, so keep the exact address out of it
referenceNoyour purchase order, cost centre or work order. Carried to the receipt untouched
site_markNosomething visible at this property and nowhere else, which must be legible in one photograph — usually the house number. This is what separates a photo of YOUR cut lawn from a photo of A cut lawn: the code proves when it was taken, the location metadata is editable by whoever made the file, and neither says whose lawn it is. Inferred from the address when you leave it out. Set it explicitly when the number is not visible from where the work happens, and name what is instead
depends_onNojob ids in the same project that must be finished and accepted before this one may be started. Use this wherever the order is real — a slab cures before anything drives on it — because otherwise two crews book the same ground for the same morning
project_idNothe budget envelope this job draws on, from open_project
work_hoursNohow long the work takes. Set this for anything longer than an errand, or the job is treated as abandoned partway through
bids_as_oneNoaccept a single offer covering every job in this project, priced per job and awarded together or not at all. Set this when the jobs share a site: arriving once is most of the cost of a small job, and a supplier who cannot bundle prices one mobilisation per job or loses
deliverableNowhat proof to bring back, e.g. a photo of the parcel at the door with the house number visible
instructionsYeswhat the person should actually do
attempt_minorNopaid for a documented failed attempt, e.g. the shop was shut
expense_cap_minorNohow much they may lay out and reclaim against a receipt
require_insured_to_minorNorefuse anybody whose verified public liability cover is below this

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers: it discloses financial consequences ('Money leaves your person's balance when you post this'), the no-key fallback behavior ('nothing leaves anywhere: the reply carries pay_at and token'), the async lifecycle ('the job goes live when their card is authorised'), and incentive effects ('skip it and you teach the people here to take only the easy jobs'). This is rich behavioral disclosure beyond anything the schema states.

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 description is long (four dense paragraphs) but each one earns its place: purpose, payment mechanics, sequencing, and parameter guidance. It is front-loaded with the core action before diving into financial detail. For a 26-parameter tool with no annotations, the length is proportionate rather than padded.

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?

Given the complexity (26 params, no annotations, no output schema), the description covers the critical lifecycle: what happens on post, what the reply contains (pay_at, token), how to follow the job, and how to phrase the deliverable. It does not describe the full response shape or enumerate fields like skills, stages, and plan_by, but those are already well documented in the schema at 92% coverage.

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?

Despite 92% schema coverage, the description adds real semantic depth to key parameters: deliverable ('write it as the thing you would need to see to believe it'), attempt_minor ('set it so whoever travels to an impossible job is not left with nothing'), and unknowns ('a guessed dimension becomes a price nobody can hold to'). It does not touch all 26 parameters, but the ones it addresses get rationale that the schema lacks.

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: 'Have something in the physical world made true' with concrete examples (sign hung, parcel delivered, slab poured). It clearly establishes this as the action-taking tool versus siblings like check_feasible, job_status, and observe_world, and even names check_feasible as a prerequisite, sharpening the contrast.

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?

The description explicitly says 'Call check_feasible first if you have not already,' naming the key sibling and the ordering. It also gives when-not-to guidance: 'Do not post one without their agreement on the amount unless they have told you a ceiling' and 'Do not describe this to your person as arranged until it has actually been taken.' It stops short of enumerating all sibling alternatives, but the main routing decision is covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target clearly distinct actions: feasibility checking, posting physical work, gathering structured info, verifying truth, and reviewing job artifacts. The only plausible confusion is between find_out and observe_world, since both involve paying someone to investigate the physical world, though their outputs differ.

Naming Consistency3/5

All names are snake_case and readable, but the pattern is mixed: check_feasible, find_out, observe_world, and list_bids are verb-first, do_in_world is a unique verb+preposition, and job_evidence, job_receipt, and job_status are noun-first. The job_* family is internally consistent, but the set as a whole lacks a single predictable convention.

Tool Count5/5

Eight tools is well-scoped for a physical-world exchange: pre-flight feasibility, posting work, requesting information, verification, bidding, status, evidence, and receipts. Each tool earns its place and the count is neither bloated nor thin.

Completeness4/5

The core lifecycle is covered: check feasibility, post a job, review bids, track status, inspect evidence, and get a verifiable receipt. The main gaps are no explicit cancel/update job tool and no direct job listing tool, but agents can navigate the main workflows without dead ends.