RBSHome

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

Annotations cover read-only/idempotent/closed-world, and the description adds value beyond them: the default resale source (CAD land-value median of comparable lots), which discounts are auto-applied, that every assumption is overridable, and that it is not an appraisal or advice. The note that it 'counts as a property lookup' hints at quota or metering behavior, which is useful context not present in 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?

Dense but front-loaded, leading with the trigger condition before the mechanics and closing with scope caveats. The middle formula sentence is long and semicolon-stacked, but every clause carries information an agent needs.

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 13-parameter calculator with an output schema, the description covers inputs, defaults, outputs, and limits of validity. Minor gap: it frames usage around 'an address and an asking price' while the schema also accepts a lead_id path that skips lookup, which the description doesn't mention.

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 earns extra by explaining the calculation chain that gives the parameters meaning — resale minus flag discounts, closing, holding and buyer margin produce the MAO, and the opening offer is derived from it. It does not enumerate individual parameter formats (that is left to the schema, reasonably).

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 ('Runs RBSHome's offer calculator on a Dallas or Collin County parcel') and enumerates the outputs (MAO, opening offer, line-by-line math, distance from asking). It is clearly distinguishable from estimate_lot_value and comps_for_address, which supply inputs rather than a full underwriting result.

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 an explicit trigger condition: an address plus an asking price, plus a question about deal quality or what to offer. It does not name a sibling alternative or state when not to use it, so it falls 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 cover read-only, idempotent, non-destructive, and closed-world, so the description is free to spend its words elsewhere — and it does: it discloses the CAD-based data provenance and the crucial caveat that Texas does not disclose sale prices, so results are a range rather than an appraisal or sale price. 'Counts as a property lookup' is a genuinely useful quota/metering signal that appears nowhere in the structured fields, and the RBSHome parcel link tells the agent what actionable artifact accompanies the result.

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 trigger condition, then scope, then outputs, then the caveat — a sensible order for an agent scanning quickly. Every clause carries information, though the output enumeration is dense enough that it approaches the length where the output schema would serve better.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with a full output schema and complete annotation coverage, the description supplies everything the agent needs to decide to call it: input scope, what the numbers mean, why they are a range, and what counts against quota. The only omission is a cross-reference to the sibling valuation tools, which is a routing nicety rather than a completeness 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 coverage is 100% and both parameter descriptions are already detailed (address format example, lead_id pattern and 'skips the address lookup'), so the schema does the heavy lifting. The description's 'address (or a lead_id)' restates the either-or relationship implied by zero required parameters but adds no format, precedence, or error-handling detail beyond that. Baseline 3 is the right level here.

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 pairing ('land comps' for a parcel at an address) and enumerates what comes back: appraisal-district values, same-ZIP same-use comps, $/sqft and $/acre quartiles, transfers, and an implied range. It is clearly a valuation-lookup tool rather than a search or ownership tool. It stops short of naming the near-sibling estimate_lot_value, so the agent must infer the boundary from the sibling list alone.

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?

'Use when someone asks what a lot or land at a street address is worth, or for comps' gives an explicit triggering intent, and the county constraint (Dallas or Collin, Texas) bounds applicability. There is no when-not guidance — nothing tells the agent to prefer estimate_lot_value or analyze_deal in the overlapping case of estimating a lot's value.

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, but the description adds genuinely new behavior: the output is non-binding, nothing is sent or stored, and the PDF must be produced manually by re-entering price and terms on the Offer tab. Repeating 'Read-only' is redundant with the hints, which keeps this from a 5, but the workflow caveat is real added value.

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 trigger condition and then densely packed with inputs, outputs, and the manual-PDF caveat in two sentences. It is long but nearly every clause carries information; the only soft spot is the redundant 'Read-only' closer after a full sentence already establishing that nothing is stored.

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 an 11-parameter generation tool with an output schema, the description covers the trigger, the county restriction, the primary/alternate key, the derived-from-analyze_deal workflow, and the downstream PDF step. An agent has everything needed to call it correctly on the first attempt.

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 every parameter is already documented in the schema, including defaults, ranges, and the analyze_deal tie-in for offer_price. The description only restates the optional field list and the address/lead_id duality, adding no format or interaction detail beyond the structured data. 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 concrete verb and artifact ('write or draft an offer letter'), names the required inputs (county-limited address or lead_id plus offer price), and specifies exactly what comes back: a one-page non-binding letter of intent plus an RBSHome link. No sibling tool drafts letters, so the tool is unmistakable from the surrounding set.

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?

Opens with an explicit trigger ('Use when someone asks to write or draft an offer letter for a property') and gives a sequencing directive, 'Use analyze_deal first for a price.' It also documents the alternative input path (lead_id skips the address lookup) and flags that the call counts as a property lookup, which matters for quota-conscious agents.

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/closed-world, and the description adds genuinely new behavioral context: the CAD data source, the fact that Texas does not disclose sale prices, and that no sale price, market value or offer price is returned. This prevents a major misread of the output; it stops short only of discussing staleness, coverage gaps, or failure modes for parcels outside the two counties.

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, and short declaratives ('CAD-based, not an appraisal', 'Counts as a property lookup. Read-only.') are efficient. The long internal enumeration of returned values is partly redundant with the existing output schema, costing a little tightness.

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 one well-documented parameter, an output schema, and rich annotations, the description supplies everything else an agent needs: county coverage, data provenance, the comparable-selection rule, and an explicit statement of what the tool does not provide. No material gap remains 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% and the pattern already encodes the County:account form, so the baseline is 3. The description adds meaning by tying lead_id to the supported county set ('Any Dallas or Collin parcel by lead_id (County:account)'), clarifying the accepted input domain beyond the regex.

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 ('Estimate a land-value range for one Dallas County or Collin County, Texas parcel from appraisal-district (CAD) land values') and immediately enumerates the inputs used (CAD land/improvement/market values, comparable-parcel $/sqft quartiles). An agent can distinguish it from generic lookups like get_property or comps_for_address because it states the derived output and the county 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?

It gives scope conditions ('Any Dallas or Collin parcel by lead_id') and a categorization hint ('Counts as a property lookup'), which implies when to reach for it. But it never names an alternative sibling (e.g. comps_for_address, get_property, analyze_deal) or states explicit when-not conditions, so routing is left partly 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 readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the data is public-record only, limited to two Texas counties, and explicitly contains no sale prices or valuations — a useful negative disclosure that prevents the agent from promising data the tool cannot return.

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 purpose, then scope, then the negative data caveat. Every clause carries information the agent needs and none repeats structured fields verbatim.

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?

This is a single-parameter read tool with full annotation coverage, a 100%-documented schema and an output schema, so return values need no explanation in prose. The description still supplies the county restriction and the no-valuation caveat — everything an agent needs to call it correctly and set user expectations.

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 pattern constraint plus example ('Collin:2771234') already document the id format. The description adds only the provenance hint that the id comes from search or other RBSHome tools, which is marginal beyond what the schema provides; 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?

The description states a specific verb ('Get') and resource ('full public-record summary for one property id') and enumerates the payload (location, owner of record, tax-delinquency, appraisal values, sources with dates). It implicitly separates itself from search by requiring an id 'returned by search', though it never explicitly distinguishes itself from the overlapping sibling get_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?

It gives a clear usage flow: use this after search or another RBSHome tool has produced an id, and it states the geographic scope (Dallas and Collin County, Texas only) which functions as a when-not-to-use condition. It stops short of naming an alternative for cases outside those counties or explaining when get_property would be preferred instead.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful non-annotation context: rows count toward a daily row limit, results are capped at 1,000 rows per filter, default page size is 25, and the tool returns no sale prices, valuations, phone numbers, or emails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and workflow, and most sentences carry operational value, including pagination, row limits, and return omissions. It is dense but appropriately sized for a complex 34-parameter tool; the closing 'Read-only' is redundant with annotations but minor.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, 34 parameters, and available output schema, the description is complete enough to guide correct use. It covers purpose, workflow, pagination, row quotas, return omissions, related tools for attrs and saved filters, and the lead_id handoff to get_property.

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 input schema already documents all 34 parameters, including attrs, pagination, filters, and defaults. The description adds a high-level list of filter categories and repeats the attrs registry warning, but it does not add syntax or format meaning beyond what the schema provides. A 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?

The description states a specific verb and resource: finding tax-delinquent property leads in Dallas and Collin County that match a buy box, using the RBSHome map filter. It also distinguishes the row lead_id as input to get_property. However, it does not explicitly differentiate this tool from the sibling search_properties or motivated_sellers_near 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?

It gives clear operational guidance: call with count_only=true first to size the list, then page through results, and call list_filter_fields before using attrs. It also says saved_filter_id comes from list_saved_filters and lead_id feeds get_property. It stops short of stating when to use this tool instead of siblings such as search_properties.

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 it discloses the ranking signals (12/27-month purchases, built-after-buying, portfolio size), the privacy rule that individuals are counted but never named, the data limitation that Texas does not disclose prices, and that a parcel link is included. Only 'Read-only' merely repeats readOnlyHint, but the rest is substantive behavior an agent could not infer.

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 triggering condition is front-loaded and every subsequent clause carries information about inputs, ranking, or caveats. It is long for a three-parameter tool, and the closing 'Read-only' duplicates the annotations rather than earning 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 an output schema present, the description need not explain return values, and it adequately covers inputs, geographic scope, ranking logic, and privacy/price caveats. It leaves unstated what happens when an address falls outside the two counties or matches no parcel.

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 meaning: it constrains address to Dallas or Collin County, explains that lead_id skips the address lookup, and frames limit as 'best first' by describing the fit ranking. That gives context the schema fields alone do not carry.

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 ('ranks the builders and investor entities active in that ZIP by fit') and makes the output nature concrete. It does not, however, distinguish itself from the sibling find_likely_buyers, which an agent could easily confuse it with.

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?

'Use when someone asks who would build on or buy a lot at a street address' gives a clear triggering condition, and it names the two accepted geographies and the lead_id shortcut. It stops short of stating when not to use it or which sibling to prefer for adjacent questions.

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 past the annotations (readOnly/idempotent/non-destructive/closed-world) by disclosing what is absent (no officers, managers, registered agent, phone or email), how misses are reported (person owner, name not listed), and the 25-entity neighbor cap with parcel counts. 'Counts as a property lookup' is a useful quota/billing hint found nowhere in 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-loaded with the action, geography and owner-type qualifier, and every clause (returned fields, absence caveats, lookup accounting) carries information. The first sentence is long and run-on, which costs some readability.

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?

Coverage limits (two counties only), alternative input forms, negative-case behavior and out-of-scope data are all spelled out, and an output schema exists so return structure needn't be explained. 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 description coverage is 100%, and the schema already documents county enum, account pattern and lead_id format. The description only restates the lead_id-or-county+account pairing without adding format or usage detail beyond what the schema provides, 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?

Specific verb (look up) plus exact resource (owner of record in the Texas Comptroller's franchise-tax registry) and scope (Dallas or Collin County property, LLC/corp/partnership/trust owners). It returns a concrete field list and is clearly distinct from entity-list siblings like find_owner_portfolio.

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 states the triggering condition — owner is an LLC, corporation, partnership or trust — and notes the result tells you when the owner is a person or the registry lacks the name, which effectively signals the non-applicable case. It stops short of naming an alternative sibling (e.g., find_owner_portfolio) for portfolio-wide or person-owner questions.

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 the description goes well beyond that: it discloses the data source and window (27 months of appraisal-district deed dates), the exact scoring signals, weekly rebuild staleness, page size and paging mechanics, and output limitations ('individual buyers are counted, not named', 'not confirmed buyers or offers, and there are no prices'). Those caveats are exactly the context an agent needs before presenting results as leads.

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 sentence states purpose first, followed by scoring mechanics, output shape, paging, and caveats in a logical order with no filler. The first sentence is long and clause-heavy, but every clause carries substantive information rather than restating the name or title.

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 scoring/ranking tool with three parameters, the description covers input requirements, the scoring model, pagination behavior, staleness, linked follow-up tooling, and the epistemic limits of the output. An output schema exists, yet the description's brief mention of reason, mailing city/state, and portfolio_lead_ids is additive rather than redundant. Nothing material is missing 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 description coverage is 100%, so lead_id format, page numbering, and the 1-25 limit are already fully documented in the schema. The description reinforces the paging workflow ('pass page for the next ones') and the 25-per-page cap but adds little semantic detail the schema lacks. Baseline 3 is appropriate when the schema carries the parameter burden.

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: 'Rank the companies most likely to buy a Dallas County or Collin County, Texas lead.' It scopes geography, audience (investor selling/wholesaling), and the scoring basis, which clearly separates it from siblings like find_recent_buyers and find_builders_for_lot.

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 establishes the calling context ('for an investor looking for someone to sell or wholesale it to') and routes the agent onward by naming find_owner_portfolio as the consumer of portfolio_lead_ids. It does not explicitly state when to prefer this over find_recent_buyers or find_builders_for_lot, so selection against those siblings is left partly 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description still contributes non-obvious behavior: a hard result ceiling ('Up to 100 properties') and a source limitation ('Public appraisal-district records only'), which explains why a known property might be absent. It does not discuss pagination, ordering, or what happens when no other properties exist, but with rich annotations and an output schema this is a solid contribution.

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 input anchor followed by what is returned and the coverage caveats. The only wasted token is 'Read-only', which duplicates the readOnlyHint annotation; everything else 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?

For a two-parameter read tool with full schema coverage, rich annotations and an output schema, the description covers the seed input, the returned content, the result cap, and the data-source boundary. Nothing an agent needs to decide whether and how to call it 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 parameter baseline is 3. The description adds real meaning by clarifying that lead_id identifies a source property ('Given one property's lead_id') rather than an owner — a distinction the field name alone obscures — and it restates the 100 cap on limit that the schema enforces.

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 ('list') and a precisely scoped resource ('other Dallas County and Collin County properties held by the same owner of record'), and names the returned payload (tax-delinquent flags and balances). It also fixes the input anchor (one property's lead_id), which distinguishes it from siblings such as find_entity_owner or filter_properties without needing to open their schemas.

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 prerequisite is implied ('Given one property's lead_id'), so an agent knows it needs a seed property, and 'Public appraisal-district records only' signals a data-coverage boundary. However, there is no explicit when-to-use vs when-not guidance and no sibling is named as the alternative (find_entity_owner is an obvious candidate for owner-centric lookups). Usage is inferable but not directed.

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, non-destructive, and closed-world, so the bar is lower, and the description still adds real substance: deed-date provenance, the ranking rules (county purchase count then nearby purchases), the 3-purchase cap per buyer, and explicit data limitations (no cash indicator, no prices, individuals excluded). It stops short of describing auth or rate behavior, but for a read-only lookup the disclosure is strong.

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?

Single dense paragraph with the core purpose front-loaded, followed by ranking, pagination, and caveats in a sensible order. Nearly every clause earns its place, though the long compound opening sentence would read better split.

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 an output schema present, the description need not explain return values, and it still covers provenance, ranking, per-buyer limits, pagination signals, and the key data gaps (no cash flag, no prices, no individuals). Nothing an agent needs to call this correctly or interpret results 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 already documents both parameters, including the 25-per-page size and the lead_id format. The description reinforces pagination behavior ('pass page for the next ones') and mentions total/has_more, but adds little parameter meaning the schema does not already carry, 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 (list) and a precisely scoped resource: entities that bought property within 0.5 miles of a Dallas/Collin lead in the last 24 months, sourced from appraisal-district deed dates. The scope itself separates it from siblings like find_likely_buyers or find_entity_owner, though the description never names those alternatives 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 context of use is implied clearly (find who has been buying near a specific lead), and pagination guidance ('pass page for the next ones') is given. There is no explicit when-to-use versus find_likely_buyers or find_owner_portfolio, and no stated prerequisites or exclusions beyond 'individual buyers are left out'.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavioral context the annotations do not: the dataset has no sale prices, days on market or sell-through rates because Texas does not disclose them, which stops an agent from requesting nonexistent metrics. It does not discuss result volume limits or how unmapped leads are reported.

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 ranking action and with the data-limitation caveat placed last as a qualifier. Every clause carries information; nothing is restated from the name or annotations.

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 a full output schema, complete parameter documentation and rich read-only annotations, the description only needs to frame the metric set and its limits — which it does, covering lead tiers, transfer windows, buyer-type shares and the missing price/DOM data. Nothing an agent needs to call this correctly is absent.

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 seven parameters, including min_score's default and the Tier A = 45+ threshold. The description reinforces semantics ('all tiers and Tier A', the 3/6/12/24-month windows, entity/absentee/out-of-state buyer share) but adds little the schema does not already say, 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?

The description names a concrete verb and resource: rank ZIP codes in Dallas or Collin County by tax-delinquent lead supply and owner-transfer activity. Its aggregate, ZIP-level scope is unmistakably different from the property-level siblings (get_property, filter_properties, search_properties), 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?

Usage is implied rather than stated: the description makes clear this is a market-overview / ZIP-comparison tool, and the 'no prices, days on market or sell-through rates' note usefully tells the agent what it cannot get from it. It never explicitly says when to pick this over siblings like filter_properties or motivated_sellers_near, or when to pass county versus zips.

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 closed-world, so safety is covered. The description adds genuine context beyond them: the explicit content exclusions (no sale prices, valuations, phone numbers or emails) and the privacy behavior of my_research, where the user's notes and free-text fields are only counted and never leave RBSHome. It does not cover latency or section cost, which 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?

Front-loaded with the verb, resource and identifier forms, then ordered from core payload to optional sections to exclusions. It is dense but every clause carries information; the single long paragraph could be broken into bullets for faster scanning, which is the only reason it is not 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?

For a 5-parameter read tool with a full output schema and complete annotation coverage, the description supplies everything an agent needs: accepted identifiers, optional section semantics, and explicit scope limits on both counties and returned fields. Return-value shape is correctly left to the output schema.

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 a 3 is the baseline, but the description adds meaning the schema lacks: it explains that the two identifier routes are alternatives and defines what each optional section actually contains (terrain = slope and flood, history = weekly tax-roll changes, links = county record and free map links, outline = parcel boundary, my_research = saved structured facts). It does not mention history_weeks or its 1–52 range interaction with the history section, leaving one small gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("Get one Dallas County or Collin County, Texas property") and states both accepted identifier forms (lead_id County:account, or county+account). It also enumerates the data domains returned (location, owner, delinquency, appraisal values) and the optional sections, so it is clearly distinguishable from siblings like search_properties or filter_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 by the identifier requirements (this is a single-record detail lookup, not a search), and the exclusion line ("Returns no sale prices, valuations, phone numbers or emails") steers agents away from expecting those. However, it never explicitly names an alternative sibling such as get_tax_sale_history or comps_for_address, nor states when not to use 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 (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is lower; the description still adds provenance (Linebarger's listings for Dallas, constables' notices for Collin), freshness ('updated weekly'), and a genuine trap-avoidance note that bid/judgment figures are from the notice and 'are not sale prices'.

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 sibling-tool routing are front-loaded, which is good, but the first sentence is a very long field-by-field enumeration of return values that largely duplicates the output schema. That bulk dilutes the high-value routing and caveat sentences that follow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema, complete parameter coverage, and full annotations, nothing an agent needs in order to select or call this tool is missing: scope, identifier modes, data source, refresh cadence, returned status values, and figure semantics are all present.

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 the combination rule the schema does not enforce: either lead_id alone, or county plus account. That mutual-exclusivity hint adds real meaning beyond the individual property descriptions.

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 ('List ... county tax-foreclosure sale listings') and pins the scope to Dallas County and Collin County, Texas. It also names the identifier mode ('lead_id, or county with account'), so an agent can distinguish it from generic property tools 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?

Explicitly routes the agent to the right alternative: 'To find listed properties, use filter_properties with the tax_sale_listed attribute.' It also flags that the call 'counts as a property lookup', which is usage-relevant context an agent would otherwise not know.

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 description's trailing 'Read-only' adds nothing. The genuinely new behavioral detail is that the payload includes reset timing and a data-freshness indicator, which signals results may be stale — useful, but modest given the annotation coverage.

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 what is returned, followed by the routing condition. The parenthetical list of quota dimensions is slightly dense but each item is meaningful; nothing is 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 zero-parameter, read-only quota check with an output schema and full annotations, the description covers purpose, when to call it, and the freshness caveat. Nothing an agent needs in order to invoke it correctly is absent.

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 no parameters, so the schema imposes nothing an agent must interpret. Baseline for a zero-parameter tool applies, with no compensating explanation needed or missing.

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 (show today's RBSHome connector allowance usage) and enumerates the tracked dimensions: calls, lead rows, property lookups, saves. It also separates itself from siblings by noting 'other tools report their own limits,' so an agent knows this is the connector-wide quota view rather than a per-tool report.

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 triggering conditions — when the user asks, and before a task that needs more than 10 calls — plus an exclusion clause steering the agent elsewhere for per-tool limits. Both the when and the when-not are present, leaving little 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 the safety profile (readOnlyHint, idempotentHint, non-destructive), so the trailing 'Read-only' is redundant. The description does add real behavioral context beyond annotations: results vary per county in coverage and include data dates, so the agent knows to expect heterogeneous, currency-tagged output.

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 front-loaded sentences, each carrying a distinct instruction (what is listed, when to call, how to drill down). The only waste is the trailing 'Read-only,' which merely repeats the annotation.

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?

An output schema exists, so return shape is out of scope; the description still conveys the semantic content of the response (values, ranges, coverage, dates). For a zero-required-parameter, two-param lookup tool this is fully 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 both parameters are already documented. The description adds marginal meaning — that county controls coverage scope and that section must match the 'section field' of a listed group — but it does not restate the enumeration values or the 60-char limit, which the schema handles.

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 ('List the filters filter_properties accepts') and enumerates the content of each group — core fields with allowed values, attribute filters with units, ranges, per-county coverage and data dates. This is clearly distinct from the sibling filter_properties, which consumes these keys rather than listing them.

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 prescribes the call order ('Call this before using attrs; never guess a field key') and names the section parameter as the route to deeper detail on one group. The agent knows both when to call it and how to escalate to full detail.

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 non-destructive, so 'Read-only' adds little. The genuinely useful additions are the result caps (50 filters, counts only for 10) and the map link in the response, but cost, latency and behavior for empty result sets are not mentioned.

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 short sentences, front-loaded with the core purpose and followed by the optional parameter and the cross-tool routing. The trailing 'Read-only' sentence is redundant with the annotations and is the only word that doesn't earn 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?

For a one-optional-parameter read tool with a full output schema, the definition covers purpose, caps, the optional count mode and the handoff to filter_properties. The only real omission is its relationship to save_filter/list_filter_fields, which would help an agent choose correctly among the filter-related siblings.

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 boolean is already documented, so the schema carries the load. The description adds only a nuance ('up to 10 of them' versus the schema's 'first 10 filters') without making the ordering or cost implication explicit, 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?

The description gives a specific verb and resource ('List the filters the user saved in RBSHome') plus scope (up to 50) and payload (plain-language summary and map link). It routes the agent to filter_properties for execution, distinguishing itself from that sibling, though it doesn't clarify how it differs from the adjacent list_filter_fields or save_filter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states the follow-up path: 'Pass an id as saved_filter_id to filter_properties to run one,' which tells the agent when this tool is a discovery step rather than an execution step. It also implies when to set with_counts (when current lead counts matter), but gives no explicit exclusions or prerequisites.

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 the description goes well beyond them: it discloses the daily row-limit cost, the 25-lead ceiling, the PII exclusion ('returns no phone numbers or emails'), and the geographic coverage boundary. Those are non-obvious operational facts an agent could not 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?

Front-loaded with the usage trigger, then inputs, then outputs, then limits — a sensible order with no wasted sentences. The trailing 'Read-only' merely repeats readOnlyHint, a small 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?

An output schema exists, yet the description still summarizes the shape of results (score-ranked leads with reason tags, owner, links), plus the row-limit cost and PII boundary. Nothing an agent needs to decide whether to call this and how to interpret results 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 every parameter is already documented, including the pattern for lead_id and the radius bounds. The description restates the address/ZIP/lead_id alternatives and radius range without adding format or precedence detail 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+resource ('motivated sellers', 'tax-delinquent leads') and scopes it to an address or ZIP. The returned payload (reason tags, owner of record, lead and map links) is named, so it is clearly distinguishable from generic property search siblings like search_properties or find_likely_buyers.

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 opening 'Use when someone asks for motivated sellers, distressed owners or off-market leads' gives an explicit trigger, and the geography constraint (Dallas or Collin County, Texas) tells the agent when not to call. No sibling tool is named as an alternative, which keeps it 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?

Beyond annotations, it discloses that the tool is create-only, cannot modify or delete existing filters, fails when the name is already used, and has a 20-saves-per-day rate limit. These details explain the non-idempotent and non-destructive behavior and give the agent the operational constraints needed before mutating saved state.

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 short sentences are front-loaded with purpose, mutation scope, duplicate-name failure, and rate limit. No sentence is filler; each carries operational information for 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?

For a two-parameter tool with a complex nested filter, the schema carries the field-level detail and the output schema covers returns, while the description covers persistence, visibility, duplicate failure, rate limit, and non-destructive scope. Nothing essential for correct invocation 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 filter object is exhaustively documented in the schema, including per-field constraints and the list_filter_fields hint. The description adds the name-uniqueness constraint but otherwise does not add parameter meaning beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the exact action and resource: saving a buy box as a new named filter in the user's RBSHome account, with the visible outcome that it appears on the RBSHome map. This clearly distinguishes it from siblings like filter_properties and list_saved_filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly scopes use to creating a new saved filter and explicitly rules out changing or deleting existing filters, and it warns that duplicate names fail. It does not explicitly point to list_saved_filters for checking existing names or filter_properties for previewing, so alternatives are 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?

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), and the description adds the result cap of 10 plus the id/title/url result shape and the fetch handoff. The closing 'Read-only' restates annotation data rather than adding to it, and the explicit return-shape mention is partly redundant with the output schema, which 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?

Four short sentences, each carrying a distinct payload: what it searches, what it returns, the follow-up call, and the alternative tool. Scope and exclusion information is front-loaded with 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?

For a one-parameter read-only search with an output schema and full annotation coverage, the description supplies everything else an agent needs: geographic scope, result cap, result shape, escalation to fetch, and the sibling to use for filtered lists.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents the address/CAD/lead-ID/owner-name formats. The description restates those same four forms with no added syntax, constraints, or edge-case behavior (e.g. what happens with ambiguous owner names).

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 plus resource ('Find ... property records in the user's RBSHome account') and bounds the domain to Dallas and Collin County, Texas. It explicitly separates itself from 'filter_properties' (buy-box lists) and 'fetch' (full record by id), so an agent can route correctly without opening sibling schemas.

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?

Enumerates the accepted lookup keys (street address, appraisal-district account number, lead ID, owner name) and states the exclusion directly: 'Does not filter by criteria; use filter_properties for buy-box lists.' It also gives the follow-up step ('Call fetch with an id for the full record'), so the multi-tool workflow is fully specified.

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=false, so safety is covered. The description still adds real context beyond them: a 25-match ceiling, the geographic restriction to Dallas and Collin counties, the presence of tier and score on lead matches, and the pointer to get_property. Auth or rate-limit behavior is not mentioned, which keeps it just 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?

The core transformation is front-loaded in the first sentence, followed by mode rules, result cap, escalation path, and geography. Every sentence carries information, though the closing 'Read-only' is largely redundant with the readOnlyHint annotation.

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 a complete input schema, a full annotation set, and an output schema that handles return values, the description covers everything an agent needs: accepted query forms, mode-specific requirements, county scope, match ceiling, and the follow-up tool for full records.

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 mode, limit, query, and county are already fully documented, including the 'Collin:2771234' lead ID format and the 3-letter owner minimum. The description restates those same constraints rather than adding new syntax or edge-case meaning, so it sits at the baseline for schema-complete 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 transformation: street address, account number, lead ID, or owner name into RBSHome lead_ids with tier and score. It explicitly separates address mode from owner mode and names the sibling get_property for full records, so an agent can distinguish it from search, filter_properties, and get_property without opening schemas.

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 per-mode conditions: address mode covers Dallas and Collin counties, owner mode requires a county plus at least 3 letters of a name. It also states when to escalate to get_property and confines use to two Texas counties, leaving no ambiguity about alternatives or prerequisites.

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