Server Quality Checklist

Tool Scores

• abort-actor-runA
  3.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the run must be active and that results include updated run details, but it does not disclose whether aborts are irreversible, whether permissions are required, or what happens to intermediate results. This is a significant gap for a state-changing operation.

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

  Conciseness5/5

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

  A single, tight sentence that front-loads the action and ends with the return type. No filler or unnecessary elaboration.

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

  Completeness4/5

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

  For a simple two-parameter tool with no output schema, the description supplies the essential information: the action, the applicable run state, and the response content. It lacks error-handling context (e.g., what if the run is already finished), but this is a minor gap for a straightforward abort action.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no new parameter-level detail; the phrase 'currently starting or running' reinforces runId semantics but is already implied by the schema.

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

  Purpose5/5

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

  The description states a specific verb ('Abort') and resource ('Actor run'), and qualifies the target state ('currently starting or running'). This clearly distinguishes it from sibling tools like get-actor-run, which reads run details rather than mutating them.

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

  Usage Guidelines4/5

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

  The phrase 'currently starting or running' provides a clear contextual condition for when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, such as checking run status with get-actor-run first.

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

• get-actor-runA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It states the tool returns information but does not disclose potential side effects (none obvious for a get), authentication requirements, or rate limits. The waitSecs parameter hints at polling behavior but is not explained beyond the schema. Description is neutral and does not contradict any annotations since none exist.

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

  Conciseness5/5

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

  The description is a single, tightly packed sentence that front-loads the purpose and lists the returned fields. No fluff or repetition; every element adds information. Ideal conciseness for an agent to parse quickly.

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

  Completeness4/5

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

  No output schema is provided, so the description carries the burden of indicating what the tool returns. It enumerates key fields (status, storages, stats, summary, nextStep), which is sufficient for most agents. It does not mention edge cases (e.g., what happens if the run does not exist) or error behaviors, but given the simplicity of the operation nominal completeness is high. Sibling tools exist but are not referenced, which slightly lowers the score.

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

  Parameters3/5

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

  The input schema already provides clear descriptions for both runId (required) and waitSecs (max wait time). The tool description does not add any additional semantic meaning beyond what the schema covers, so it meets the baseline but provides no extra clarity on how parameters affect the call.

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

  Purpose5/5

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

  The description clearly states the tool retrieves detailed information about a specific Actor runasi and enumerates the data returned (status, storages, stats, summary, nextStep). This distinguishes it from sibling tools like get-dataset-items and get-key-value-store-record, which fetch specific storage data rather than the run itself. The verb 'Get' and resource 'Actor run' make the purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage when you need run-level metadata but does not explicitly contrast with alternatives. It does not state when to use this instead of get-dataset-items or abort-actor-run, and it lacks exclusionary guidance (e.g., 'use get-dataset-items to fetch raw data'). Adequate but not proactive.

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

• get-dataset-itemsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full disclosure burden. It does reveal a key behavioral trait (waits for terminal Actor run state before fetching), which is useful, but it omits other behavioral aspects like error handling, pagination nuances, or response format. It provides moderate transparency but lacks depth.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose and includes a relevant timing constraint. Every word contributes meaning with no redundancy.

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

  Completeness2/5

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

  Given the complexity (8 parameters, no output schema, no annotations), the description is too sparse. It fails to explain the return structure, default behavior, or limitations (e.g., handling large datasets). The minimal context leaves significant gaps for an agent to call the tool correctly in edge cases.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all 8 parameters are already documented in the schema. The tool description adds no additional parameter semantics beyond what the schema provides, aligning with the baseline of 3 for high coverage.

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

  Purpose5/5

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

  The description clearly states the verb 'Get' and the resource 'items (rows) from a dataset', and explicitly ties it to the output of an Actor run. This distinguishes it from siblings like get-actor-run (run status) and get-key-value-store-record (KVS records) without ambiguity.

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

  Usage Guidelines4/5

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

  The description provides clear context on when to use the tool: after an Actor run reaches terminal state ('once terminal'). However, it does not explicitly mention alternative tools or state when not to use it, stopping short of full guidance.

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

