Geolithic

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

With no annotations, the description must fully disclose behavior. It does mention a rate limit ('at most one per tick') and a payment requirement, but it fails to explain side effects (e.g., record creation, immutability), permissions, or reversibility. The term 'witnessed' is vague, and no information about errors or output is provided. This is insufficient for an agent to reliably invoke the tool.

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 four sentences and mixes essential operational details with metaphorical language ('record chains beside the world's state'). It is not tightly structured; the core action is front-loaded, but the meaning is diluted by poetic phrasing. It is neither overly verbose nor highly disciplined, so it earns a mid-level score.

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 a tool with 7 parameters, no annotations, and no output schema, the description is far from complete. It does not explain parameter meanings, usage conditions, or expected behavior in a way an agent can act on. The rate limit and payment info are useful fragments, but they do not form a coherent operational picture. A substantial amount of context is missing.

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 compensate, but it provides almost no parameter semantics. Only 'payment' is referenced implicitly, and the 'hash' parameter is implied by 'attach your own sha256'. The remaining parameters (addr, start, amount_degrees, salt, label) are completely unexplained. The description adds negligible value beyond the raw 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 states a specific verb ('Attach') and an object ('sha256 to the face-term'), but 'face-term' is an undefined, domain-specific term that leaves the actual purpose ambiguous. It also does not distinguish this tool from siblings like 'claim' or 'hold_ground', which likely overlap in scope. The poetic phrasing obscures clarity.

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 only usage guidance is a payment requirement ('pass the x402 payment... or pay the card checkout first'), but there is no explicit statement about when to use attest versus alternatives. The reference to 'see claim' hints at a dependency but does not clarify selection criteria. An agent is left without clear direction for choosing this tool over others.

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 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 behavioral burden. It discloses the first 402 response, the checkout_url vs x402 payment paths, the requirement to call claim() again with a base64 payment, and the immediate issuance of the lease. It does not cover failure modes or permission requirements, so it is not fully exhaustive.

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 action and packs a complex payment protocol into a compact paragraph. It is dense and slightly jargon-heavy, but every sentence contributes necessary information without filler.

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 tool with no annotations and no output schema, the description covers the critical two-step workflow, payment options, and outcome. The main gap is individual parameter explanation, but the instruction to present the bid's exact fields and salt partially compensates by pointing the agent back to the prior bid context.

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 0% description coverage, so the description must compensate. It usefully labels the required fields as 'your bid's exact fields and salt' and explains the payment parameter as the base64 x402 PaymentPayload. However, it never defines addr, start, or amount_degrees individually, leaving meaningful ambiguity for an agent constructing the call.

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 opening phrase 'After the gavel: present your bid's exact fields and salt' clearly situates this tool as the post-auction claim step. The winner/lease language makes the resource and lifecycle stage clear, and it is distinguishable from siblings like bid and verify_lease, though the verb 'claim' is not restated.

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 description gives explicit timing ('After the gavel') and explains that only a winner proceeds through the 402 payment flow. It also details the two payment routes and the need to call claim() again with the payment. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.

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 provided, the description must carry the behavioral disclosure burden, and it does add meaningful details: a four-minute wait limit, payment requirements, reserve/clearing pricing, and the wait=False receipt behavior. Yet the explanation is so domain-specific and cryptic that the actual side effects—such as whether a binding hold is created or how attestation completes the flow—are not clearly communicated.

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 run-on paragraph packed with semicolons, parentheticals, and unexplained terms. While it is not long in word count, its structure makes the workflow harder to parse rather than easier, and it mixes purpose, pricing, async behavior, and follow-up actions into one confusing block.

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 tool with 9 parameters, no annotations, no output schema, and many sibling tools, the description is not complete enough. It never explains return values beyond a vague 'receipt', coordinate semantics, what a 'face' or 'place' is, failure conditions, or the meaning of salt/label/amount_degrees. An agent would likely need additional external knowledge to call this tool correctly.

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 only alludes to a few: 'session's length' maps to hours, 'sha256' maps to hash, and it names payment and wait. Required parameters lat and lon are never clearly explained, and optional parameters salt, label, and amount_degrees are completely absent from the description. This leaves over half the parameters effectively undocumented.

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 does state a specific action—'Hold the ground you work on, in one call'—and outlines a multi-step flow involving quote, bid, claim, and payment. However, the heavy jargon ('face under the place', 'gavel', 'x402', 'attest()') obscures the actual outcome and makes it hard for an agent to know exactly what is being held or claimed. It also does not explicitly distinguish this tool from siblings like bid, claim, quote_ground, or attest.

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 description provides some conditional usage guidance, such as using wait=False to bid and return a receipt, and calling attest() after claim_after. It also explains behavior for contested vs. uncontested cases. However, it never explicitly tells an agent when to prefer hold_ground over the individual sibling tools or what prerequisites must exist before calling it.

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?

The description discloses the core conditional behavior: if both stamps stand on faces sharing a parent at the same tick, the answer names the room and level. With no annotations provided, it still leaves the negative case unstated and does not explicitly confirm whether this is a read-only query or what happens on invalid input.

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 and front-loaded with the question. The trailing clause 'the same place at the same time, by the chain's own arithmetic' is slightly redundant but reinforces the tool's logic 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 tool with no output schema and no annotations, the description explains the positive case well but omits the negative-case return, error behavior, and explicit output shape. An agent can call it, but may not know what a 'no meet' result looks like.

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%, so the description carries the full burden, and it succeeds by identifying both a and b as the two stamps' chain.digest values. This adds real meaning beyond the bare string fields in the schema, though it does not specify the digest format.

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 clearly states the tool's purpose: to determine whether two stamps met by comparing their chain.digest values. It specifies the resource (two stamps), the operation (meet), and the expected output (room and level). The concept is distinct enough from sibling tools like stamp or verify_lease.

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 question 'Did two stamps meet?' implies the intended use case, and 'Pass the two stamps' chain.digest values' tells the agent what to provide. However, the description gives no explicit guidance about when to prefer this tool over related siblings, nor any when-not-to-use conditions.

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 does disclose meaningful behavior: the whole tick is never served, `field` restricts output, results include Merkle openings verifiable with hashes alone, and mapped fields may appear conditionally. It omits auth requirements, error behavior, and side-effect status, but for a query-like operation the disclosed constraints are substantial.

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 dense, run-on, cryptic paragraph that mixes input requirements, output contents, verification details, and conditional availability without clear structural separation. It is not front-loaded with a plain action statementcarrying a lot of useful detail, but it forces the agent to parse through a wall of domain jargon.

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 lists the major output components and important constraints, which is valuable given there is no output schema. However, it omits precise return structure, exact units or formats for the numeric readings, error conditions, and any guidance on how the Merkle opening should be consumed. It is more complete than minimal, but not fully self-sufficient for an unfamiliar agent.

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%, yet every parameter receives meaningful context: `addr`, `start`, `amount_degrees`, and `salt` are called the lease's own fields; `tick` is the optional named tick; and `field` is explicitly narrowed to `wind_10m`, `wind_850`, and `magnet`. This fully compensates for the bare input 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 eventually identifies a concrete read operation: submit lease fields, optionally name a tick and field, and receive the held address plus mapped facet observations, the tick record, census, and stamps. It is not a tautology and states a resource (the facet/ground) and a specific scope. It does not explicitly differentiate from siblings like `ground` or `quote_ground`, but the core purpose is recoverable.

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 when-to-use or when-not-to-use guidance, and no mention of alternative sibling tools. The conditional notes about `field` narrowing and magnet availability are parameter-level guidance, not tool-selection guidance. An agent cannot tell why `open_ground` should be chosen over `ground`, `hold_ground`, or `quote_ground`.

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 transparency burden and does add some useful behavioral detail: the caller supplies a salt (16–64 hex) that 'the house never holds', and the response includes 'exact x402 requirements to sign.' It does not state whether the call is read-only, what side effects occur, or what the full response shape looks like.

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 and information-dense, with no obvious filler, and it front-loads the core concept. However, the structure is poetic and opaque rather than agent-friendly, with undefined terms like 'face', 'gavel', and 'house' that force the agent to parse jargon.

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 four-parameter tool with no output schema and no annotations, this description is incomplete: it omits the role of lat/lon, does not explain when to use the tool versus siblings, and gives no clear response format or side-effect information. It does provide some useful signals, such as the returned fields and salt handling, so it is not wholly inadequate.

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 compensate, but it only loosely maps to the parameters: 'duration' hints at hours, 'place' vaguely implies lat/lon, and salt is explicitly described as 16–64 hex. It does not explain that lat and lon are required, what their formats should be, or how the default of 1 hour behaves.

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 indicates the tool produces a quote-like 'plan to hold the ground under a place for a session' and lists pricing-related fields, so it is not merely a tautology. However, it never plainly says 'get a quote', uses cryptic metaphors like 'face', 'gavel', and 'house', and does not clearly distinguish this from sibling tools such as ground, hold_ground, or bid.

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 call quote_ground versus bid, ground, hold_ground, or claim. The phrase 'sign before the gavel' implies this is a pre-bid or quote step, but the conditions, prerequisites, and alternatives are left to inference.

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?

With no annotations, the description carries the transparency burden and does disclose key behavior: a two-cent fee over x402, no account required, and a 402-then-payment flow. It omits the final response format and any permanence/side-effect detail, but the main payment and retry behavior is clearly exposed.

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: purpose and price appear first, then optional location, then the payment flow, then the sibling tie-in. Some metaphorical wording such as 'Earth's tick' and 'world's last witnessed state' is atmospheric rather than purely operational, but it still keeps the description short.

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 six-parameter tool with no annotations and no output schema, the description is adequate but not complete. It covers the payment handshake, the optional location fields, and the relationship to 'meet()', but it does not explain 'label' or what success-after-payment returns, so an agent still has gaps to fill by trial.

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?

Because schema coverage is 0%, the description must compensate, and it partially does: 'hash' is clarified as the sha256 to stamp, 'addr'/'lat'/'lon' as the location selectors, and 'payment' as the signed follow-up. However, 'label' is never mentioned or mapped, and the relationship between addr versus lat/lon is left implicit.

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 says the action is to 'stamp' a supplied sha256 to the current moment/time/state, with a fee and no account. It also routes the two-stamp case to the sibling 'meet()', which gives some distinction from related tools. The poetic phrasing is indirect, but the operative resource and action are discernible.

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 explicitly explains the payment workflow: without 'payment' the tool returns a 402 with signing requirements, and the caller should call again with 'payment'. It also says location can be provided as an address or lat/lon, and it names 'meet()' for the witnessed-meeting case. A full when-not-to-use set of alternatives is not given.

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. It discloses that the default returns only a hash, that 'light=True' returns field arrays at mesh levels 2–5, and that the reading is 'chained and never served'. However, these disclosures are wrapped in obscure language ('unsworn', 'poles' eyes', 'measured magnet's zeros') that obscures rather than clarifies actual behavior. It does not state side effects, permissions, or failure modes.

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 long and dense with metaphor, but the key information (default hash, light option, mesh levels) is buried in figurative language. It is not front-loaded with a plain statement of purpose. Every sentence is stylized, which hurts scannability for an agent.

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 no output schema and no annotations, the description is incomplete. It does not explain the return format beyond 'hash' and 'field arrays', does not specify the meaning of 'slice' clearly, and does not describe error conditions or relationship to sibling tools. The reference to 'open_ground()' hints at a workflow but does not clarify it.

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. It explains 'light' as a boolean that toggles returning 'the light' (field arrays), and 'slice' is mentioned only as 'mesh level (2–5)' in the context of light=True. The description does not clearly map 'slice' to the integer parameter, nor explain its default behavior or range. The poetic phrasing adds ambiguity rather than clarity.

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 is poetic and metaphorical ('the newest tick of the Earth, free', 'the clock and the chain's links', 'the commitment a stamp binds to'), making it difficult for an agent to determine what concrete action 'tick' performs. It mentions returning a hash by default and optionally 'light' field arrays, but the core function remains obscured by figurative language. It does not clearly distinguish itself from siblings like 'stamp' or 'attest'.

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. The description references 'open_ground()' as a way to open the face, but does not explain when to choose 'tick' over 'stamp', 'attest', or 'ground'. The usage context is implied through metaphor rather than stated.

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.

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

With no annotations, the description carries the full burden and does disclose meaningful traits: a per-call cost of two cents over x402, the 402-with-requirements first response, refusal of not-yet-chained moments, the ~3-hour chaining lag, and the shared-payment semantics ('one payment opens a face-tick for everyone after'). It does not describe error modes beyond refusal or the shape of a successful payload, but the payment and refusal behavior is unusually well covered.

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 prose is dense and every clause carries information, but the opening sentences are poetic and the practically critical payment mechanics sit mid-paragraph rather than being front-loaded. A reader must parse metaphor before reaching 'Two cents over x402' and the refusal rule, which weakens structure even though little is redundant.

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 five-parameter tool with no annotations, no output schema, and 0% schema coverage, the description covers payment, refusal, and the settlement lifecycle but omits key callable details: how lat/lon pair with `at`, what units or valid ranges they take, and what a successful witness payload contains. It is coherent but not fully sufficient to invoke confidently.

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% with five parameters, so the description must compensate. It does explain `at` (ISO hour or tick, UTC, default newest), `addr` (from an earlier answer, re-reads one face-tick), and `payment` (the x402 proof), covering three of five. `lat` and `lon` are only implied by 'the wind at a place' and their units/expected ranges go unstated, leaving a real gap.

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 does convey the resource — wind state at a place and moment as committed to a chain, including proofs and the outside anchor — so it is not a tautology. However, the intent is wrapped in metaphor ('nest face's three corners', 'the Merkle opening to the tick's chained root'), and it never distinguishes itself from close siblings like ground, open_ground, or tick. An agent would have to infer the specific role from the settlement narrative at the end.

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?

Usage conditions are stated concretely: `at` selects an hour or tick and defaults to the newest chained tick, unchained moments are refused rather than substituted, and the two-stage x402 flow (get 402, retry with `payment`) is spelled out. It also names collaborating siblings stamp() and meet() in the settlement flow. What is missing is any explicit when-to-use-this-instead-of-ground/open_ground guidance.

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