Fabrica (Sepolia testnet)

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

Adds substantial context beyond the annotations: it warns on expiry under a day, distance from Fabrica's estimate, or collateral status; discloses that signing sells the property; and describes prepared-not-sent behavior, the 15-minute expiry, and that the server holds no keys. The destructiveHint=false annotation is consistent because the tool only prepares a request.

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?

Front-loaded with the action and scope, and every clause carries information (warnings, lifecycle, key custody). It is dense but lengthy; slightly more than needed for one 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?

With no output schema, the description still fully explains the returned signRequest shape (summary, warnings, signLink, expiresAt, payload null), the storage behavior, and the human signing step. Nothing an agent needs 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 already 100%, and much of the description's parameter detail (wallet is the signer, orderHash comes from get_land_order_book) duplicates the schema's own text. No new semantics beyond the schema, so the baseline 3 is right.

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?

Specific verb+resource: 'Prepare accepting an open offer' on a property the wallet holds, with the exact source of orderHash (get_land_order_book). It is clearly distinguishable from siblings make_land_offer, cancel_land_order and buy_land.

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?

States preconditions (offer must be open, wallet must hold the token) and the outcome (signing sells the property), plus what happens next. It does not explicitly name an alternative tool or a when-not condition, so it falls just short of 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description goes further by disclosing the retrieval mechanism ('lexical over a committed index, with no external call') and the return shape ('best matching passages with their URLs, so an answer can be cited'). Minor gap: the 'suggests which lookup tool' behavior is mentioned but not detailed.

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?

Five sentences, each earning its place: sources, return format, coverage areas, the property/wallet routing rule, and the retrieval mechanism. Slightly front-loading could improve, but no significant waste.

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?

No output schema exists, so the description appropriately describes what is returned (matching passages with URLs). It covers sources, return format, scope, and cross-tool routing. The main missing piece is guidance on what the returned passages look like in detail, but for a retrieval tool this is sufficient.

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 100%, so the schema already documents question, source (with enum values), and maxPassages. The description adds no syntax or format detail beyond naming the sources in prose. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (answer questions) and a well-defined scope: Fabrica's own published documents, explicitly enumerated (docs.fabrica.land, help center, US trust agreement). This is clearly a documentation-retrieval tool, distinct from every sibling which are all lookup/action tools (get_property, search_properties, etc.).

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 says when to use it (conceptual 'how does Fabrica work' questions) and, crucially, adds a routing rule: when the question names a specific property, wallet or listing, the result suggests which lookup tool to call. This links it to the sibling lookup tools and makes the boundary 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?

Goes well beyond the annotations: it discloses that nothing is sent onchain at call time, that a signRequest is returned and stored, that the sign link expires in 15 minutes, that payload is currently null, and that the server holds no keys and submits nothing. This is unusually rich disclosure for a non-read-only, open-world 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 safety-critical scope and preconditions are front-loaded, and the sentences are information-dense. There is mild redundancy around the sign-then-transact sequence ('Signing sends an onchain transaction', 'Prepared, not sent', 'nothing happens until then'), which could be tightened.

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?

With no output schema, the description carries the full burden for return values and does so: signRequest contents (summary, warnings, signLink, expiresAt, payload) are enumerated. For a multi-step prepare/sign tool this is complete enough to invoke 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 coverage is 100%, so the baseline is 3. The description clarifies that orderHash maps to orderId in get_land_order_book and that wallet is the signing address, but the schema already states both; the added value over the structured schema is marginal.

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?

States a specific verb and resource ('Prepare buying a property at its open listing') plus the network (Sepolia Testnet) and the exact identifier source (orderHash = orderId from get_land_order_book). This clearly separates it from make_land_offer and accept_land_offer, which involve different flows.

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?

Explicitly names the prerequisite listing states it checks (open, buyable, not own wallet, not reserved) and routes the follow-up to get_transaction_status. It does not explicitly say when to prefer this over make_land_offer or accept_land_offer, so it falls just short of full alternative routing.

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?

Annotations only supply readOnly=false, destructive=false, openWorld=true, idempotent=false; the description goes well beyond them. It discloses the async two-step flow (returns a signRequest, stores it, human must open the link and sign), the signRequest contents (summary, warnings, signLink, 15-minute expiresAt, null payload), and the trust model (server holds no keys, submits nothing). This is exactly the extra context the annotations do not carry.

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?

Front-loaded with the core action and scope, then the flow and return shape. Mostly efficient, but the async-signing point is made twice ('Canceling is a confirmation on the sign page, with no transaction' and 'nothing happens until then. The server holds no keys and submits nothing'), which is mild redundancy.

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?