• get-actor-run-logA
  4/5.0
  Behavior3/5

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

  Without annotations, the description carries the full behavioral burden. It states what the tool retrieves and hints at the type of run states (live vs failed), but it does not disclose behavior like whether logs are truncated, how pagination works, or any side effects. It is functional but minimal.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the core function and the key usage context. Every part adds value, and there is no repetition of schema details.

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

  Completeness4/5

  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 complete schema coverage, the description provides enough context to choose and invoke it correctly. A bit more detail about the return format or when to prefer sibling tools would be helpful, but this is adequate.

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

  Parameters3/5

  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 no additional meaning to the parameters; it merely frames the tool's purpose.

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

  Purpose5/5

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

  The description names a specific verb ('Retrieve'), a specific resource ('recent log lines for a specific Actor run'), and clarifies its intended use for live progress or debugging failed runs. This clearly distinguishes it from siblings like get-actor-run.

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

  Usage Guidelines4/5

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

  The description communicates when the tool is useful: to inspect live collection progress or diagnose a failed run. It does not explicitly exclude alternatives or name a sibling to use instead, but the context is clear enough for an agent to match its intent to this tool.

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

• get-dataset-listA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries main responsibility. It discloses the important behavior that unnamed datasets are excluded by default and that actor-run outputs are unnamed, but it does not describe the response format, pagination behavior, or potential errors. This is partial transparency.

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

  Conciseness5/5

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

  Two sentences with no wasted words. The first states the action and the use case, and the second provides a critical usage hint. Every part earns its place.

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

  Completeness4/5

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

  The four parameters are fully documented in the schema, and the description covers the main use case and a key filtering nuance. The lack of an output schema is not critical for a basic list operation, though a brief note on return value shape would make it complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description restates the unnamed flag's purpose but does not add meaning beyond the schema, except contextual rationale for why the flag is needed.

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

  Purpose5/5

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

  States a specific action 'List datasets on the account' with a concrete use case: locating a run's output dataset when its ID was lost. This clearly distinguishes it from siblings like get-dataset-items, which targets items within a dataset.

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

  Usage Guidelines4/5

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

  Provides clear context: use this when you need to find a run's output dataset, and explicitly signals that unnamed=true is required for that purpose. It does not mention alternative tools to avoid, so it misses the full 'when-not-to-use' guidance.

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

• get-key-value-store-keysA
  4/5.0
  Behavior3/5

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

  Because no annotations are provided, the description carries the burden of behavior disclosure. It does communicate that this is a paginated read operation, which is helpful, but it does not describe what the returned representation looks like or how pagination continuation is surfaced beyond the exclusiveStartKey schema.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the main operation, includes the pagination qualifier, and then gives a concrete domain hint with expected keys. Nothing is redundant or wasted.

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

  Completeness4/5

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

  For a simple list-keys operation, the description plus a fully-covered schema is largely complete: it names the resource, the operation, pagination, and even relevant expected keys. It would be stronger with a note on whether the response includes just keys or also pagination metadata, but that is a minor gap for this tool.

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

  Parameters3/5

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

  The input schema already covers all parameters with full descriptions (100% coverage), including the requirement for keyValueStoreId and the meaning of exclusiveStartKey. The description adds no additional parameter-specific semantics, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description names a specific verb and resource: listing keys in a key-value store, and adds the pagination behavior. It is clearly distinct from siblings like get-key-value-store-record and get-key-value-store-list, which return a record's value or list stores rather than keys.

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

  Usage Guidelines4/5

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

  The description provides concrete usage context: keys expected in this actor's runs are ORDER_SUMMARY, DEDUP_UPDATE, and STATUS. It does not explicitly name alternative tools or when not to use it, but for a simple list operation the intended use case is clear enough.

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

• get-actor-run-listA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It adds useful behavioral details: sorting behavior when desc=true, account-wide scope (no per-actor filter), the actId field for matching, and that entries contain defaultDatasetId and defaultKeyValueStoreId. It could mention pagination behavior, but the schema covers limit/offset.

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

  Conciseness5/5

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

  Three dense, purposeful sentences: the first states the primary function and the use case, the second removes a potential ambiguity (account-wide, no per-actor filter), and the third connects the results to the companion tools. No filler or redundancy.

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

  Completeness4/5

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

  Even without annotations and an output schema, the description explains the main behavior, scope, sort order, and what the returned entries contain (runId, dataset/KVS ids). It is sufficient for an agent to select and call the tool; the schema fills the remaining parameter details.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context around desc=true and the run-related fields, but it does not deepen parameter meaning beyond what is in the schema; thus a baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb and resource ('List Actor runs for the authenticated user') and clarifies the key ordering behavior ('newest first with desc=true'). It clearly differentiates this list tool from the sibling get-actor-run and get-actor-run-log by framing it as the account-wide entry point to obtain runId values.

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

  Usage Guidelines4/5

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

  Strong usage context: it declares this is the recovery entry point after a client timeout and explicitly states there is no per-actor filter; it tells the agent to subsequently use the id field as runId for companion tools. It does not name the alternative tools explicitly, but the intended routing is clear.

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

