Moonshot Lab (demo)

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

With no annotations, the description carries the full burden, and it discloses the non-obvious and consequential side effect that stored shopper email is deleted — the most important behavioral fact for an agent to surface before calling. It omits whether cancellation is irreversible, idempotent, or what occurs if the search_id no longer exists, which keeps it 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 short sentences, front-loaded with the DEMO marker and the action, followed by the single risk disclosure. Nothing is padded and every sentence carries information.

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 mutation with no annotations and no output schema, the definition covers purpose and the destructive side effect but says nothing about the success response, failure modes, or irreversibility. Adequate to call correctly, thin on what to expect back.

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 says "search_id from save_search"; the description adds no format, nullability, or lookup detail beyond that. The baseline of 3 applies since the schema does the work.

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 ("Cancel a saved search"), which pairs unambiguously against the sibling save_search. It does not explicitly name the sibling or the create/cancel relationship, but the resource is specific enough to distinguish it from the listing/dealer/inventory tools.

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

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

Usage is only implied: the tool operates on a search previously persisted by save_search, and the schema's required search_id makes that prerequisite inferable. There is no explicit statement of when to use this versus save_search, nor any condition for when cancellation is inappropriate.

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 so well: it discloses that lowest_* keys are UNFILTERED math winners, that recommended_scenario/lowest_*_eligible skip demo-rule-flagged scenarios, that an ineligible scenario is never recommended, what cash=true does, and the 'estimate, not an offer; leases are not modeled' caveat. This is rich behavioral context an agent could not infer from the schema.

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

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

Front-loaded with purpose and the sibling routing, and every clause carries operational information (return keys, eligibility filtering, caveats). It is dense and run-on, with a heavy enumeration of return fields, but given the tool's complexity and the absence of an output schema that content largely 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 complex, 6-parameter tool with no annotations and no output schema, it covers purpose, alternatives, defaults, eligibility semantics, return keys, and limitations. An agent has everything needed to call it correctly and interpret the result.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds value by mapping scenario dimensions (cash down, term, credit tier/APR, trade-in, incentives) and spelling out the cash scenario and the $0 down/60 month/good credit defaults. It complements rather than merely repeats the schema.

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

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

States a precise verb (compare) and resource (financing what-ifs for ONE listing), plus the scope constraint 'side by side in one call'. It explicitly names the sibling it differs from (repeated get_payment_estimate calls / get_payment_estimate for a single scenario), so an agent can route 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?

Gives explicit when-to-use and when-not: 'Prefer this over repeated get_payment_estimate calls' and 'For a single scenario use get_payment_estimate', with a hard limit of 'Up to 6 scenarios'. Alternatives and selection conditions are 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?

With no annotations, the description carries the full behavioral burden and does so: it discloses that every line has a source and confidence, that unknowns become ranges, that payments is null, that states outside the 8 covered return a low-confidence estimate without tax and government fees, and that inputs are not stored. It also sets accuracy expectations ('not an offer, not a quote, not penny-accurate').

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 dense but front-loaded: the core purpose, the covered scope, and the produced lines come first, followed by output-field guidance and alternative routing. Every sentence carries information, though the middle section on output fields is packed tightly and could be marginally streamlined.

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 tool with no annotations and no output schema, the description covers purpose, inputs' effect (trade-in, buyer location), return structure (itemized lines, sources, confidence, ranges, warnings, payments null, tax_location.resolution), limitations, and routing to siblings. Nothing essential for correct invocation appears 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 the schema already documents all 13 parameters, including field-level notes like buyer_zip resolving state/county/city. The description adds little parameter-level detail beyond clarifying trade-in handling (negative equity added, balance due after trade), which is mainly output semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a precise verb and resource: an itemized out-the-door estimate for ONE listing, scoped to the buyer's state, county and city, for the 8 covered states. It enumerates the cost lines it produces and explicitly distinguishes itself from get_price_breakdown (price/fees only) and get_payment_estimate (monthly payment). An agent can route correctly without opening any schema.

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

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

It names alternatives and the exact conditions that select them: 'Use get_price_breakdown instead for only the dealer's listed price and fees, and get_payment_estimate to turn this total into a monthly finance payment.' It also tells the agent to read warnings and explains the trade-in case where the total becomes the balance due.

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. It valuably discloses that the data is fictional and warns against telling users to call or visit (555 numbers), and it notes inventory is paged. It does not disclose auth requirements, error behavior, or rate limits, so gaps remain.

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 tight sentence listing the returned entities, with no wasted words. The important safety warning lands at the end rather than being front-loaded, but the overall size is appropriate.

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 usefully enumerates what a returned dealer profile contains, which is exactly the compensating detail needed. The remaining gap is usage/routing guidance, which the description leaves to the 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 the schema already documents all three parameters, including the dealer_key source and the inventory limit/offset semantics. The description only loosely echoes paging via 'a page of inventory' and adds no format or syntax detail beyond the schema.

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

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

