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?

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower, yet the description adds genuinely useful behavior: the data is from a hand-refreshed table as of 2026-10-16, each answer carries that date, and the live answer is the on-ramp page. It also discloses the boundary that no fee amounts or owner data are 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?

Front-loads the answer (what coverage statuses mean), then outputs, then data provenance, then input format and exclusions. It is dense with useful content, though the long first sentence lists many outputs and could be tightened; no sentence is purely 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 read-only coverage-lookup tool with no output schema, the description covers the status vocabulary (supported/notConfigured/unsupported), the fields returned for a supported county, data freshness/provenance, accepted input formats, and explicit exclusions. That is sufficient for an agent to call it correctly and interpret 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 the schema already documents fips, state, county, and ownerType with patterns, examples, and an enum. The description reinforces input form ('5-digit county FIPS, or a two-letter state with or without a county') and notes ownerType implications indirectly, but adds little beyond the schema. 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 and resource (check on-ramp coverage for a county/state) and enumerates exactly what the tool returns: coverage status, deed/forms, witness requirements, owner questions, and on-ramp steps. It is clearly distinguishable from the read-side siblings like get_property or find_parcel by naming the coverage concept.

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 scopes inputs (5-digit county FIPS or a two-letter state with or without county), and explicitly excludes two adjacent concerns: 'No fee amounts (ask_fabrica has them) and no owner data.' This routes the agent to the right sibling for fees and pre-empts misuse of this tool.

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 (readOnly/openWorld/idempotent/non-destructive) by disclosing that nothing is actually sent, that the user sends the email, that replies come back by email, and that summaries containing a private key or seed phrase are refused. These are non-obvious behavioral facts an agent cannot derive 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?

