Geolithic

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.

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys that the tool is informational and enumerates the data it exposes, but it never explicitly states that it is read-only, what the response structure looks like, or how domain terms like 'Earth ladder' and 'reserve prices in degrees' should be interpreted.

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?

The description is a single dense sentence that front-loads the core purpose and then compresses all important content categories into a readable list. There is no filler, though the heavy use of domain-specific terms makes it slightly less accessible than it could be.

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?

For a zero-parameter tool with no output schema, the description provides the essential high-level contents: available strata, terms, reserve prices, how to bid and claim, and stated limits. It would be stronger with an explicit statement of return format and read-only behavior, but the invocation path itself is unambiguous.

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?

The input schema has zero properties, so there are no parameters to document. The description does not need to add parameter-level semantics because schema coverage is effectively complete by having no inputs.

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 'What is for lease' and enumerates the catalog's contents: strata L4-L7, terms, reserve prices, bidding/claiming instructions, and founding-period limits. This clearly marks it as an informational catalog rather than an action tool like bid or claim, though it does not use an explicit verb such as 'lists' or 'returns.'

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?

The phrasing 'What is for lease' implies this is the tool to consult for available lease inventory and terms before taking actions like bidding or claiming. However, it does not explicitly name sibling tools or state when not to use it, so the usage guidance remains implicit rather than declarative.

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

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

With no annotations, the description carries the full burden and reveals important behavior: winner gets bearer paper, loser only sees clearing price, and a 402 with pay.checkout_url may precede the final lease. It does not cover auth or invalid-input failure modes, but the core state-changing and payment behavior is disclosed.

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 sentences, with the temporal trigger front-loaded, the outcome next, and the payment edge case last. No repeated schema content; each clause adds information, though the metaphor 'After the gavel' costs a little clarity.

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?

For a complex claim flow with no output schema, it covers the main success path, loser behavior, and the payment retry path. It is slightly incomplete because 'rail' is unexplained and parameter meanings are left implicit, but an agent can act on the described flow.

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 description coverage is 0%, so the description must explain the four required parameters. It only says to present the 'bid's exact fields and salt' and use 'the same fields' on retry, which is useful but does not define addr, start, amount_degrees, or salt individually.

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 gives a specific post-auction action: present the bid's exact fields and salt to receive the lease. It distinguishes the tool's role from siblings by explaining winner/loser outcomes and the lease delivery, so the agent knows claim is the resolution step after bidding.

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 clearly says when to call: after the gavel, and it describes the conditional rail/payment path when a second call is needed. It does not name alternative tools or state explicit 'do not use when' cases, but the winner/loser framing gives enough context.

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

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

With no annotations provided, the description must fully disclose behavior, but it only hints that the tool produces a location at two time points and a drift measurement in kilometers. It does not explain whether this is a read-only lookup, what output is returned, how 'founding' and 'tick' are determined, or what units/format drift takes.

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?

The description is short, but it is not efficiently structured: it uses poetic language and em-dashes rather than plain, front-loaded operational language. Important information is buried in metaphor, and the sentence does not earn its place by aiding comprehension.

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?

Given two parameters, no output schema, no annotations, and no sibling differentiation, the description is far from complete. An agent has no way to know the expected input format, the meaning of the output, error conditions, or the relationship to related tools. This is a minimal and largely unusable definition.

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 description coverage is 0%, so the description must explain the parameters, but it does not explicitly map 'addr' or 'tick_iso'. 'tick's chained frame' obliquely references tick_iso, but 'addr' is only alluded to as 'face address'. This is insufficient for an agent to know what values to provide.

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 gestures at a geolocation operation ('where a face address stands on the earth'), but uses cryptic, non-standard terms like 'face address', 'founding', and 'tick's chained frame' without defining them. It does not state a clear verb or operation such as 'returns', 'computes', or 'looks up', so an agent cannot confidently determine what the tool does.

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?

There is no guidance about when to use this tool versus any of the siblings such as 'tick', 'verify_lease', or 'tell_the_house'. The description implies some relationship to ticks and parcels, but it never explains the intended use case, prerequisites, or alternatives.

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

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

With no annotations, the description carries the transparency burden. It discloses useful behavioral traits: data is public, prices are always included while party identities are never included, every strike is covered, and records carry chain identity plus current occupancy. It does not mention request limits or response ordering, but the core access and privacy behavior is clearly signaled.

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?

The description is compact and front-loaded, with the core data content in the first sentence. The final sentence is a somewhat stylistic tagline, but it adds a purpose signal without bloating the text.

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?

For a simple one-parameter read tool with no output schema, the description gives enough to understand the returned content and privacy rules. It leaves important operational details undocumented—what limit means, whether results are paginated, and the exact response shape—so it is only minimally complete.

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 description coverage is 0% and the description never mentions the only parameter, limit. The schema's name and default give a basic hint, but the description adds no meaning about how limit behaves, what the maximum is, or how it affects the rent-roll records.

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 identifies a specific resource (the public rent roll) and specifies its content: every strike, prices, no parties, chain identity, and current occupancy. It lacks an explicit verb like 'list' or 'get', so it is not a 5, but the noun-phrase form is still clear enough to know what data the tool exposes.

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?