The description names the resource (dealer profile) and enumerates its contents — registry entity, stores with addresses and 555 numbers, group, state rules, and an inventory page — so an agent can tell it apart from the list-style siblings. It lacks an explicit retrieval verb, but the content scope is clear and specific.

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 offers no when-to-use guidance and never mentions the sibling alternatives (list_dealers to find the key, search_inventory for inventory queries). The only routing hint lives in the schema's dealer_key description, not in the tool description itself.

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 exist, so the description carries the full burden and does useful work: it discloses that records are synthetic (method 'synthetic') with per-value provenance, and explains what listing.selling_location contains (link_status, selling_location_id, candidates, flags like group_site_lists_sister_store/multi_store_unstated). It omits error/missing-listing behavior and any auth or rate-limit context.

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

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

The opening sentence front-loads what the record is and its provenance, and every following clause adds concrete field-level information rather than filler. It is dense with nested parentheticals, which costs some readability but no sentence 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?

With no output schema, the description compensates by describing the record's key sub-structures (selling_location link, dealer block) and routing price/fee questions elsewhere. It still leaves the overall response shape and failure modes unstated, so it is strong but not exhaustive for a record-retrieval tool.

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

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

Schema description coverage is 100% and the single parameter is fully documented there. The description restates the same listing_id format (dealer_key:VIN or urn) without adding syntax, validation, or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific resource and scope: a full synthetic listing record with per-value provenance, retrieved by listing_id. It distinguishes itself from get_price_breakdown (compact price/fees) and anchors listing_id to search_inventory, so an agent can tell it apart from its siblings 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?

It names one alternative with an explicit selecting condition ('For price and fees in a compact form, use get_price_breakdown') and implies the upstream flow via 'as returned by search_inventory'. It does not state when this tool is the wrong choice beyond price lookups, 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?

With no annotations, the description carries the full burden and does disclose substantive behavioral context: the media are self-generated SVG placeholders labeled DEMO, are not real car photos, and no video or 360 viewer exists. That is genuinely useful for an agent to avoid misinterpreting results. It remains silent on auth, rate limits, and pagination behavior, so it stops short of a 5.

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

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

Two compact sentences front-load the resource identity, with the DEMO caveats following. The phrasing is slightly dense, but every clause carries information and nothing is padded.

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 sideless read tool with no output schema and no annotations, the description covers what the payload contains and flags its synthetic nature, which is the key risk an agent needs to know. Minor gaps remain around result volume and ordering, but nothing essential to 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 description coverage is 100%, so all three parameters are already documented, including the limit range and type filter values. The description's mention of photo/video/spin echoes the types enum without adding syntax or format 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?

The description identifies the resource clearly ('Media block for a listing') and enumerates what it contains (photo, video poster, spin, rights notes), which cleanly separates it from siblings like get_listing and get_dealer. The retrieval verb is only implicit in the fragment phrasing, but the resource and scope are unambiguous.

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

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

Usage is only implied: the listing_id format ('dealer_key:VIN from search_inventory') hints at the calling sequence, but there is no explicit when-to-use statement, no exclusions, and no comparison against alternatives such as get_listing.

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 at all, the description carries the full burden. It does disclose one genuinely useful behavioral trait the schema cannot: results are a delta of cars that *started* matching after the save/since point, so already-known matches are not re-returned. It says nothing about read-only safety, empty-result behavior, result ordering, or what 'DEMO' implies about data fidelity.

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 economical sentence with the scoping condition front-loaded, no filler. The unexplained 'DEMO.' prefix consumes the most prominent position without telling the agent what it means.

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

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

No annotations and no output schema, so the description is the only place to learn the return shape, pagination/limits, and whether search_id must come from save_search — none of which it covers. For a tool with zero structured behavioral metadata, one sentence is too thin.

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 both parameters are documented there, including the checked_at idiom for `since`. The description only restates '(or after `since`)' without adding format or boundary semantics (inclusive/exclusive, timezone), so it stays at the baseline.

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

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