Front-loads the purpose and routing condition in the first clause, then adds return shape and the no-send/filtering caveats. Each sentence carries distinct information, though the run-on first sentence packs three concerns together, making it slightly dense.

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 describes the return payload (help center section, support email, mailto link). Combined with usage routing, the no-send behavior, and the refusal rule, an agent has everything needed 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 description coverage is 100%, so the schema already documents topic, summary, and tokenId including enums, length bounds, and pattern. The description adds the private-key/seed-phrase refusal rule tied to the summary, but otherwise the schema does the heavy lifting, making the baseline 3 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+resource (hand a question to Fabrica's support team) and names the scope of what it escalates: a stuck onramp, a document question, a dispute. It explicitly distinguishes itself from the sibling ask_fabrica, so an agent can route between 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?

Gives explicit when-to-use conditions: when the documents (ask_fabrica) fail to answer, or when a person is needed. It names the alternative tool and the condition that selects against it, leaving nothing 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/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: that supplying tokenId triggers an additional pass-count in the response, the upper bound of 75342, and an explicit statement that results are not authoritative for title purposes.

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, then the digit legend, then the tokenId behavior, then the disclaimer — a sensible order. Dense but every sentence carries information; only the parenthetical about the old name is arguably trimmable.

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 and no required parameters, the description carries the burden and mostly does: it explains the encoding, the optional lookup behavior, and the conditional pass-count in the response. It stops short of describing the response shape when only a score 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 coverage is 100%, so baseline is 3, but the description goes beyond it by decoding the score's positional structure (ten-thousands = recovery status, thousands = past title, hundreds = ownership, tens = onchain history, ones = basic validation) and clarifying that each digit is a category value, not a count, plus the 75342 ceiling that the schema's generic maximum obscures.

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 property's Property checks from its numeric encoding — and immediately disambiguates the name from what it decodes ('formerly called the confidence score; the tool name keeps it'). No sibling tool does anything comparable, so an agent can route to it unambiguously.

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: pass a numeric score to decode it, or a tokenId to have it looked up and counted. The closing disclaimer ('a starting point for your own research, not a title search or title insurance') sets expectations but is not a when-to-use-vs-alternative rule and names no sibling tool.

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 annotations (readOnly, idempotent, openWorld, non-destructive), it discloses the rate limit (30 lookups/minute per client), that the tool creates nothing, that ambiguous queries return up to 5 candidates matched by parcel number only, that a degraded search falls back to Fabrica's own records flagged 'match: unconfirmed, matchSource: fabrica-index', and that owner names are never returned. This is unusually rich behavioral context.

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 fields, and every sentence carries operational weight (rate limit, fallback semantics, no owner names). It is one dense paragraph rather than a structured list, and a couple of clauses ('it starts an on-ramp only when a person opens it and decides there') are wordier than needed, keeping it off 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?

With no output schema, the description fully carries the burden: it enumerates the returned fields (address, place, APN, state, county, token ID, property link), explains the candidate/ambiguity shape, and defines the unconfirmed fallback semantics. 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: query accepts either a street address or an APN, and state/county are the tie-breakers that narrow an ambiguous result set to one parcel receiving the full Fabrica check. That interaction between parameters is not expressible in the schema alone.

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 ('Resolve') and resource ('US street address or parcel number (APN) to a parcel'), then enumerates exactly what is returned. This clearly separates it from siblings like search_properties, get_property, and check_coverage, which an agent can distinguish 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?

It gives strong contextual guidance: address vs APN input, how state/county narrow an ambiguous query, what happens when the US parcel search is unavailable, and that links.addToFabrica only starts an on-ramp when a person acts on it. It does not explicitly name a sibling alternative (e.g. search_properties) or state when not to use this 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine context beyond them: the breadth of event types returned and the important semantic that omitting all identifiers broadens scope to the whole network rather than erroring. It stops short of describing pagination or ordering of the feed.

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 before the long enumeration of event types. The second sentence ('Covers transaction history and event timelines') is largely redundant with the first, but the overall length is reasonable for a tool with three distinct modes.

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 and full parameter documentation, the description covers what an agent needs to invoke it: the three scope modes and the event taxonomy. Gaps remain around result ordering and whether the feed is paginated, which matters for a history-retrieval tool but do not block correct invocation.

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 identical no-identifier fallback note on tokenId. The description repackages the property/wallet split but adds no syntax, format, or combination semantics beyond the schema, 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 and resource ('Get the activity feed') and precisely delineates three scopes: property, wallet, and network-wide fallback when no identifier is supplied. The enumerated event categories (mints, transfers, sales, loans, liquidations, config changes) further pin down what 'activity' means. An agent can select this tool 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?

The description clearly explains the routing logic between the three modes: slug/tokenId for property activity, address for wallet activity, and nothing for network-wide recent activity. It does not, however, explain when to prefer this over adjacent tools like get_property or get_portfolio, nor does it state any exclusions or combined-filter behavior.

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 description only needs to add behavioral context — and it does: the amount is explicitly an estimate, the binding rate comes from a live quote at borrow time, and it explains why the pool may show no capacity (tax status, oracle checks). That is real added value beyond structured fields, though it doesn't discuss auth requirements or rate limiting.

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 in the first clause and the two closing sentences ('The amount is an estimate...') carry important caveats. The middle is a single heavy run-on sentence enumerating return fields and enum values, which is dense but largely earns its place given there is no output schema.

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 of describing returns, and it does so thoroughly: pool liquidity and max loan, existing loan status, no-capacity reasons, the limitedBy enum values, collateral price and LTV derivation. An agent has enough to interpret the response and set expectations about estimate vs. live rate.

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 slug and tokenId, so the schema already carries parameter meaning. The description adds nothing about how slug vs tokenId are used or which is required, 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?

Opens with a specific verb+resource: 'Get borrowing options for a specific tokenized property', then names the exact payload (pool liquidity, max loan, durations, existing loan status, limiting factors). This is clearly distinct from siblings like get_lending_market (market-level data) or get_valuation (property valuation), so an agent can route to it without opening a 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?

Provides an implied usage cue by stating the user question it answers ('How much can I borrow against this property?'), which helps an agent recognize the intent. However, it never states when NOT to use it or which sibling to prefer for adjacent questions (e.g. get_lending_market for pool-level rates), so guidance stays 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds useful domain context about pool-based lending and that historical retired P2P loans are included in records, but says nothing about result size, pagination behavior, or freshness/latency.

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 with the payload description front-loaded, which is the right ordering. The second sentence is background framing rather than operational guidance, but it is short and does clarify an otherwise confusing data caveat.

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 explaining return contents and it does so enumeratively (counts, loans, liquidity/utilization, APR, recent events). Filtering and pagination semantics are left entirely to the schema, which is adequate here but leaves the aggregate-level vs list-level result shape ambiguous.

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 limit, since, lender, status (enum), and borrower all documented in the schema. The description mentions none of these filters and adds no syntax or interpretation beyond what the schema already states, 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?

Names a specific verb and resource ('Get an overview of the Fabrica lending market') and enumerates what the overview contains: loan counts, loans, pool liquidity/utilization, average APR, and recent loan events. It is clear what the tool does, though it does not explicitly distinguish itself from near-siblings like get_protocol_stats or get_borrow_quote.

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 when-to-use statement, no exclusion, and no reference to any alternative tool despite several plausible overlaps (get_protocol_stats, get_borrow_quote, get_activity). The second sentence explains domain history (retired P2P integration) rather than telling the agent when to pick this tool.

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), yet the description still adds real behavioral context: expired/canceled/filled orders are hidden by default, offers are sorted descending, and the response surfaces premint status and whether the property is collateral for an active loan with implications for a sale. Only the vague 'with what that means for a sale' clause keeps it from a 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?

