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.

Input Schema

TableJSON 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

TableJSON 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.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description adds rich behavioral context: no fee/gas/money moves, nothing is held, the server owns the hours-counting flag, the flow is not automatic, and the signed message expires. No contradiction with annotations.

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 longer than typical, but nearly every sentence carries behavioral or workflow information. It is front-loaded with the core purpose and ends with the critical next step, though some stylistic redundancy could be trimmed.

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 complexity of a two-step signing flow and the presence of an output schema, the description is complete: it covers preconditions, security constraints, what to send, what not to send, how the next step works, and the expiry/next action. Nothing essential is missing.

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

Parameters3/5

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

The input schema covers all parameters with detailed descriptions, so the baseline is 3. The description largely restates parameter guidance (hash not photo, plain-word name, local person, offers list) rather than adding new semantic constraints beyond the schema.

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 clearly states the tool's purpose: preparing a place for the board in step 1 of a 2-step process. It names the exact resource ('place'), the action ('prepare'), and the follow-up tool ('submit_place'), distinguishing itself from the sibling submission tool.

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

Usage Guidelines5/5

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

It explicitly frames the precondition ('Your place is not on the board yet'), explains the non-automatic next step, and instructs the agent to sign with the wallet's personal_sign and call submit_place within 5 minutes. This is direct, actionable usage guidance.

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