The clause 'New cars that started matching a saved search after it was saved' names a specific resource (new matches for a saved search) and a precise temporal scope, which distinguishes it from search_inventory (general browsing) and save_search (creation). The weak point is that the verb is only implied by the tool name and the leading 'DEMO.' is unexplained.

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 statement of when to call this rather than search_inventory or save_search, and no prerequisites (e.g. 'requires a prior save_search'). Polling intent is only inferable from the phrase 'or after `since`', and the more actionable hint ('use checked_at from your last call') lives in the schema, not the description.

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 usefully discloses the return content and even the value-wrapper shape ({v, m, c, src}), which helps an agent decode results. However, it never states that this is a read-only/no-side-effect metadata call, nor any auth or caching/rate-limit behavior, leaving basic behavioral facts to inference.

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

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

Two sentences, no filler, and the sibling routing clause is placed at the end where it belongs. The first sentence is a bare noun-list fragment rather than a full sentence, which slightly hurts readability but not density.

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

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

With no output schema, the description must convey what comes back, and it does so at a high level (schema version, states, condition values, sorts, wrapper format). Enough for an agent to know when this returns the information it needs, though the specifics of each item remain unspecified.

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 the baseline is 4. The description appropriately adds no parameter discussion and none is needed.

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 enumerates the specific metadata the tool returns (schema links, schema version, covered states, condition values, search sorts, value-wrapper format), which is enough to identify it as a schema/ontology introspection tool. It clearly distinguishes itself from list_searchable_fields by naming it as the sibling to use for filterable fields. It falls short of a crisp verb+resource statement, reading as a list of return contents rather than 'returns the data model ontology'.

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 explicitly routes the agent away for one case: 'For the list of filterable fields and allowed values, use list_searchable_fields.' That is a concrete alternative with the condition that selects it. It gives no explicit when-to-use guidance for the tool itself beyond implying it is for reading schema metadata.

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, but the description discloses the calculation path, demo APR behavior by credit_tier, $5 rounding and range semantics, demo lender eligibility flags, assumptions, deprecated aliases, and the 'estimate, not offer' limitation. This is strong behavioral disclosure for a tool without 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?

Purpose and routing guidance are front-loaded, and the length is justified by the complex calculation and lack of an output schema. The second sentence is dense, but most details earn their place.

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

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

With no annotations and no output schema, the description still explains return fields, assumptions, total-cost metrics, a deprecated alias, and key limitations such as leases not being modeled. It gives an agent enough context to invoke and interpret the tool correctly.

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

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

Schema description coverage is 100%, so all 13 parameters are already documented in the schema. The description adds useful context about parameter interaction—down payment and trade equity reduce the financed amount, APR or demo APR is selected by credit_tier—but this is largely redundant with the schema, so the baseline 3 is appropriate.

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

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

The description opens with the exact user question and resource: 'what would my monthly payment be' for ONE listing. It clearly distinguishes the tool from estimate_out_the_door, get_price_breakdown, compare_payment_scenarios, and search_inventory.

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 explicitly limits use to ONE set of terms and directs agents to compare_payment_scenarios for multiple down, term, trade, or credit options. It also names alternatives for dealer price/fees, out-the-door totals without payment, and finding cars by payment across listings.

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 and does so well: it states that the tool takes no buyer inputs, computes no tax amounts or total, and that a dealer-advertised monthly payment is ad text rather than a calculation. It also describes output structure details such as price_component labels, source_text, method_text, and tax_treatment metadata.

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 primary purpose and remains dense with useful details rather than filler. It is somewhat long and clause-heavy, but the length is justified by the complexity of the output and the need to route the agent to adjacent tools.

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 lack of an output schema and annotations, the description is complete enough for an agent to call the tool correctly. It explains the returned price components, fee and incentive treatment, tax-rule checks, and the distinction between published ad text and calculated amounts.

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 already provides 100% description coverage for listing_id, including its dealer_key:VIN format from search_inventory. The description reinforces that the tool operates on ONE listing but does not add new syntax or meaning beyond the schema, so the baseline score of 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: seeing what the dealer lists for ONE listing as published, including headline price, MSRP, fees, incentives, and tax/fee rules. It clearly distinguishes this tool from estimate_out_the_door and get_payment_estimate by naming those siblings and describing their different purposes.

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 explicitly says to use this tool to see the dealer's published listing breakdown, then directs the agent to use estimate_out_the_door next for the buyer's total and get_payment_estimate for a monthly payment. It also explains conditional incentive handling, including passing label_raw values only if the shopper qualifies.

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 carries the transparency burden and does disclose a key behavioral trait: the data is 'ready-made demo' (pre-canned, not live inventory), plus the shape of the returned fields. It does not explicitly state side-effect-free/read-only behavior, but for a parameterless catalog getter the residual risk is low.

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

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

A single dense sentence that front-loads the resource and appends the intended consumers. Every clause earns its place; nothing is padded.

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

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