There is no output schema, so the description carries the return-value burden and does so fully (signRequest fields, storage, 15-minute expiry). Combined with prerequisites and the signing handoff, an agent has everything needed to invoke and interpret 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 100%, so the schema already documents all four parameters. The description restates the orderHash-to-orderId mapping and the wallet-as-signer role, which largely duplicates the schema's own parameter descriptions and adds no new syntax or format detail. Baseline 3 is appropriate.

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?

States a specific verb ('Prepare canceling') and a precisely scoped resource ('the wallet's own open listing or offer') on a named network, and cross-references the sibling get_land_order_book for the orderHash. An agent can distinguish this from accept_land_offer and make_land_offer without opening either schema.

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?

Gives clear operating context: it 'checks first that the order is open and the wallet made it,' implying it is used for orders the caller already owns. However, it never explicitly names an alternative (e.g., accept_land_offer) or states a when-not-to-use condition, so exclusions 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior beyond them: the answers come from a hand-refreshed rules table dated 2026-10-16, each answer carries that date, and the live on-ramp page is authoritative. That freshness/staleness caveat is exactly the kind of context an agent cannot infer from structured fields.

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?

It is front-loaded with the core question and then the answer contents, and each sentence contributes something (outcomes, data freshness, accepted inputs, exclusions). The first sentence is a dense run-on that could be split, which keeps it short of a 5.

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?

There is no output schema, so the description carries the return-value burden — and it does, listing deed, forms, notarization, witness requirements, owner questions and on-ramp steps, plus the date stamp on answers. Combined with the input format guidance and the freshness caveat, nothing an agent needs to call it correctly 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?

With 100% schema description coverage, the baseline is 3, and the description earns above it by clarifying the accepted input combinations — 'a 5-digit county FIPS, or a two-letter state with or without a county' — which the schema does not spell out as mutually alternative paths. It does not, however, explain ownerType's effect on the answer, leaving that to the enum.

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 names a specific verb and resource — checking whether a US county or state can be added to Fabrica through the on-ramp — and enumerates the exact outcome values (supported, notConfigured, unsupported). It also spells out what a positive answer contains (deed, forms, notarization, witnesses, owner questions, steps), so an agent knows precisely what this returns and can distinguish it from siblings like buy_land or ask_fabrica.

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 gives a clear use context (on-ramp eligibility lookups) and at least one explicit boundary against a sibling: 'No fee amounts (ask_fabrica has them) and no owner data.' However, it never states the when-not conditions in full — e.g. that estimates or parcel searches belong to estimate_land_borrowing or find_us_parcel — so the routing map is partial rather than complete.

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?

Annotations cover the safety profile (readOnly, non-destructive, idempotent, openWorld), and the description adds substantial context beyond them: nothing is sent by the tool, the person sends the email and replies return by email, an AI-disclosure line is added unless discloseAgent is false, and summaries containing a private key or seed phrase are refused. That refusal rule is real behavioral disclosure not present in the schema or annotations.

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?

Front-loaded with the purpose and the routing condition, and nearly every sentence carries distinct information. It is on the long side and a few clauses ('a stuck onramp, a document question, a dispute') could be tightened, but there is little true waste.

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?

With no output schema, the description still explains the return payload (help center section, support email address, mailto link with summary and property link) and closes the loop on what happens after invocation. An agent has everything needed to call it and describe the outcome.

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 100%, so baseline is 3, but the description adds meaning beyond it: 'subject sets the subject in the person's words', the default subject derivation, the discloseAgent default and its effect, and the private-key refusal constraint on summary. It also confirms the property link is the same fabrica.land page used by the other tools.

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?

States a specific verb and resource ('Hand a question to Fabrica's support team') and immediately distinguishes itself from the sibling ask_fabrica by defining the condition where ask_fabrica fails. An agent can select it without opening any schema.

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?

Explicit when-to-use triggers are given (documents do not answer, a stuck onramp, a dispute, a person is needed) plus the named alternative ask_fabrica. No inference required.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is explicitly an estimate, the reasons a pool shows no capacity are surfaced (tax status, oracle checks), and it warns that 'the rate is set by a live quote when borrowing' rather than by this call.

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 purpose is front-loaded, which is good, but the body is one enormous run-on sentence stuffed with internal field names (wouldAllow, limitedBy, onramp, deed_check) that is hard to parse. Some length is justified because there is no output schema, but the packing is heavier than it needs to 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?

With no output schema, the description carries the return-shape burden well, documenting limitedBy, the oracle block and the toRaise lever list, plus the estimate disclaimer. The main gap is that both slug and tokenId are optional in the schema and the description never says which identifier is needed or what happens if neither is supplied.

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 100%, so the schema already documents slug, tokenId and amountUsd; baseline is 3. The description restates amountUsd's purpose but adds no syntax, format or selection guidance (e.g. whether slug or tokenId is preferred, since neither is required).

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?

States a specific verb+resource up front: 'Estimate how much can be borrowed against a land property on Fabrica'. The scope (DeFi lending pool liquidity, existing loan status, binding limits) is specific enough to distinguish it from siblings like get_fabrica_lending_market, get_fabrica_loan_book and get_land_valuation without opening any schema.

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?

Gives clear context for when to reach for it ('Answers questions such as How much can I borrow against this property?') and explains the optional test mode ('pass amountUsd to test a loan amount'). It stops short of naming alternatives or stating when NOT to use it (e.g. versus a live quote or the lending-market tool), so no exclusions 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value beyond them: the 5-digit positional layout, the max value of 75342, the clarification that each digit is a category value and not a count, and the fact that supplying tokenId makes the response count passing checks. It does not cover behavior when both inputs are supplied or how lookup failures are handled.

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 core action is front-loaded in the first clause, and the digit legend is compact and information-dense. The disclaimer sentence is slightly tangential but earns its place by scoping expectations; overall there is little waste.

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?

There is no output schema, so the description must carry the return-value burden, and it does explain that a tokenId response additionally counts passing checks. The preconditions for the two input modes and error cases are not addressed, leaving a small gap for a decode tool with two alternative inputs.

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 100%, so the baseline is 3, but the description goes further by decoding what the 'score' value actually represents (per-digit verification groups) and clarifying the tokenId alternative path. That meaning is genuinely beyond the schema's terse 'explain this number' phrasing.

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?

States a specific verb and resource (explain a Fabrica property's Property checks from a numeric encoding) and then defines the encoding precisely, so the agent knows exactly what this tool decodes. It is clearly distinguishable from siblings like get_land_property or get_land_tax_status, which retrieve raw property data rather than interpret a verification score.

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 disclaimer that Property checks are 'a starting point for your own research, not a title search or title insurance' establishes a scope boundary, which is useful. However, it never states when to call this versus siblings (e.g. get_land_property) or what condition a user must satisfy to need a decode, so usage is only implied.

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?

Goes well beyond the annotations: discloses the 30 lookups/minute per-client rate limit, that 'The tool itself creates nothing' (reinforcing readOnly), that ambiguous queries return up to 5 candidates matched by parcel number only, that fallback candidates come back as match: unconfirmed / matchSource: fabrica-index and should be presented as likely not confirmed, and that owner names are never returned.

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?

Purpose is front-loaded and every sentence carries operational content (rate limit, fallback semantics, privacy rule). The single dense paragraph, especially the run-on 'For a list, queries takes...' sentence, could be split for faster scanning, so it is efficient but not maximally scannable.

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?

With no output schema, the description carries the return burden and does: candidate lists, per-query rows (onFabrica, tokenId or addToFabrica, coverage), and an unresolved list with reasons. Combined with the fallback and privacy disclosures, an agent has everything needed to call and interpret this 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 100%, so the schema already documents query/state/county/queries and their constraints, making 3 the baseline. The prose adds some framing (list queries share one state and county scope; each list entry counts as one lookup) but no format or syntax detail the schema lacks.

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?

States a specific verb and resource: 'Look up any US land parcel by street address or parcel number (APN)'. It also enumerates what is returned (address, place, APN, state/county, Fabrica status), which separates it from browsing siblings like search_land or list_land_for_sale.

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?

Gives clear conditions for use: single 'query' vs a 'queries' list under one state/county scope, the 5-candidate ambiguity path, and the degraded fallback when the US parcel search is not answering. It stops short of naming sibling tools (e.g. search_land, check_county_coverage) as explicit alternatives, so routing is inferred 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?

Annotations already declare the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds meaningful domain context the annotations don't: it explains the pool-based lending model and warns that loan records include legacy peer-to-peer loans from a retired integration, which materially affects how an agent should interpret the results.

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?

Front-loaded with the core purpose and an enumeration of returned data, with the sibling pointer immediately after. The closing sentences on pool-based lending and the retired P2P integration are informative but slightly long for what they add.

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?

There is no output schema, so the description carries the burden of describing returns, and it does so by listing loan counts, loans, liquidity/utilization, average APR, and recent events. It is largely complete for a read-only overview tool, with only minor gaps such as pagination behavior for the loan results.

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 100%, so all five parameters (limit, since, lender, status, borrower) are already documented in the schema, including the status enum and defaults. The description adds no additional parameter semantics, so the baseline of 3 applies.

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?

States a specific verb+resource (lending market overview) and enumerates exactly what the overview contains: loan counts, loans, pool liquidity/utilization, average APR, and recent loan events. It explicitly names the sibling get_fabrica_loan_book as the source for the whole-history distribution, so an agent can distinguish the two without opening either schema.

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 routes the agent away from this tool for the loan-to-value/state/outcome distribution, pointing to get_fabrica_loan_book. It gives clear context for what this tool is for, though it does not state explicit when-not conditions or prerequisites beyond the sibling pointer.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: counts derive from loan records, and where the pool data source's counters disagree, both values are shown — an important reconciliation caveat an agent would otherwise not know.

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?

It is a single dense sentence front-loaded with the core purpose, and each clause maps to real output content rather than filler. The long enumeration is heavy but almost every item earns its place by describing a returned section.

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?

There is no output schema, so the description must carry the return-value burden — and it does, itemizing every section the response contains (counts, principal, LTV bands, exposure, APR/duration spread, repayments, liquidations, monthly originations, largest loans with property pages). Nothing essential to calling or interpreting the tool 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 100% with enums on status, groupBy and provider, so the schema already carries the parameter semantics. The description alludes to the same dimensions ('by status and provider', 'by state and acreage') but adds no syntax, defaults, or interaction rules beyond what the schema documents — the baseline 3 applies.

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 verb and resource ('Get the lending history of the Fabrica protocol') and enumerates the concrete distributions returned (loan counts, LTV bands, APR spread, originations by month, largest loans), so an agent knows exactly what this returns. It does not, however, distinguish itself from related siblings such as get_fabrica_lending_market or get_fabrica_stats, which an agent may hesitate between.

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 states what data is covered ('Covers DeFi lending pool loans and historical peer-to-peer loans') but gives no when-to-use, when-not-to-use, or alternative-tool guidance. Nothing tells the agent why it should pick this over get_fabrica_lending_market or get_fabrica_stats for lending figures.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered without the description. The description adds scope context (aggregate over a tokenized land-trust network) but says nothing about freshness/refresh cadence, caching, or how expensive the call is — meaningful gaps for a network-wide aggregate endpoint.

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?

A single front-loaded sentence carries the verb, the scope, and the full metric inventory with no filler. The inline gloss on Fabrica ('where US land is held in trusts represented by tokens') is slightly explanatory overhead, but it earns its place for an agent unfamiliar with the domain.

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?

With no output schema, the description does the right thing by enumerating the returned metric categories, which is the main thing an agent needs to decide whether this call answers the question. The remaining gap is the absence of any note on data staleness or call cost, but for a parameterless read-only endpoint this is close to 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?

The tool takes zero parameters, so there is nothing for the schema to document and nothing the description needs to compensate for. Baseline 4 applies; the description correctly avoids inventing filter semantics it does not support.

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 verb and resource ('Get network-wide statistics for Fabrica') and enumerates exactly which metrics are returned (properties, value, lending volume, TVL, geography, contract addresses), so the agent knows the surface covered. It does not, however, differentiate itself from overlapping siblings such as get_fabrica_lending_market or get_fabrica_loan_book, which also return lending figures, leaving the agent to infer that this one is the broad overview.

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?

'Network-wide' implies this is the aggregate/overview entry point, which is usable context, but there is no explicit guidance on when to prefer it over the many narrower siblings (get_land_portfolio, get_fabrica_loan_book, get_land_valuation). No exclusions, prerequisites, or alternatives are named.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the breadth of event types returned, which is useful. It says nothing about pagination, ordering, or a suggested use pattern, so it stays at baseline.

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 scope and the default (network-wide) behavior are front-loaded in the first clause, before the event-type enumeration. Tight overall, though the single dense sentence listing event types is slightly heavy for the value it adds.

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?

There is no output schema, so the description carries the burden of describing what comes back, and it does so by enumerating event categories. Combined with 100% schema coverage and read-only annotations, an agent has enough to call it correctly; only result shape and pagination behavior remain unstated.

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 100%, so all five parameters are already documented, including the omit-all-fields behavior on tokenId. The description reinforces the no-argument case but adds no syntax, format, or filtering detail beyond what the schema states. Baseline 3 applies.

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?

Specific verb (get) plus resource (activity feed) with a clearly stated scope: property, wallet, or network-wide when no identifiers are given. It enumerates the covered event kinds (mints, transfers, sales, loans, configuration changes). It does not name a sibling to distinguish itself from, but the scope statement makes its role unmistakable.

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 an explicit selection rule: pass tokenId, slug or address for scoped activity, or omit them for network-wide recent activity. That tells the agent when each behavior applies. It stops short of naming an alternative tool (e.g. transaction-status or property lookups) for adjacent needs.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the county boundary is only included when includeCountyBounds is true, and the return is GeoJSON (relevant since no output schema exists).

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?

Two sentences, no filler, and the core purpose plus output format are front-loaded before the conditional detail. Every clause earns its place.

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?

With no output schema, the description usefully states the return is GeoJSON and that county bounds are conditional. It leaves unstated how slug and tokenId relate (either/or identification), which an agent must resolve from the schema, but otherwise the tool is adequately covered.

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 100%, so the schema already documents all three parameters, giving a baseline of 3. The description restates the includeCountyBounds condition ('only with includeCountyBounds: true'), which reinforces but does not materially extend the schema's own wording.

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?

States a specific verb (Get), resource (parcel boundary of a land property on Fabrica), and output format (GeoJSON), which is enough to separate it from most siblings. It does not explicitly contrast with the closest sibling, get_land_map_image, which is also mapping-oriented, so the distinction (raw geometry data vs. rendered image) is left to inference.

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 'for mapping, spatial analysis, and visualization' implies intended usage but names no alternative tool and no condition for choosing this over get_land_map_image or find_us_parcel. It is implied guidance rather than explicit when/when-not routing.

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?

Annotations already declare this a safe, idempotent, read-only, open-world read. The description adds genuinely useful behavior beyond that: the parcel-boundary rendering with a pin fallback when no boundary exists, the fact that the result is an inline image rather than a URL, and theme/dimension customization. It does not cover image format or size limits, which the width/height caps suggest exist.

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 short sentences, zero filler, and the core capability (static map of a parcel boundary) is front-loaded ahead of the fallback and configuration details.

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?

With no output schema, the description correctly discloses the return shape ('inline image') and the fallback rendering path. It is essentially complete for a read-only image fetch, with only minor gaps around output format/limits and how slug vs tokenId are used.

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 100% and all five parameters (slug, theme, width, height, tokenId) are documented in the schema itself. The description only echoes theme and dimension support without adding format or interaction detail (e.g. whether slug or tokenId is preferred), so the baseline 3 applies.

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?

States a specific verb and resource ('Get a static map image of a land property on Fabrica') and even specifies the rendered content (parcel boundary or fallback pin). The singular 'a land property' implicitly separates it from the sibling get_land_portfolio_map_image, but no sibling is named explicitly, so it falls just short of a 5.

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 is implied by the description's scope (one property's map image), but there is no explicit when-to-use, when-not-to-use, or routing guidance such as when to prefer get_land_boundary or get_land_portfolio_map_image. The agent must infer the choice from the resource noun alone.

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?

Annotations already declare readOnly/idempotent/no-destructive, so the description's added value is the default-exclusion behavior for non-active orders, the sort order of offers (highest to lowest), and the premint/collateral flags with their sale implications. That is meaningful behavioral context beyond the annotation block, though it omits pagination or result-size limits.

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?

Front-loaded with the core purpose and return contents, and each sentence carries information. The density is high and some clauses (e.g., listing every returned field inline) could be tightened, but there is no 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?

With no output schema, the description must carry the return-value burden, and it does: it details the listings/offers, their fields, sort order, expiry formats, and premint/collateral status. An agent has enough to call it and interpret results 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 100%, so the schema already documents all four parameters, including the status enum and minOfferUsd. The description reinforces the status default but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb (get) and resource (order book for one land property on Fabrica) and enumerates exactly what is returned: lowest active listing, all listings, and sorted offers with price, counterparty, expiry, restrictions, and documents. This distinguishes it from siblings like get_land_activity and get_land_property without opening any schema.

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 explains the default filtering semantics ('Expired, canceled and filled orders are left out unless status is all'), which implies when to switch modes, but it never names an alternative tool or states when to prefer this over get_land_activity or search_land. Usage is implied rather than guided.

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?

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds a meaningful behavioral caveat beyond annotations: counts and totals always cover the whole wallet even when properties are paged, which is important for interpreting limit/offset results.

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?

Two sentences, front-loaded with the core purpose and followed by the one non-obvious behavioral detail. There is no redundant or filler 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?

With no output schema, the description does the right thing by naming the return sections: properties, loans, orders, credit history, and total value. It also clarifies pagination scope. It stops short of describing response structure, but is complete enough for an agent to call it 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 coverage is 100%, so the schema already explains address, limit, and offset. The description adds useful semantics by indicating that paging applies to owned properties while counts and totals remain wallet-wide, clarifying how the parameters affect the returned data.

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 and resource ('Get a wallet's land portfolio') and enumerates exactly what the portfolio includes: properties, loans, orders, credit history, and total value. This makes it readily distinguishable from narrower siblings like get_land_property or get_land_order_book.

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 is implied by the portfolio scope: an agent can infer this is the aggregate wallet view. However, the description does not explicitly say when to use this versus single-property or market-specific siblings, nor does it mention exclusions 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds useful context by disclosing the return format ('Returns an inline image') and theme/dimension support, but says nothing about rate limits, error cases, or empty portfolios.

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 tight sentences with the core purpose front-loaded and no filler. The theme/dimension sentence is somewhat redundant with the schema but is short enough not to bloat the definition.

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 read-only image tool with full schema coverage and no output schema, the description supplies the key missing piece: that the result is an inline image rather than a URL or JSON. Only minor gaps (empty-portfolio behavior, response format specifics) remain.

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 100%, so all four parameters (theme, width, height, address) are already fully documented with defaults and ranges. The description's mention of 'dark/light themes and custom dimensions' merely restates that, adding no syntax or format detail 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?

States a specific verb ('Get') and resource ('static map image') with clear scope: 'all land properties a wallet owns'. This implicitly separates it from get_land_map_image (single land) and get_land_portfolio (data, not image), though it never names those siblings explicitly.

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 explains what the tool returns but gives no when-to-use guidance and never mentions alternatives like get_land_map_image or get_land_portfolio. An agent must infer from the scope wording alone whether this or a sibling is 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?

Beyond the readOnly/idempotent annotations, it discloses return-level behavior: fees is null when none assessed, flags return an empty list when none apply, a replaced premint ID returns the successor, and the host may decline a fullscreen request. These are non-obvious semantics an agent could not infer from annotations or schema.

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?

Front-loaded with the core purpose, then grouped sensibly (record contents, lifecycle/fees/flags, routing notes, display, owner names). Dense and long, but nearly every clause carries distinct information; a little pruning of repeated display wording would help.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: it enumerates the record fields, lifecycle stages, fee/approval states, flag semantics, and successor behavior for replaced premint IDs. An agent has enough to call and interpret the result 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 coverage is 100%, so slug, tokenId and display are already documented. The description elaborates on display: fullscreen and the host-decline behavior, but that detail is largely duplicated from the schema's own enum description, so it does not add much beyond baseline.

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?

Names a specific verb and resource ('Get the full record of one land property on Fabrica (Sepolia Testnet)') and enumerates the returned facets, distinguishing it from siblings like get_land_boundary and get_land_trust_documents that cover sub-parts of the record.

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?

Explicitly routes boundary geometry to get_land_boundary, deed-grantor names to get_land_trust_documents, and states third-party parcel owner names are never returned. It gives clear context for use but never states an explicit 'use this when you need X' trigger or exclusion beyond those two handoffs.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavioral context beyond them: the provenance of the signal (Property Taxes Current check, DeFi lending pool block reason, both, or disagreement), the check/expiry timestamps, the borrowing-limit effect, and an explicit statement of unavailable data. It stops short of auth or rate-limit details, so a 4 rather than 5.

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?

Front-loaded with the core answer (what the status is) before drilling into signal sources and metadata, and the closing sentence on limitations earns its place. The first sentence is long and clause-heavy, which slightly hurts readability but not content density.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: status value, signal source including the disagreement case, checked/expiry timestamps, and borrowing impact. It also preempts the obvious follow-up (amount due/due date) by declaring those unavailable.

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 100%, so slug and tokenId are already documented in the schema, and the description adds no syntax, format, or interaction guidance for them. Baseline 3 applies since the schema does the heavy lifting.

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?

States a specific verb (get) and resource (land property tax status) and enumerates the possible outcome values (current, past due, unknown). It is clearly distinguishable from siblings like get_land_property or explain_property_checks because it names its data source (Fabrica's Property checks) and its scope.

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 bounds what the tool is ('a data lookup, not the county's own statement') and states what it cannot return (amount due, due date), which implies usage. However, it never says when to reach for this versus explain_property_checks or check_county_coverage, so routing guidance is 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context: agreement text is only returned when includeAgreementText is true and is long, trust.agreementResource is the MCP resource for this token's own agreement, and owner names are sourced only from Fabrica's deed-grantor records, never third-party parcel data.

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 lead clause front-loads the purpose before the field enumeration, and the caveats (agreement text size, owner-name sourcing, title-search disclaimer) are placed after the core statement. The output inventory is long, but each item is decision-relevant rather than 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?

With no output schema, the description carries the burden of describing the return payload and does so thoroughly, including the conditional agreement text, the MCP resource pointer, and the ownership-data sourcing limits. An agent has enough to call it and interpret results 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 coverage is 100% and every parameter is already documented, including the 150 KB size warning on includeAgreementText. The description ties the flag to a returned field, which adds a little meaning, but largely restates the schema's conditional/default behavior. Baseline 3 applies when the schema does the heavy lifting.

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?

Opens with a concrete verb+resource ('Get the legal record of a tokenized property') and then enumerates the exact artifacts returned: trust, trust agreement, legal description, parcel identifiers, deed reference, uploaded documents. It is clearly distinguishable from get_land_property, which it names as the home of the holder's display name.

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?

Routes the agent to a sibling ('a holder's chosen display name is in get_land_property') and sets a scope boundary ('not a title search or title insurance'). It does not state an explicit when-not condition beyond those two notes, so it stops short of full when/when-not guidance.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds meaningful behavioral context beyond them: what data is returned, that provenance/source/confidence/dates accompany each value, and that the oracle's 'reason' is supplied when a price is missing, which tells the agent to expect partial results rather than a hard failure.

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?

Purpose and scope are front-loaded in the first clause, followed by an enumerated payload list; every element names real returned data rather than filler. The second half is dense — one very long sentence listing five categories — but nothing 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?

With no output schema, the description carries the burden of describing return content and does so in detail, including the missing-price reason case. The remaining gap is that neither parameter is required (0 required) and the description does not clarify whether slug or tokenId is needed, which leaves a real ambiguity for an agent about how to invoke 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 100% for both parameters (slug, tokenId), so the schema already documents them fully. The description adds nothing about how the two identifiers relate or whether slug can substitute for tokenId; per the rubric, full schema coverage puts this at the baseline.

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 ('Get every value the Fabrica API holds for a land property') and then enumerates the payload — estimate plus sources, AVM/Prycd/county assessor figures, signed DeFi valuations, oracle state, report link. This distinguishes it from siblings like get_land_property (raw property data) and the estimation tools, and the closing clause 'it suggests no price' further separates it from pricing/estimate 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?

Usage is only implied: the emphasis on provenance and the note that it 'suggests no price' hints that an agent should call this when it needs raw, sourced values rather than an estimate, but no sibling is named as an alternative and no when-not-to-use condition is stated. There is no routing guidance among the many get_land_* and estimate_* siblings.

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?

Annotations already declare readOnly/idempotent/non-destructive/open-world, and the description adds substantial context beyond them: requests expire 15 minutes after preparation, expired ids surface as 'unknown', and a pending request is re-checked against the live order book. These are exactly the behavioral traits an agent needs to interpret results.

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?

Front-loaded with the core action and result states, then the source tools, then expiry semantics. The parenthetical list of five tools is dense but earns its place; the sentences carry little waste.

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?

With no output schema, the description carries the return-value burden and does so: it specifies the two status values and the hash returned once signed, plus the expiry/unknown edge case. Nothing an agent needs to interpret a response 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 coverage is 100% and the single 'id' parameter is fully described in the schema, including the sr_ prefix. The description only restates that the id comes from a prepare tool, adding no new format or syntax detail, so baseline 3 applies.

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?

States a specific verb and resource ('Get a sign request ... by its id') plus the concrete outcome states (pending or completed, order/transaction hash). It also names the five sibling prepare tools that produce the id, making it clearly distinguishable from get_transaction_status and the other get_* siblings.

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 makes the workflow explicit: this consumes an id returned by make_land_offer, list_land_for_sale, accept_land_offer, buy_land, or cancel_land_order. It stops short of contrasting with alternatives like get_transaction_status or stating when to poll vs. not, so it falls just below full routing guidance.

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?

Annotations already cover readOnly/idempotent/openWorld/non-destructive, yet the description adds real value: it enumerates the four possible status outcomes, lists the returned fields (block, confirmations, sender, recipient, explorer link), and pins the tool to Sepolia Testnet rather than mainnet — an important scope constraint not in the structured fields.

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?

A single front-loaded sentence that packs the action, scope, outcome set, and return fields with no filler. The trailing 'Reads the chain only' is brief and reinforces the safety profile.

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?

With no output schema, the description carries the burden of describing returns and does so — status values, block, confirmations, sender, recipient, explorer link — plus the network scope. Nothing an agent needs to call and interpret this one-parameter read tool 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 100% and the single 'hash' parameter is fully documented with a regex pattern, so the baseline is 3. The description's 'by hash' and the Sepolia/Ethereum framing add context but no syntax or format detail beyond what the schema already provides.

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?

States a specific verb (get), resource (transaction status), and the exact scope (Ethereum transaction on Sepolia Testnet by hash), which cleanly separates it from the many other 'get_*' siblings such as get_tax_status or get_activity.

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 is implied — you call it to poll a transaction's status by hash — but the description never states when to prefer it, what precedes it, or any conditions/exclusions. There is no sibling alternative for this resource, so the omission is less damaging, but no explicit guidance is 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it explains the tool is 'prepared, not sent', returns a signRequest with summary/warnings/signLink/expiresAt/payload=null, stores it for the sign page, and that the server holds no keys and submits nothing. This is exactly the non-idempotent, deferred-signing behavior an agent must know.

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?

Front-loads the core action and price/payment terms before detailing checks and the prepared-not-sent flow. Dense but every clause carries information; slightly long, though justified by the tool's complexity.

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?

With no output schema, the description fully describes the return value (signRequest contents, 15-minute expiry, null payload) and the end-to-end signing flow. Nothing an agent needs to call this correctly 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 coverage is 100%, so the schema already documents all five parameters with descriptions, patterns, and bounds. The description only adds that wallet is the signing address, which the schema already states, so baseline 3 applies.

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?

States a specific verb and resource ('Prepare a listing of a property the wallet holds on Fabrica at a USD price paid in USDC'), including chain and payment currency. It is clearly distinguished from siblings like make_land_offer and buy_land, which handle offers and purchases rather than one's own sale listing.

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?

Gives clear context for use: the wallet must hold the token, and preconditions (already listed, offer at/above price, collateral) are surfaced before action. It never names an explicit alternative tool or a when-not-to-use case, so it falls just short of 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 annotations declaring only the generic mutation profile (readOnly=false, idempotent=false, destructive=false), the description supplies the real behavioral picture: pre-flight checks (property live, wallet doesn't hold it), warning conditions (far from estimate, listing at/below offer, collateralized), a 15-minute expiry, payload null for now, and the explicit safety statement that the server holds no keys and submits nothing.

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?

Purpose and the 'prepared, not sent' distinction are front-loaded, and every sentence carries information. It is a dense single block with several clauses stacked into long sentences, which slightly hurts scannability but not 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?

No output schema exists, so the description must carry the return contract — and it does, enumerating signRequest contents (summary, warnings, signLink, expiresAt, payload) and explaining the persisted state. Combined with the warning and pre-check behavior, an agent has everything needed to call and interpret this 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 100%, so all five parameters are already documented in the schema, including the wallet pattern and the expiresDays default of 14. The description mostly restates that coverage ('wallet is the address that will sign'), adding only the note that the sign page restricts signing to that wallet — a marginal gain over the schema baseline.

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?

States a specific verb and resource ('Prepare an offer to buy a minted property on Fabrica') along with the payment mechanics (USD amount paid in USDC). The framing 'Prepared, not sent' immediately separates it from execution siblings like buy_land or accept_land_offer, so an agent can distinguish it without opening the schema.

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?

Gives clear context for when this applies: the offer is prepared and stored so the sign page can load it, and nothing happens until the person signs. It does not explicitly name the alternative sibling tools (e.g. buy_land for immediate purchase, accept_land_offer for the counterparty side), so it stops just short of full when/when-not/alternatives guidance.

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?

Annotations already declare readOnly/idempotent/openWorld/destructive=false, so safety is covered; the description adds genuine value beyond them by describing the return shape (sorted rows, per-acre price labelled listing vs estimate, distanceMiles with near, per-group counts and location page link) and by flagging that these are Sepolia test properties with no real-world effect. It stops short of auth or rate-limit context, but the return-shape disclosure is substantive for a tool with no output schema.

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?

Purpose and scope are front-loaded in the first sentence, and the remaining clauses (sorting, grouping, distance, testnet caveat) each carry distinct information. It is a dense single paragraph with several run-on clauses rather than a tightly structured one, which keeps it out of the top band.

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?

With 18 optional parameters, no output schema, and nested objects, the description does the work of describing the response shape, grouping mode, distance behavior, and the testnet caveat. Pagination and the meaning of 'Property checks' are left to the schema and the explain_property_checks sibling, which is a reasonable delegation but a small remaining gap.

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 100% and every parameter already carries a description, so the schema does the heavy lifting. The prose recap of sort keys and distance is consistent with the schema but adds no syntax, defaults, or format detail the schema doesn't already state. Baseline 3 is appropriate.

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?

Names a specific verb (search) and resource (US land on Fabrica/Sepolia), and scopes it precisely: 'land for sale and every other property on the network, mostly vacant lots and acreage.' The superset framing ('every other property') implicitly separates it from listing-only siblings like list_land_for_sale, but no sibling is named, so the differentiation is inferential rather than explicit.

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 explains behavioral modes (groupBy yields counts, near yields distance and changes default sort) but never states when to choose this over list_land_for_sale, find_us_parcel, or get_land_property, nor any exclusions or prerequisites. Usage is implied by the tool being a general search, which is the minimum-viable bar.

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