HeritageDeed AI Title Search

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: expected latency ('takes a few seconds'), the three possible status outcomes, their meanings, and that a downed county service does not block ordering. It omits auth/permission needs and any rate-limit or retry semantics, so it falls 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?

Three tight sentences, front-loaded with the action, then timing, then an outcome-to-action mapping. Every clause earns its place 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?

With no output schema, the description correctly takes on the job of explaining the status return values and their consequences, and adds latency expectations. It is missing input-format guidance, which is the one substantive omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description says nothing about the three required parameters — no format for address lines, whether state must be a two-letter code, or how county should be named. For three required inputs with zero schema documentation, this is a meaningful gap the description does not compensate for.

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 that an address matches a real parcel in the county's records'), and the 'BEFORE ordering' clause ties it to the ordering workflow, separating it from siblings like check_coverage and order_title_search.

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 says when to use it (before ordering) and gives a decision branch for every outcome: 'matched' = safe to order, 'not_found' = ask the user to correct, 'unavailable' = proceed anyway because ordering retries. Nothing is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses useful behavior by stating what is returned (the exact state and county values to pass onward), but omits what happens when a county is not covered, whether that surfaces as a boolean, an empty result, or an error, and any auth or rate constraints.

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 tight sentences with zero filler, front-loaded with the core purpose before the return-value detail. Every clause earns its place.

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

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

For a two-param tool with no output schema and no annotations, the description covers the purpose, the input alias flexibility, and the return shape. It still leaves the failure/uncovered case and the accepted format of state unspecified, which an agent would need to invoke this confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and both parameters are required, so the description must compensate. It usefully clarifies that county can be a borough or city name (Brooklyn, Tampa, Houston), which is real semantic value, but leaves the expected format of state (abbreviation vs full name) undocumented and does not reconcile the county input against the state input.

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: it checks whether a given county can be searched. It also names the downstream consumer (order_title_search) and clarifies that borough/city inputs like Brooklyn or Tampa are accepted, which sharpens the scope. It stops short of explicitly contrasting itself with the sibling list_coverage, so a 4 rather than a 5.

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

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

Gives clear context: call this before order_title_search to confirm a county is searchable, and it explains that the returned values are the ones to feed into that tool. There is no explicit when-not-to-use or a direct comparison to list_coverage, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the status taxonomy, that progress is reported per source, and that failure surfaces an error message. It omits the read-only/no-side-effect framing and any polling or rate-limit guidance, which leaves one meaningful behavioral gap.

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, zero filler, and the most decision-relevant content (the returned status values and the follow-up trigger) is front-loaded. Every clause earns its place.

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

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

For a single-param, no-output-schema tool with no annotations, the description adequately conveys what comes back and what to do next. The only real omission is the origin/format of order_id.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the sole parameter order_id is undocumented everywhere. The description never says where order_id comes from (presumably a prior order-creation call) or what format it takes, so it does not compensate for the coverage 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?

States the resource precisely (order progress) and enumerates the exact status values and per-source detail returned, which lets an agent recognize this as the polling/status-read tool among siblings like get_report or list_coverage. A stronger opening verb is absent, but the content is specific enough to distinguish it.

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: 'When complete, call get_report,' which establishes this tool as the preceding step in a workflow and identifies the correct sibling to follow it. It does not state when NOT to use it or what to do on failure states, so it stops short of full when/when-not coverage.

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

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

No annotations are provided, so the description carries the full load. It describes the return structure in detail and discloses the precondition (order must be complete), which is critical behavioral context. It doesn't mention error behavior if called prematurely or any rate limits, but the main behavioral trait is covered.

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

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

Two sentences: first enumerates the return contents, second states the precondition. Front-loaded with what the tool returns, no wasted words, efficient for an information-dense description.

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 appropriately details the return structure. It also includes the key precondition. The only gap is the parameter documentation and any potential error handling, but for a simple single-parameter tool this is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the schema does not explain 'order_id' at all. The description mentions 'order' implicitly via the get_order_status dependency but does not describe the order_id parameter's format, source, or meaning. Baseline 3 for a simple required ID parameter; the description neither fully compensates nor adds much beyond context.

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?

Clearly states it returns a finished structured report containing specific data fields (property, owner, risk score, findings, chain-of-title, environmental/tax data, sources). This is much more specific than a generic 'get report' and distinguishes it from siblings. However, it doesn't explicitly contrast with get_sample_report, which could also return a report-like structure.

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 requirement: 'Only works once get_order_status reports "complete".' This tells the agent exactly when the tool can be invoked and which sibling must be called first, leaving no ambiguity.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful traits — the sample is a 'real finished report', it covers the Current Owner Search product, and it includes the PDF — but it does not clarify that this is a static example (always the Empire State Building address) rather than a query, which is the key behavioral fact an agent needs.

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

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

