Bid for the NEXT term of a face-stratum (address F{base}·{digits},
level 4–7 by digit count; amount in degrees ≥ the reserve, ≤ 720,
at most 12 decimals). Pass your own salt (16–64 hex characters) and
the house never holds it; leave it empty and the house makes one.
Returns a receipt: KEEP THE SALT — it is the only credential. The
gavel strikes at the receipt's gavel tick; then use claim().
| Name | Required | Description | Default |
|---|---|---|---|
| addr | Yes | ||
| salt | No | ||
| amount_degrees | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses salt handling (house never holds it if supplied, generates one if empty), warns that the salt is the only credential, and describes the gavel-tick timing and subsequent claim. It doesn't cover failure modes or confirmation behavior, but the critical behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the purpose, then pack constraints, security warning, and next-step instruction without waste. The parentheticals and semicolons keep related facts together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the receipt, the salt as credential, the gavel timing, and the follow-up claim() call. It provides enough context to invoke bid correctly and connect to the broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description fully compensates: it specifies addr format (F{base}·{digits}, level 4–7 by digit count), amount_degrees bounds (≥ reserve, ≤ 720, ≤12 decimals), and salt length (16–64 hex chars) plus optional behavior. Every parameter's meaning and constraints are explained beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb, 'Bid,' and a clear resource, 'the NEXT term of a face-stratum,' with address and amount constraints. It clearly distinguishes the action from siblings by naming claim() as the subsequent step, making it unmistakably the bidding tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for bidding on the next term and instructs to use claim() after the gavel strikes, providing strong workflow context. It does not explicitly name alternative tools for other stages or state when not to use bid, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.