Purpose is front-loaded in the first clause, and the long field enumeration is dense but informative for a tool with no output schema. It reads as one run-on inventory rather than cleanly separated sentences, which slightly hurts scanability.

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 describe the return payload, and it does so thoroughly: field-by-field contents, dual-currency pricing, seller/buyer role, ISO and relative expiry, buyer restrictions, disclosure documents, premint and loan-collateral flags. Nothing an agent needs to interpret the result 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%, including an explicit enum description for status, so the schema already carries the parameter burden. The description's mention that excluded orders reappear under status 'all' restates the schema rather than adding new semantics, so the 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 and resource ('Get the marketplace order book for one property') and then enumerates exactly what it returns: lowest active listing, all listings, and offers sorted high-to-low with prices, counterparties and expiry. An agent can distinguish it from get_property, get_lending_market and search_properties 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?

Usage is only implied: the tool is for inspecting listings and offers on a given property, and 'links to the property page, where offers are made' hints at the follow-up workflow. It never names an alternative sibling or states prerequisites/exclusions relative to get_property or search_properties, so the agent must infer when this is the right call.

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 safety is covered. The description adds a genuinely non-obvious behavioral fact: counts and totals always cover the whole wallet even though the property list is paged. It does not mention auth requirements, rate limits, or error behavior for invalid addresses, but with annotations carrying the safety profile this is solid added context.

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 tightly packed sentences with zero filler, front-loading the resource and then the contents; the paging/totals caveat is placed immediately after the paged item it qualifies.

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 aggregation tool with no output schema, the description does the essential work of enumerating the returned sections and explaining the paging/total relationship. It leaves minor gaps, such as behavior for a non-existent or non-contract address, but nothing an agent needs in order to invoke 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?