• get-key-value-store-listA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral burden. It makes the listing nature and the relevant special case ('unnamed=true to include run-produced stores') clear, which is useful. However, it does not disclose output shape, pagination behavior, or any access prerequisites, so it is only moderately transparent.

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

  Conciseness5/5

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

  The description is two succinct sentences with no wasted words. The main action and scope comes first, and the important behavioral note about unnamed stores is in the second sentence. Every sentence contributes to understanding the tool's purpose.

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

  Completeness4/5

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

  For a simple four-parameter listing tool with no output schema, the description covers the motivating use case and relevant filtering behavior. The only real gap is that it does not describe the shape of the returned list, but the schema and straightforward list semantics make this a minor limitation.

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

  Parameters4/5

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

  The schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds semantic value by explaining that unnamed=true includes 'run-produced stores' and connecting the list operation to locating a store after ID loss, which clarifies why and when that parameter matters.

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

  Purpose5/5

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

  The description identifies a clear verb ('List') and a specific resource ('key-value stores on the account'), and distinguishes this tool from sibling record/key operations by framing it as the way to to locate a store when its ID was lost. The mention of ORDER_SUMMARY / DEDUP_UPDATE / STATUS records gives concrete context that is not available from the tool name alone.

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

  Usage Guidelines4/5

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

  The description gives a clear use case: use this tool when you need to find a run's key-value store after losing its ID. It also explains when to set unnamed=true. It does not explicitly state when to prefer get-key-value-store-record or get-key-value-store-keys, so it lacks explicit sibling exclusions, but the context is sufficient.

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

• get-key-value-store-recordA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that exactly one record is retrieved (a 'single' record) and enriches understanding of the built-in keys, which is beyond the schema. However, it omits details like idempotency, error behavior, or whether it is read-only—though 'Get' implies safety. The added key semantics justify an above-baseline score.

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

  Conciseness5/5

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

  A single sentence that front-loads the main action and resource, then uses a colon to introduce a compact parenthetical list of the most important key-value store records. Every word earns its place; no fluff.

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

  Completeness4/5

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

  For a simple two-parameter GET-like tool with no output schema and no nested objects, the description adequately covers the core purpose and the special records. It could mention the return format or error handling, but given the simplicity of the operation, the current coverage is sufficient.

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

  Parameters4/5

  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 both parameters. The description adds value by enumerating the special values for 'recordKey' (ORDER_SUMMARY, DEDUP_UPDATE, STATUS) and what they map to, which goes beyond the schema's generic 'Key of the record' – hence above the baseline of 3.

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

  Purpose5/5

  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 ('a single record from a run's key-value store'), clearly distinguishing it from sibling tools like 'get-actor-run' (run metadata) and 'get-dataset-items' (dataset items). No ambiguity about what it operates on.

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

  Usage Guidelines4/5

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

  The description names three special keys (ORDER_SUMMARY, DEDUP_UPDATE, STATUS) and explains their meaning, giving clear context for when to use this tool. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.

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

• germane_binoculars--zillow-leads-property-dataA
  4.7/5.0
  Behavior5/5

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

  With no annotations available, the description carries the full behavioral burden, and it does so thoroughly: it discloses paid catalog behavior, minute-to-hour live collection, immediate runId;+status return, polling requirements, and the financial risk of duplicate submission. This goes well beyond the input schema and explains the tool's real runtime behavior.

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

  Conciseness5/5

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

  The description is dense but every sentence earns its place, front-loading the core action (actor call plus output) before covering mode timing, polling workflow, and the duplicate-payment warning. It manages to capture a complex tool's essential behavior without padding or redundancy.

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

  Completeness5/5

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

  For an 11-parameter, multi-mode tool with no output schema and no annotations, the definition is remarkably complete when combined with the schema: it explains mode selection, timing expectations, minimums, dedup, bounds, and post-run follow-up. There is no obvious critical context an agent would need to invoke this tool correctly that is left unaddressed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema itself already documents every parameter and mode interaction; the scoring baseline is therefore 3. The description does add high-level context around modes and run lifecycle, but it does not meaningfully enrich individual parameter semantics beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb plus resource: it calls the Actor "germane_binoculars/zillow-leads-property-data" and retrieves its output results. It names concrete data content (Zillow listings, agent/broker contacts, price/tax history, foreclosure flags, schools), which makes the tool's purpose unmistakable and distinct from the sibling retrieval tools.

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

  Usage Guidelines5/5

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

  The description gives explicit mode-based usage guidance: catalog is instant, other modes launch live collection, and follow-up should use get-actor-run and get-dataset-items. It also includes a strong exclusion/alternative rule: do not resubmit after a client timeout; recover the runId with get-actor-run-list instead.

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