The phrase 'The market data that prices the market' implies this tool is for market/pricing data, and 'public' suggests an open read-style lookup. However, it never states when to choose rent_roll over siblings such as catalog or tick, nor any exclusion cases.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly states that a human reads every word, that the 'door' may change as a result, and that nothing is promised back except a reading. This is valuable transparency, even though the exact nature of the 'door' change is not spelled out.

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?

The description is three concise sentences with the main instruction front-loaded and no repeated information. The 'door itself changes' metaphor is decorative but conveys an expected effect and is not filler. It is well-sized for a simple tool.

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?

For a two-parameter feedback tool with no output schema, the description covers what to write, where to route it, human involvement, and the lack of a guaranteed reply. However, it leaves the meaning of 'the door itself changes' undefined and offers no guidance on how to decide between this tool and its siblings. It is adequate but not fully complete.

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?

With 0% schema description coverage, the description must compensate for the parameter meaning. It explicitly clarifies `where` as naming the tool or route, and `words` is implied to contain the user's confusion, wants, and offers. However, it never directly names the parameters or notes that `words` is required, so the compensation is only partial.

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 communicates that the caller should say what confused them, what they wanted, and what they would pay for, and that a person will read it. However, the actual operation is expressed metaphorically ('the door itself changes') and the concrete effect or resource involved is never defined. It does not differentiate from sibling tools such as bid or claim.

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 implies when to use this tool: when the user is confused, has an unmet want, or has a price in mind, and `where` can name the relevant tool or route. It never explicitly says when not to use it or how it differs from the sibling tools, so the usage guidance remains implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output includes census, poles, frame, and chain references, but does not disclose whether the operation is read-only, whether it has side effects, what authorization is needed, or how invalid mesh levels are handled. The ambiguous word 'free' further reduces transparency.

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?

The description is a single, fairly compact sentence and puts the main object up front. However, it is packed with unexplained domain jargon ('reality', 'census', 'poles', 'frame', 'chain references') and the ambiguous qualifier 'free.' It is not bloated, but it is not maximally clear.

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?

For a single-parameter call, the description gives enough to attempt a default invocation: the slice range is specified and the returned state components are listed. However, there is no output schema, no usage context, no definitions of core terms, and no guidance about when this tool is appropriate relative to its siblings. It is minimally adequate, but with clear gaps.

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?

The schema has 0% description coverage, but the description meaningfully compensates by explaining that the tool operates at a 'given mesh level (2–7)', which maps directly to the slice parameter. It provides both semantic meaning and an allowed range. It does not reference the parameter by name or mention defaults, but the compensating value is strong for a single-parameter tool.

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 identifies an object ('newest tick of reality') and its contents ('canonical state ... census, poles, frame and chain references'), implying this tool returns the latest canonical state for a given mesh level. However, it lacks a clear verb like 'retrieves' or 'returns', and uses ambiguous language such as 'free.' It does not differentiate itself from sibling tools.

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?

There is no explicit guidance on when to use this tool versus alternatives like bid, catalog, ground, or rent_roll. The phrase 'canonical state' hints at authoritative current data, but this is implied rather than stated. No exclusions, alternatives, or selection criteria are provided.

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

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

With no annotations present, the description carries the full burden and addresses it thoroughly: it states that the tool fetches the rent-roll record, recomputes every hash locally, checks the link against the ledger's /api/commitments, and opens winner_env with the salt. It also explicitly discloses trust boundaries ('Nothing is taken on the door's say-so') and what remains trusted, which is exactly the behavioral context an agent needs.

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?

The description is front-loaded with the core purpose, and the following sentences each add substantive detail about the verification steps and trust model. It is longer than strictly necessary and the hash checks are packed into one dense sentence, but there is little wasted wording.

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?

The description thoroughly explains the verification algorithm and trust boundary, which is important given there is no output schema or annotations. However, it does not state the return value or success/failure behavior (e.g., does it return a boolean, throw on mismatch, or produce a report?), and it gives no usage context relative to siblings. These are meaningful gaps for an agent invoking the tool.

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 description coverage is 0%, so the description must add meaning to the three parameters. It does: lease_json is implicitly the named rent-roll record, salt is used in the winner-envelope hash, and amount_degrees is used only when the bid differed from clearing price. It does not explicitly map each parameter or describe formats, but it provides significantly more context than the bare 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 and resource: 'Verify a lease LOCALLY against the public chain', which is clear and not a tautology. It goes on to detail the exact verification checks, but it does not explicitly distinguish this tool from sibling tools such as rent_roll or tell_the_house, so it stops short of full differentiation.

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?

There is no explicit guidance on when to use verify_lease versus the sibling tools, nor any mention of prerequisites or exclusions. The reader can infer that this is for local lease verification, but the description never states the conditions that should trigger this tool or when another tool would be more appropriate.

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