Schema description coverage is 100%, so limit and offset are already documented and the baseline is 3. The description adds meaning beyond the schema by noting the results are paged and, importantly, that pagination does not shrink the counts/totals — semantics an agent could not infer from the parameter descriptions alone.

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 (a wallet's Fabrica portfolio) and enumerates exactly what the portfolio contains: owned properties, active loans (borrower or lender), marketplace orders, credit history, and total value. This clearly separates it from siblings like get_property, search_properties, and get_lending_market.

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 scope (one wallet, keyed by address) clear, which implicitly tells the agent to use it for wallet-level aggregation rather than per-property lookups. However, it names no alternatives and gives no explicit when-to-use/when-not-to-use guidance relative to siblings like get_lending_market or get_activity.

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 still adds real value by disclosing the return medium ('Returns an inline image'), which is absent from annotations and from any 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?

Three short sentences, front-loaded with the core action and followed by output format and options; nothing is padded. The theme/dimension sentence mildly duplicates the schema but is not wasteful.

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 covers the return format (inline image) and the option surface, and annotations handle safety. It omits edge cases such as wallets with no properties or invalid addresses, but is otherwise sufficient for correct invocation.

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 address, theme, width and height are already documented with ranges and defaults. The description restates theme and dimension support without adding syntax, units, or constraints beyond the schema, 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 with scope: a static map image of all properties owned by a wallet. The 'all properties owned by a wallet' framing implicitly separates it from get_property_image and get_property_map, but it never names those siblings explicitly, so an agent must infer the boundary.

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 by the scope phrase; there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_portfolio (data) versus this (visual). An agent can guess the intent, but nothing is 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: fees is null when none are assessed, flag lists are empty when none apply, and an old premint ID returns the successor token. It doesn't discuss auth requirements or pagination/volume, but the disclosure is well above the annotation 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 purpose is front-loaded in the opening clause and the rest is organized as a return-content inventory plus scoping statements. It is long and enumerative but nearly every clause carries information the agent cannot get elsewhere (no output schema), with only 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?

With no output schema, the description carries the full burden of describing returns and does so comprehensively: legal description, valuation, tax status, property checks encoding, ownership, loans, listings, activity, media, lifecycle stage, fee state, duplicate-claim flags, and successor-token behavior. Nothing an agent needs to call or interpret this 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 coverage is 100% and both parameters (slug, tokenId) are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level meaning, such as whether slug or tokenId is preferred or how they interact, so it neither helps nor hurts.

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 (retrieve comprehensive details about a specific tokenized property on Fabrica/Ethereum Mainnet) and explicitly distinguishes itself from two siblings, get_property_map (boundary geometry) and get_trust_documents (full legal record). An agent can select this over the near-neighbours 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?

Routing is provided by the two explicit boundary statements: boundary geometry lives in get_property_map and the full legal record in get_trust_documents, so the agent knows what this tool will and won't cover. It lacks an explicit 'use when you have a slug or tokenId' trigger and doesn't mention search_properties for discovery, so it's clear context without a complete when/when-not rule.

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 and open-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations cannot convey: the response is an inline image, and a pin marker is substituted when no parcel boundary 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?

Three tight sentences, front-loaded with the core purpose before the fallback and option details. The final sentence overlaps with what the schema already says about theme and dimensions, but it is brief and not wasteful.

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, and the description usefully explains the return is an inline image, so that gap is covered. However, all five parameters are optional and the description never clarifies whether slug or tokenId is the identifying input, leaving an agent unsure how to form a valid call.

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 documents every parameter including enums, defaults and min/max ranges. The description only restates themes and custom dimensions generically, adding no syntax or default information beyond the schema; 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: a static map image of a tokenized property, with the parcel-boundary behavior spelled out. It distinguishes itself from the sibling get_portfolio_image by scope (property vs portfolio), but does nothing to separate itself from get_property_map, which an agent could easily confuse with this one.

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?

No statement of when to choose this over get_property_map or get_property. The existence of closely named siblings (get_property_map, get_portfolio_image) makes an explicit routing rule valuable, and none 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so the safety profile is fully covered without description help. The only behavioral statement — that county bounds require includeCountyBounds: true — merely restates the schema's own parameter description, adding little beyond structured 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?

Two tightly bounded sentences with the core purpose front-loaded and no filler. The second sentence is partially redundant with the includeCountyBounds schema description, which costs a point but not the structure.

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 geo tool with strong annotations, the description conveys the return type (GeoJSON) adequately and no output schema is needed. The notable gap is that zero parameters are required, yet the description never clarifies whether slug, tokenId, or both are needed to resolve a property — the main decision an agent faces here.

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, including the county-bounds flag and the large decorative layer caveat. The description adds no syntax, format, or relationship guidance (e.g., whether slug or tokenId is required) beyond the schema, matching the baseline for fully covered schemas.

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 — retrieving GeoJSON boundary data for a tokenized property — which is clear and distinct from most siblings like get_property or get_valuation. However, it never differentiates itself from the spatially-related sibling find_parcel, so an agent choosing between boundary-lookup tools gets no help.

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' gives implied usage context (when the caller needs geometry), but there is no explicit when-to-use versus find_parcel or get_property_image, and no exclusions or prerequisites 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety and determinism profile is covered. The description adds the useful detail that this is protocol-wide (not scoped) aggregation, but says nothing about freshness, caching, or cost despite openWorldHint=true.

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 dense sentence that front-loads the aggregating scope and then lists categories. The list is long but each item is a distinct returned metric, so little is wasted.

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-param, well-annotated read tool with no output schema, the description is nearly complete: it enumerates what the aggregate contains. It stops short of explaining aggregation granularity or whether 'estimated value' is per-chain, but that is a minor 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?

Zero parameters, so there is nothing to disambiguate and the baseline is high. The description correctly signals that the call needs no inputs via its protocol-wide framing.

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 (protocol-wide statistics) for the named platform, and enumerates the exact categories returned (properties, value, lending volume, DeFi pool TVL, geography, contract addresses). This distinguishes it from query-shaped siblings like get_lending_market or search_properties.

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: call it for a protocol-wide aggregate. But there is no explicit when-to-use vs. siblings like get_lending_market (which covers lending specifics) or get_valuation. An agent must infer the aggregation scope on its own.

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 safety is covered. The description adds real value beyond that: the check's provenance ('Property Taxes Current check, the DeFi lending pool's block reason, both, or a note that they disagree'), expiry semantics, and the borrowing-limit implication.

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 answer (current/past due/unknown) before the supporting detail, and every clause carries information about returned signals or scope limits. It is a long single sentence, but trimming it would remove genuinely useful distinctions.

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, yet the description effectively enumerates the return payload: status, signal source, check timestamp, expiry, and borrow impact. Combined with the explicit limitation about county amounts, 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% with only two parameters (slug, tokenId), both already documented in the schema. The description adds no parameter-level syntax or format detail, 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?