A single compact sentence, front-loaded with the 'what' ('a real finished report to look at before ordering') and finishing with the concrete specifics. The parenthetical and trailing 'with its PDF' are informative rather than filler, though the colon construction is slightly awkward.

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, no-output-schema tool, the description supplies the essentials: it is a sample report, which product it demonstrates, and that a PDF accompanies it. Only the static/demo nature and its relationship to get_report remain unstated, which 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?

The schema has zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The only semantic risk is that the hard-coded address might be mistaken for an argument, which the description's framing as a sample mitigates.

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 conveys a specific resource — a sample finished report (Current Owner Search) with its PDF — and the framing 'before ordering' makes clear it is a preview artifact, not a live result. It does not explicitly contrast itself with the sibling get_report, leaving that distinction to be inferred from the word 'sample'.

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?

'to look at before ordering' implies a usage moment (pre-purchase inspection of output quality), which is a reasonable if terse hint. However, it never states when to prefer this over get_report or get_order_status, nor that it is a fixed non-parameterized demo rather than a lookup for the agent's own address.

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

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

With no annotations provided, the description carries the full behavioral burden and falls short: it never states that this is a read-only lookup, whether the content is static, or whether it is scoped to a report/account. The phrase 'legal boundary of a report' hints at a scope but doesn't disclose any actual behavior.

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

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

It is a single short sentence with no padding, which is appropriate for a no-argument getter. However it is a comma-separated noun list rather than a front-loaded statement of purpose, which slightly weakens 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 zero-parameter, no-output-schema tool the description is adequate in that it names the content returned, but it omits the read-only nature and the confusing 'legal boundary of a report' clause leaves the tool's relationship to the report tools unclear. Nothing is badly wrong, but it is only minimally 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?

The tool takes zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to compensate for. The description appropriately spends no words on inputs.

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

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

The description lists the content the tool returns (terms, privacy, refund policy) but is a sentence fragment with no verb, so it only implicitly signals a retrieval operation. The trailing 'legal boundary of a report (what it is and is not)' is vague and does not clearly distinguish it from get_report or get_sample_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?

There is no indication of when an agent should call this versus the sibling tools such as get_report, get_sample_report, or the coverage tools, nor any prerequisites. The only implied usage is 'when you need legal terms', which is left entirely to inference.

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

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

With no annotations present, the description must carry the behavioral load, and it does disclose the return surface: coverage geography, pricing, and report contents. The 'list' framing plus zero parameters makes the read-only, side-effect-free nature self-evident, though the description never states this outright or mentions any auth constraints.

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 tight sentences. The coverage scope is front-loaded, and the second sentence delivers the sole actionable instruction, so nothing 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?

There is no output schema, and the description compensates by enumerating what the caller receives: states, counties, main cities, report price, and report contents. For a zero-parameter, annotation-free listing tool this is sufficient 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless schema is 4. The description correctly implies no input is needed to obtain the full catalog.

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 resource — the coverage footprint (states, counties, main cities) where HeritageDeed runs title searches — plus the two accompanying data points (report price and report contents). It is clearly a discovery/catalog tool, which sets it apart from address- or order-oriented siblings like check_coverage and order_title_search, though it 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?

It gives an explicit when-to-use trigger: 'Call this before ordering if you are unsure of the county.' That grounds the agent's sequencing against order_title_search. There is no stated when-not or fallback alternative, but for a no-arg listing tool the guidance is clear enough.

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

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

With no annotations, the description carries the load and does well: it discloses asynchronous behavior (returns order_id, completion in 1-3 minutes), polling cadence (~20s), cost ('free during the launch period'), and email side-effect semantics ('nothing is sent while email delivery is off'). It omits auth/permission requirements, idempotency, and cancellation/error behavior, but the disclosed context is well beyond a bare restatement.

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 sentence, parameter semantics follow, and the workflow/cost notes close it out. Every sentence carries information an agent needs (order result, poll interval, timing, cost, email behavior) 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?

There is no output schema, so the description correctly covers the return value (order_id) and the entire downstream workflow (poll get_order_status, then get_report). Combined with cost and optional-email behavior, an agent has everything needed to invoke and follow through on this multi-step async operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does: address is defined as house number, street, city, ZIP; state as the two-letter code; county as the county or borough/city alias; email as optional and used only for the report link. Each parameter's expected content and role is clarified beyond the bare schema types.

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 ('Order a title search report for a property') and immediately distinguishes itself from siblings by naming get_order_status and get_report as the follow-on steps. An agent can tell exactly what this tool produces (an order_id for a title search) 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 gives a clear operational sequence: call this to order, poll get_order_status every ~20 seconds until 'complete' (1-3 minutes), then call get_report. That is explicit routing to alternatives with conditions. It does not mention preceding siblings like check_coverage or check_address, so it falls just short of full when/when-not guidance.

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