For a zero-param, no-annotation, no-output-schema tool, the description tells the agent what the data is, that it is demo/pre-canned, and how to use it. There is no meaningful remaining gap 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?

The tool takes zero parameters, so the baseline is 4. The description adds value by naming the fields the object will contain (trade_value, payoff), which is not parameter information but does orient the caller.

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

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

Names a specific resource (ready-made demo trade-in scenarios) and its contents (trade_value, payoff, one per state), which is well beyond a tautology. It also distinguishes itself implicitly from siblings by naming the two tools its output feeds, though the term 'state' is left ambiguous (US state vs. status).

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

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

States clear downstream context: the returned values are meant to be passed to estimate_out_the_door or get_payment_estimate. There are no alternatives to choose from and no exclusions stated, but the usage path is unambiguous for a zero-parameter helper.

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. It usefully discloses that this is a fixed fictional/demo dataset (20 dealers, 4 groups), which tells the agent the data is static and pre-seeded. It does not state that it is a read-only operation or mention any auth or rate-limit 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?

One dense sentence that front-loads the core resource ('All 20 fictional demo dealers') before the detail. It is information-rich but slightly sprawling with nested parentheticals; no wasted sentences, though the structure could be broken up.

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

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

No output schema exists, so the description must describe returns, and it does so thoroughly: dealers, stores, hierarchy, groups and per-metro coverage counts. The main gap is the relationship to get_dealer and any scoping/pagination behavior for an agent choosing between the two.

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 clarify beyond the schema. Baseline of 4 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?

It names a specific verb+resource (listing dealers) and precisely enumerates what the response covers: the 20 demo dealers, their stores with group_id/region_id/store_id, the Group→Region→Store hierarchy, the 4 dealer groups, and a metro coverage summary. It does not, however, distinguish itself from the sibling get_dealer, so an agent must infer the list-vs-single distinction.

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

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

There is no when-to-use guidance, no mention of when to prefer get_dealer over this tool, and no note on whether results are paginated or filterable. Usage is only implied by the tool's verb.

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 disclose a key behavioral trait: the full compact list is about 30 KB, warning the agent of a large payload and prompting it to scope. It doesn't cover caching or whether output is static, but the size disclosure is genuinely useful and not derivable 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?

Three sentences, no waste, and the enumeration of content comes first followed by the size warning and the remedy. Front-loaded and every sentence 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?

There is no output schema, so the description must characterize the return value, and it does (fields with types, ranges, operators, example filters plus the 30 KB size). For a read-only introspection tool with no annotations, this is nearly complete, only missing minor notes on freshness/static nature.

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

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

Schema description coverage is 100%, so the schema already documents query, detail, and prefix with examples. The description's 'narrow it with prefix or query' largely restates that, so baseline 3 is appropriate with little added meaning.

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 ('Every filterable ontology field') and enumerates exactly what is returned (type, range/allowed values, shortcut names, operators, example filters). It ties the resource to its consumer ('for search_inventory'), which differentiates it from the adjacent get_ontology sibling.

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 practical usage advice on how to call it ('narrow it with prefix or query'), which is real guidance. However, it never states when to reach for this vs. get_ontology or the other introspection siblings, so the when-to-use-vs-alternative decision is left implicit.

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 so: it states THIS TOOL SENDS NOTHING, that delivery.status is not_sent, that no dealer email is invented (dealer.handoff_contact is null), that synthetic data is labeled DEMO, and that the deal is persisted to a dashboard scoped to store/region/group. It also declares the hard failure condition (no phone, email, or name plus preferred_contact) and that SSN/DOB/income inputs are rejected.

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 trigger condition is front-loaded, followed by contents, then the no-send guarantee, then prerequisites and optional extras — a sensible order for a complex 18-param tool. It is long and has some repetition (the no-price rule for add-ons appears twice), so it is efficient rather than tight.

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

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

There is no output schema, so the description must describe returns, and it does: the JSON package contents plus email.subject/email.text/email.html with no recipient. It also covers prerequisites, privacy scoping, persistence side effects and the DEMO labeling, which is everything an agent needs to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by grouping parameters into meaningful blocks (optional extras the dealer will use: trade_details, buyer_address, financing_details, add_on_interest) and by stating the practical constraint on shopper_contact. It adds policy-level meaning the schema cannot express, notably that financing lines are separate and that add-on interest is never priced.

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 gives a specific verb (builds a handoff package) and resource (structured dealer handoff package for ONE configured deal), and the body enumerates exactly what the artifact contains. It is clearly distinguishable from the pricing siblings (estimate_out_the_door, compare_payment_scenarios) because the package is an assembled deliverable, not a calculator.

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 this when the shopper has picked a car and a deal structure and wants to take it to the dealer" gives a clear triggering condition, and scope exclusions are stated (leases, add-on pricing and payment dates are left to the dealer). It does not explicitly name which sibling produces the upstream deal structure or when to prefer a lesser tool, so it stops short of full alternative routing.

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

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