Names a specific verb (get) and resource (tax status) and enumerates the exact domain values returned: current, past due, or unknown. It is clearly distinguishable from siblings like get_property or get_valuation because it scopes to tax standing on a tokenized property.

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 frames the tool as 'a data lookup, not the county's own statement,' and states what is not available (amount due, due date), which sets expectations about when to rely on it. It does not, however, name an alternative sibling or state a when-not-to-use condition.

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/no-destroy, so the bar is lower; the description still adds real behavioral context: agreement text is returned only when includeAgreementText is true because it is long, the token carries beneficial interest, and the trustee defaults to the holder. It does not mention auth requirements or rate limits, but the added domain caveats are substantive.

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 resource and its returned artifacts, and the practical gating detail (long agreement text, link always returned) is placed where it matters. It is somewhat long, and the closing sentences about beneficial interest and trustee designation are domain education rather than invocation guidance.

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 work of enumerating return fields and flags the one costly optional artifact, which is exactly what an agent needs. Only the absence of routing guidance against siblings leaves a small 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%, so the baseline is 3. The description only re-states the includeAgreementText gating condition already documented in the schema ('default: false; the link is always returned') and says nothing new about slug or tokenId, so it adds no meaning 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 and resource ('Get the legal record of a tokenized property') and then enumerates exactly what is returned: trust, agreement, legal description, parcel identifiers, deed reference, and uploaded documents. This is far more informative than sibling 'get_property' and lets an agent distinguish the two without opening a 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?

Usage is implied by the resource ('legal record of a tokenized property') and there is a useful scope caveat ('not a title search or title insurance'), but the description never says when to prefer this tool over get_property, get_tax_status, or find_parcel. No alternatives 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the response carries provenance, dates and confidence, includes oracle feed freshness and a missing-price reason, and explicitly does not recommend a price.

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 scoped by a single dense sentence; nearly every clause enumerates a distinct returned element, so little is wasted. It is long and clause-heavy, but the density is justified by the breadth of the payload.

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 takes on full responsibility for describing return contents and does so comprehensively — value sources, dates, confidence, oracle state and report link. Nothing an agent needs to call or interpret 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 coverage is 100% and the schema documents both slug and tokenId, so the description carries no param burden. It adds no format, precedence or lookup-order guidance for the two identifiers, which is the baseline expectation.

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 and then enumerates exactly what 'every value' means: estimate, AVM, Prycd, county assessor, signed DeFi valuations, oracle state, report link. An agent can distinguish it from siblings like get_property or get_lending_market without opening a 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 clarifies the tool's posture ('Presents data with its provenance; it suggests no price') but never states when to prefer it over alternatives such as get_property, ask_fabrica or explain_confidence_score, nor any prerequisites despite both parameters being optional.

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 read-only, idempotent, non-destructive, open-world behavior, and the description adds real context on top: results are US land parcels held in a trust tokenized as ERC-1155, and state/county results carry a fabrica.land location link. It doesn't cover pagination behavior for large result sets or any auth/indexing caveats, so it stops short of a 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?

Four sentences, front-loaded with the core purpose, and each subsequent sentence adds something (count vs row behavior, location link, what a result actually is). No filler, though the trust/ERC-1155 explanation is slightly tangential to invocation.

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 11 optional parameters, no output schema, and no required fields, the description sensibly characterizes the two return shapes (property rows vs grouped counts) so the agent knows what comes back. It could say more about default pagination behavior, but nothing essential to a correct call 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%, including the nuanced minScore default and county/region combination rules, so the schema carries the parameter burden. The description echoes groupBy semantics but adds no new parameter-level detail, making 3 the correct 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 ('Search tokenized real properties on the Fabrica protocol') and scopes it to Ethereum Mainnet. It also distinguishes itself from the single-property sibling get_property by describing filter-based retrieval and grouped counts, so an agent can pick 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?

Usage is implied by the filter/groupBy description, but there is no explicit when-to-use guidance and no naming of alternatives such as find_parcel, get_property, or get_property_map. The agent must infer that this is the multi-result search entry point.

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