Skip to main content
Glama

Hand the board your own place (step 1 of 2)

prepare_place
Read-onlyIdempotent

Your place is not on the board yet: this is how it gets there. FREE, a signed statement, no fee, no gas, no money moves and nothing is held. You give the pin where you are standing, the radius of the place, plain words for its name, the name of the local person who will acknowledge the handover, the SHA-256 hash of one photo you took at the spot, and a short list of what you can DO there, which is the half that makes a match possible. SEND THE HASH, NEVER THE PHOTO: this board takes a hash and never a file. You give NO Regen address either, because the board derives the Regen account your signing key controls from the signature itself. What happens next is NOT automatic: the house reads the intake and decides whether to post hours-counting work at your place, because the flag that makes a packet count hours is server-owned and a stranger's own post can never carry it. Nothing here is a job, a claim or a promise of pay. Returns MESSAGE_TO_SIGN and BODY_JSON; sign with that wallet's personal_sign, then call submit_place within 5 minutes. Cost and signer: free, no gas; the person signs the result with their own wallet or passkey, and the house never holds a key.

Input Schema

NameRequiredDescriptionDefault
latYesLatitude of the exact spot, as your phone reads it. Not a city centre.
lngYesLongitude of the exact spot, as your phone reads it.
noteNoOptional, up to 300 characters: anything the house should know about the place.
offersNoOptional, and the half that makes a match possible: 1 to 5 short plain-word lines saying what you can DO at this place, at most 80 characters each, e.g. ["trail clearing, hand tools", "can bring two people"]. A human reads them beside the work the house is about to post. Descriptive only: they gate nothing and price nothing.
radiusKmYesHow far the place reaches, in km, from 0.1 to 3. A place someone can walk, not a region.
placeNameYesPlain words a person would recognise, e.g. 'the north boundary of the community forest'. Up to 120 characters.
stewardNameYesThe local person who will acknowledge that the work was handed back. A NAME ONLY: this record is public, so never a phone number, an address or an email. Up to 80 characters.
workerWalletYesThe 0x… address that signs. Address only, never a private key.
sitePhotoSha256YesThe 64-character hex SHA-256 of one photo taken at the spot. The hash only. Keep the photo yourself; it is what proves the hash later.

Output Schema

NameRequiredDescriptionDefault
okNo
toolNo
fundedNo
payUsdNo
workIdNo
claimIdNo
claimableNo
next_callNo
proofRuleNo
fulfillableByNo
definitionOfDoneNo
needs_from_callerNo
notClaimableReasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: no fee, no gas, no money moves, nothing held; the hash-not-photo constraint; that no Regen address is supplied because it is derived from the signature; that posting is not automatic and the hours-counting flag is server-owned. It also discloses the 5-minute signature window and who signs (user's own wallet or passkey, house never holds a key). Nothing described contradicts the readOnly/idempotent/non-destructive hints, since this step only produces a payload.

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?

It is one dense run-on paragraph with repetition ("FREE... no fee, no gas, no money moves and nothing is held") and a duplicated phrase about offers being "the half that makes a match possible" that also appears in the schema. Every fact is relevant, but the lack of structure and the redundancy make it heavier to parse than necessary.

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 nine-parameter, seven-required prepare step with an output schema and full annotation coverage, the description covers the essentials: what is produced, how to sign, the deadline, and the downstream gate. It stops short of covering failure modes such as an expired signature window or rejected intake, but the output schema and annotations carry the rest.

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 the schema already documents all nine parameters, but the description reinforces the two high-risk semantics: send the SHA-256 hash and never the photo, and supply no Regen address. It also explains that the offers list is descriptive only and enables matching. This adds intent and safety emphasis beyond the field-level text, though it mostly mirrors what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description establishes a specific action (get a place onto the board) and explicitly frames it as step 1 of 2, naming the follow-up sibling submit_place and its outputs. The opening sentence is narrative rather than a declarative verb+resource statement, which costs it a point, but an agent can still tell it apart from submit_place and the other prepare_* tools.

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 the triggering condition ("Your place is not on the board yet"), the exact next step ("sign with that wallet's personal_sign, then call submit_place within 5 minutes"), and excludes misreadings ("Nothing here is a job, a claim or a promise of pay"). There is no explicit contrast against any alternative besides submit_place, but for a two-step pair that is sufficient context.

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.

Resources