With no annotations, the description carries the full burden and does so: it discloses that the key is shown once, exactly how to transmit it (X-MoonshotLab-Agent-Key header or ?agent_key= query param), that limits and anonymous access are unchanged, that no personal data is collected, and what downstream parties see.

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 most decision-relevant facts ('Optional and free', key shown once) are front-loaded, and the operational details follow in a logical order. It runs slightly long with the dealer-visibility sentence, but nothing is genuinely redundant.

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

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

There is no output schema, so the description correctly explains the return value (a one-time-shown agent key) and how to use it. For a two-optional-parameter, no-side-effect tool, an agent has everything needed to call it and interpret the result.

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 both parameters are already documented there with their optionality and examples. The description adds only indirect color (no personal data collected, platform appears only in aggregate), 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 (registers) and resource (your agent) and names the concrete artifact produced (an agent key). It is trivially distinguishable from every sibling, which are all read/estimation tools for dealer and inventory data.

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 framed as optional and free, and clarifies that anonymous use keeps working, which tells the agent it can skip this without penalty. It does not need to route to an alternative tool, but it stops short of stating a positive condition for when registration is worth doing.

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 disclosure burden and does well: it warns that the returned search_id is the only handle for reading or cancelling, states the default 30-day expiry and renewability, and flags demo-mode behavior (emails logged not sent, arrivals simulated). It does not say whether repeated saves with the same filters create duplicates, or that saving may require prior registration via register_agent.

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

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

Purpose is front-loaded in the first clause, and each following sentence adds a distinct operational fact (return handle, expiry, alternatives, consent, demo caveat) with no filler. The single dense paragraph could be broken into return/usage/demo segments for faster scanning, which keeps it from 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 23-parameter, zero-required tool with no annotations and no output schema, the description covers the essentials: what is created, what comes back (search_id, expiry), how to consume matches, and the demo-mode caveat. It falls short of complete because it never states what makes a valid search given that every filter is optional, nor how it composes with register_agent or prepare_dealer_handoff.

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, and the description adds real meaning beyond it: it explains the lifetime semantics of expiry (default 30 days, renewable), the purpose of callback_url as an alternative to polling, and the consent precondition on email. It still leaves the 23 optional filters unexplained as a group, so an agent gets no hint about which combination forms a valid search (e.g. radius_miles needing zip).

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 ('Save a car search and get alerted when new cars match') and names the follow-up sibling get_new_matches. It also clarifies the relationship to cancel_search via the search_id ('the only way to read or cancel the search'), so an agent can place it in the workflow 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?

Gives clear usage conditions: use get_new_matches to poll for new cars, or supply a callback_url for push; pass renew_search_id to extend an existing search rather than creating a new one; email alerts only with explicit consent. It never mentions search_inventory as the alternative for a one-off search, so the most likely sibling confusion is left unaddressed.

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 delivers: synthetic data (must be disclosed to the shopper), exact-match vocabulary semantics where 0 often means a wrong value, zero-result hints and zip-based coverage output, near_misses behavior, financeable_only dropping listings, payment assumption defaults, and the 'estimate, not an offer... not penny-accurate' caveat.

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, but the body is a dense run-on covering result fields, payments, coverage, financing and caveats with no headings or grouping. Nearly every clause carries information, yet the volume and lack of structure make it harder to scan than it needs to be.

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

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

For a 52-parameter tool with no output schema and no annotations, the description covers the data model, per-result fields, payment assumptions, zero-result and coverage behavior, and disclaimers. An agent has what it needs to invoke and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3, but the description still adds value: worked filters examples with dotted field paths, the payment_min/payment_max semantics tied to the demo out-the-door estimate, and the best_value score formula. This meaningfully supplements rather than repeats the schema.

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

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

Opens with a specific verb+resource+scope: searching a synthetic demo inventory of ~860 fictional vehicles at 20 dealers across named states. It distinguishes its data universe from real listings and points to compare_payment_scenarios for the scenario-comparison sibling, so an agent can place it without opening the schema.

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

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

Gives actionable routing: check parameter descriptions, widen radius_miles or drop a filter on a zero total, pass max_monthly_payment=300 for 'under $300/month', and use compare_payment_scenarios to compare one car's scenarios. It does not state when NOT to use this versus get_listing/estimate_out_the_door, so it stops short of full exclusion guidance.

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