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

There are no annotations, so the description carries the full burden. 'Check whether' strongly implies a read-only, non-mutating operation, and the explanation about authenticated actions adds valuable context. It doesn't explicitly state the return type (e.g., boolean), but the meaning is unambiguous.

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, front-loaded sentence that communicates the exact check and its relevance. No filler or redundancy—every word 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 zero-parameter, no-output-schema tool, this is complete. It explains what is checked, why it matters, and mentions specific authenticated actions. Nothing essential is missing for an agent 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 has zero parameters, so schema coverage is trivially 100% and the description correctly omits parameter details. With no parameters, the baseline is 4 and no additional semantics are 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 uses a specific verb ('Check') and resource ('current session to carsales.com.au'), and singles out two sibling tools ('save_vehicle' / 'make_offer') as the reason for checking. This clearly distinguishes it from tools like 'set_auth' and other search/list tools.

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

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

It states the purpose is to confirm whether authenticated actions will work, which implies use before save_vehicle or make_offer. It gives context but doesn't explicitly name alternatives or say when not to use it, though the reference to authenticated actions effectively routes the agent.

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 discloses that the lookup is 'best-effort' (implying potential failure), that it points to the official state-transport check, and that the manual URL is always returned for verification. This gives users realistic expectations about reliability and provides a fallback.

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 two sentences with no wasted words. 'Free vehicle trust check' immediately conveys the purpose, and the rest specifies scope and limitations. It is well-structured and front-loaded with key 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?

The description lacks explicit details about the return value beyond stating that the manual URL is always returned. It does not specify the structure or content of the automated lookup result, error handling, or what 'trust check' means in terms of output. Since there is no output schema, this is a gap that could affect an agent's ability to interpret the result 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 schema already documents both parameters. The description does not add extra meaning beyond noting that the check is free and covers specific aspects. It does not elaborate on parameter usage or constraints beyond what's in the schema, so it meets the baseline for high-coverage schemas.

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

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

The description explicitly states the tool's function: a free vehicle trust check that verifies registration validity and written-off status via an official state transport source. It distinguishes itself from paid PPSR by noting encumbrance is out of scope. This is a clear, specific purpose that differentiates it from sibling 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?

The description implies when to use it: when you need a free, government-sourced registration and written-off check. It explicitly states when not to use it for encumbrance information (paid PPSR only). However, it does not explicitly name an alternative tool or contrast with siblings, but given the sibling list, no other tool seems to perform this function, so it's adequate.

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 burden of behavioral disclosure. It discloses that the tool performs a 'Pure local diff over free search results' and clarifies that it is 'no paid alert service' – a key behavioral trait that prevents misuse. It also explains the different outputs for search vs. listing watches, which is behaviorally nuanced. However, it does not explicitly state whether the operation is read-only (though implied by 'diff') or the return format, leaving minor gaps.

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 fluff. The primary action and resource are front-loaded, followed by a concise breakdown of watch types and a final clarifying note about the service nature. 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?

For a single-parameter tool with no output schema and no annotations, the description is largely complete: it covers purpose, different behavior by watch type, and the mechanism. It does not explicitly state that the watch must already exist via watch_search/watch_listing, but that is implied by 'saved watch.' The return format is not described, but given the simplicity, this is not a critical 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?

The input schema already describes the only parameter ('Watch name to check') with 100% coverage, so the baseline is 3. The description adds value by explaining how the watch's type (search/listing) affects the result, but this is contextual to the tool, not the parameter syntax. No additional parameter semantics are needed 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 clearly states the action ('Re-run a saved watch') and the resource ('watch'), then specifies exactly what it reports for each watch type (NEW listings for search watches, PRICE DROP for listing watches). This distinguishes it from siblings like list_watches (which probably just lists watches) and watch_search/watch_listing (which create watches). The tool's purpose is unambiguous and context-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 implies when to use it (when you have a saved watch and want changes) without explicitly naming alternative tools. It contrasts with create/remove watch tools by focusing on the 're-run' aspect, but doesn't explicitly say 'use this instead of list_watches when you want a specific watch's diff.' The context is strong enough for inference, but an explicit 'when to use' statement would make it 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?

No annotations are provided, so the description carries the transparency burden. It discloses that the tool 'pulls full details' and 'renders a comparison table,' which is informative. However, it does not mention whether authentication is required, rate limits, error behavior, or explicitly that it is read-only. This is partial disclosure, not comprehensive.

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 a single, efficient sentence that front-loads the purpose and includes the output behavior. It contains no filler or redundant details, making it appropriately concise and well-structured.

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?

Without an output schema, the description partially describes the output as a 'comparison table' but does not specify its structure or what 'full details' entails. It does not mention error conditions, pagination, or auth needs. For a tool that compares up to 3 listings, this is moderately complete but leaves some ambiguity for an agent to make assumptions.

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%: both 'listings' (array with item descriptions) and 'includeImages' have descriptive text in the schema. The description adds little beyond the schema, only reiterating that comparison is by listingId or url. No additional parameter semantics are provided beyond what the schema already states.

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 action: 'Side-by-side comparison of 2–3 listings,' with explicit input methods (by listingId or url) and output ('renders a comparison table'). This clearly distinguishes it from siblings like get_listing_details (single listing) and search_cars (finding listings).

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 implies usage for comparing multiple listings but does not explicitly state when to use it over single-listing tools (e.g., get_listing_details) or search tools. No alternatives or exclusions are mentioned, leaving the guidance implicit rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses best-effort scraping and platform-specific behavior. However, it does not mention potential failure modes (invalid URLs, rate limits), whether the operation is read-only, or what happens when no rating is found. This is acceptable for a lookup 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.

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

Three sentences, front-loaded with the primary purpose, then expanding on platform nuances and a usage instruction. No wasted words; every sentence earns its place. Highly concise and well-structured.

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 low complexity (2 simple params, no output schema), the description covers the main behaviors and use cases. It implies the return values (star rating, review count, seller type) but does not explicitly define the output shape. For a tool of this simplicity, this is largely sufficient, but a clear return format would make it fully 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 100%, so both 'url' and 'name' are already documented. The description adds marginal value by clarifying the url can be 'any listing URL' and that name is echoed, but this largely repeats the schema. Baseline of 3 is appropriate when the schema handles parameter 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?

The description states 'Look up a seller/dealer reputation' with a specific verb and resource, and clearly distinguishes between carsales (scrapes star rating + review count) and Facebook/Gumtree (confirms seller type). This differentiates it from sibling tools like get_listing_details and the search tools, giving an agent a precise sense of what it does.

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 provides clear context: 'Use before contacting anyone' and explains when it is useful vs. when it is less useful (Facebook/Gumtree private sellers). It does not explicitly name alternative tools or give a 'when not to use' exclusion, but the platform distinction effectively guides selection. A slightly more explicit reference to alternatives would push this to 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 provided, the description carries the full behavioral burden. It does disclose meaningful traits: the operation is free, requires no external service, and returns the CSV as a text block rather than a file artifact. It does not disclose limits on CSV size, whether a live search is executed, or any auth requirements, but the core side-effect and return-format behavior are stated.

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

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

Two sentences with zero waste: the first front-loads the action, cost profile, and use case; the second states the return format. Every clause earns its place, and the most decision-relevant facts (free, no external service, output is a text block) appear first.

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?

The description compensates for the missing output schema by stating the return value is a CSV text block, and the input schema covers all 10 parameters. The main gaps are the ambiguous relationship to the search tools (does it run its own search or export existing results?) and no mention of result volume truncation or delivery size limits. Adequate but not fully self-contained.

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 applies. The description adds no parameter-specific detail beyond what the schema already provides, but none is needed — each parameter (make, limit, minPrice, state, etc.) is already documented clearly. The phrase 'a carsales search' does loosely tie the params together as search filters.

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

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

The description names a specific verb ('Export'), a specific resource ('a carsales search'), and a concrete output format ('CSV'), plus the practical benefit ('opened in a spreadsheet'). It is immediately distinguishable from all siblings, which are search, offer, watch, or auth tools — none of which do CSV export.

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 the use case ('so results can be opened in a spreadsheet') and differentiates the approach ('free, no external service'), which implies when an agent would reach for this tool. However, it does not explicitly explain the relationship to search_cars or search_all_cars — whether this runs a fresh search with the given filter params or exports previously fetched results — and names no alternatives or exclusions.

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 meaningfully discloses that the tool may fall back to summary card data when the full detail page is blocked by anti-bot protection, which is valuable non-obvious behavior. It does not mention auth requirements or return structure, but the fallback disclosure is a strong transparency signal for a read-only tool.

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 dense sentences with no filler. The core capability and identifier options are front-loaded, and the fallback behavior is appended without cluttering the primary purpose.

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 3-parameter tool with no output schema and no annotations, the description covers inputs, the fallback behavior, and even names summary-card fields. It does not detail the full output shape or mention auth, but the information provided is sufficient for an agent to invoke the tool effectively in most cases.

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 adds little beyond the schema, mainly confirming that either url or listingId can be used; the schema already provides examples and parameter descriptions. No extra semantic meaning is needed for the parameters.

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

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

The description states a specific verb ('Get full details'), a specific resource ('a single carsales.com.au listing'), and the accepted identifiers (listing id or URL). This clearly distinguishes it from sibling search and comparison tools, since it is explicitly focused on a single listing rather than aggregates.

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

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

The description makes the core usage context clear: use it for a single listing's full details when you have a listing id or URL. However, it does not explicitly contrast with alternatives like search_cars or compare_listings, nor does it state when not to use this tool.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'List all saved watches' but does not mention whether authentication is required, how results are ordered/paginated, what fields are returned, or whether the operation is read-only. This is a significant gap for a tool with zero annotation support.

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, front-loaded sentence that conveys the action and the scope ('all saved watches') plus a parenthetical clarifying the two types. No filler words or redundant clauses. Perfectly sized for a simple listing tool.

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

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

Given the tool's simplicity (no params, no output schema), the description covers the essential purpose. It doesn't specify the return format, but for a list operation that may be inferred from the context or API conventions. The lack of any mention of sorting or filtering is acceptable since there are no parameters. A 4 reflects that it's adequate, not exceptional.

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 has 0 parameters, and schema coverage is trivially 100%. The description doesn't need to explain parameters since there are none. Baseline for 0 parameters is 4, and the description adds no unnecessary param details, so it meets that 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 description states a specific verb ('List') and resource ('all saved watches'), and explicitly differentiates the two watch types ('search watches and listing price-drop watches'). This clearly distinguishes it from sibling tools like watch_search (create) and watch_listing (save), without requiring schema inspection.

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 purpose is clear enough that an agent can infer when to use this tool (retrieving saved watches). It doesn't explicitly state when not to use it or name alternatives, but among the siblings there is no competing list-all tool, so the context is unambiguous. A small deduction for lack of explicit guidance.

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 burden of behavioral disclosure. It explicitly warns of HIGH-RISK (contacts a real person, may involve money), states the best-effort nature ('opens the contact/enquire form and submits your message'), and details the confirm flow (first call returns a warning and does nothing). This is comprehensive transparency that fully prepares the agent for the tool's 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?

The description is concise and well-structured: it leads with purpose, then prerequisites, then behavior/risk, then confirm requirement. Each sentence adds value with no redundancy. It is front-loaded with the most critical information (purpose and risk) and keeps the confirm flow explanation brief but clear.

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

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

Given the tool's complexity (high-risk, authentication, confirm flow), the description covers all necessary aspects: prerequisite (set_auth), behavioral best-effort, risk disclosure, and the confirm requirement with its first-call warning. It does not mention the return value, but since there is no output schema and the action is best-effort, that omission is acceptable. An agent has enough context to invoke 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 5 parameters have descriptions in the schema. The tool description adds general context (best-effort, risk) but does not add per-parameter meaning beyond what the schema already provides. The confirm parameter's behavior is already described in the schema, and the description reiterates it without adding new parameter-specific semantics. Baseline 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 clearly identifies the action: 'Contact the seller / make an offer on a carsales listing'. It specifies the resource (a carsales listing) and the verb (contact/make offer), and distinguishes itself from sibling tools like save_vehicle or check_vehicle by explicitly addressing the seller/enquire action. The mention of authentication via set_auth further sets it apart.

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 provides clear usage prerequisites: it requires an authenticated session via set_auth and mandates confirm: true to actually send. It explains the first-call warning behavior, which is essential for correct invocation. While it doesn't explicitly name alternatives, the purpose is specific enough that an agent can infer when to use it. The guidance is helpful but could be stronger with explicit 'when not to use' or alternative pointers.

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 must carry the burden of behavioral disclosure. It mentions the tool is free, uses free comparable listings, and derives a price band with percentiles, which adds some transparency about the method and data source. However, it does not disclose whether the operation is read-only, whether it requires authentication, or what happens if no comparables are found—gaps that are significant for a tool with no 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?

The description is exceptionally concise at two sentences, with the core purpose front-loaded and no filler words. Every clause earns its place by contributing either the method, the differentiator (free vs. paid), or the optional behavior. It is a model of efficient communication.

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 that there is no output schema and no annotations, this description leaves out substantial operational details. It does not explain the output format (e.g., the structure of the price band or the verdict on a target price), how errors or edge cases (like zero comparables) are handled, or whether state and year filters significantly affect the results. An agent would likely need additional information to call this tool confidently and interpret its response.

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 input schema provides 100% coverage for all six parameters, so the description adds minimal value beyond what the schema already states. It does reinforce that the band is based on same make/model/year, which loosely maps to the year parameters, and mentions the optional 'targetPrice' judgment, but these are essentially restatements of the schema descriptions. With high schema coverage, a baseline 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 clearly states the tool's purpose: deriving a fair-price band from comparable listings, with the option to judge a target price. It distinguishes itself from search tools by focusing on valuation rather than listing retrieval, and it openly notes it avoids paid services like RedBook/CarHistory, setting it apart from potential alternatives.

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 explicit guidance on when to use this tool versus the many search tools in the sibling list (e.g., search_cars, search_all_cars). The description implies it is for pricing questions, but it does not state when a user query should route here rather than to a search tool, nor does it mention any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Delete,' which indicates a mutation, but does not explain whether the deletion is permanent, whether authentication is required, what happens if the watch does not exist, or how the operation signals success or failure. This is a significant gap for a destructive operation without annotation support.

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 a single, concise sentence that gets straight to the point. It avoids unnecessary detail and is appropriately front-loaded. However, it may be slightly under-specified given the lack of behavioral details, but for a simple delete tool, this length is acceptable.

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

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

With no output schema and no annotations, the description must provide enough context for the agent to understand the tool's behavior. It lacks information about return values, error handling, permissions, or side effects. For a mutation tool, this is incomplete; an agent might call it without knowing whether the operation actually succeeded or what the consequences are.

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% coverage for the single parameter 'name' with the description 'Watch name to delete.' The tool description adds no additional semantic meaning beyond that, so it meets the baseline of 3. It does not explain format constraints, case sensitivity, or how to find the exact watch name.

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 ('Delete') and a specific resource ('saved watch'), and clarifies it covers both search and listing watches. This clearly distinguishes it from sibling tools like watch_search, watch_listing, list_watches, and check_watch, which involve creating, listing, or checking watches rather than deleting them.

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

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

The intended use is implied: use this tool when you want to remove a saved watch. However, the description does not explicitly mention when not to use it or point to alternatives (e.g., if you want to create a watch, use watch_search or watch_listing). No exclusions or context are given beyond the basic action.

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 burden of behavioral disclosure. It candidly states 'Best-effort: clicks the Save/Watchlist control on the listing page', revealing the underlying UI automation behavior, and 'Requires confirm: true before any account action is taken', disclosing the two-step confirmation flow. It also notes the authentication requirement. While it doesn't describe failure modes or side effects like pre-existing saves, the transparency is above average for a tool with no 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?

The description is concise, delivered in two sentences with no fluff. The primary action and authentication prerequisite are front-loaded, followed by the best-effort nature and confirm requirement. Every phrase adds value, and the structure is logical and scannable for an agent.

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 tool with three parameters, no output schema, and no annotations, the description covers the essential aspects: the action, the auth prerequisite, the best-effort behavior, and the human-in-the-loop confirmation. It does not explain what the tool returns (though none is specified) or handle edge cases like when a listing is already saved, but given the absence of an output schema and the tool's relative simplicity, the description is reasonably 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?

The input schema already has 100% description coverage, with each parameter (url, confirm, listingId) having meaningful descriptions. The tool description adds little beyond restating the confirm requirement ('Requires confirm: true') and does not provide additional syntax or format details. This matches the baseline of 3 where 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 clearly states the action: 'Save/watchlist a carsales listing to YOUR account', with a specific verb and resource. It also mentions the authentication prerequisite via set_auth, which adds specificity. However, it does not explicitly differentiate from the 'watch_listing' sibling, which may perform a similar operation, so it doesn't fully distinguish among siblings.

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 provides clear context about the requirement for an authenticated session and the confirm flag (human-in-the-loop), which signals when it is appropriate to invoke. However, it does not explicitly state when to use this tool versus alternatives like 'watch_listing' or 'remove_watch', nor does it mention any exclusion conditions. The guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose key behaviors: combining sources, deduplication, tagging by source, and good-deal flags. However, it omits other behavioral aspects such as authentication requirements (siblings include auth_status and set_auth), rate limits, or any side effects, which are relevant for an agent to fully understand what calling this tool entails.

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 two sentences, front-loaded with the core action and scope, and includes the purpose ('one-shot'). Every phrase earns its place—no redundancy or fluff—making it highly concise and easy to parse.

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?

Despite having 12 parameters and no output schema or annotations, the description is brief. It gives a high-level overview but does not explain the return structure (e.g., fields in results), how 'de-duplicated-where-possible' works in practice, criteria for good-deal flags, or whether authentication is needed. This leaves significant gaps for an agent to correctly invoke and interpret the 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?

The input schema has 100% parameter description coverage; every parameter (make, limit, model, state, etc.) is documented with examples and defaults. The description text adds no additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate since 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 clearly states the tool's action: searching both carsales.com.au and Facebook Marketplace simultaneously, combining results, de-duplicating where possible, tagging by source, and flagging good deals. It explicitly positions itself as the 'one-shot find me a car' tool, distinguishing it from sibling tools like search_cars and search_facebook_cars that target single sources.

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

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

The description says 'Use this as the one-shot find me a car tool,' which provides a clear use case for a comprehensive search. However, it does not explicitly contrast this with alternatives (e.g., when to use a single-source search or when to avoid this tool), leaving usage guidance mostly implied rather than explicit.

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

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

With no annotations, the description carries more burden, but it reveals a key behavior: some filtering happens in-memory from listing cards, implying results may be approximate and only from a single page/batch. It does not mention pagination depth, rate limits, or that in-memory filtering may require fetching many pages. It is honest about the mechanics but incomplete regarding scale and freshness.

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, front-loaded with what the tool searches, then supported filters, then the in-memory caveat and return fields. No filler or redundancy.

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

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

For a search tool with 21 parameters and no output schema, the description communicates the main filtering domains and the return shape, which is a good foundation. However, with no output schema and no annotations, it would benefit from stating the listing card's data limitations (e.g., no full descriptions, images, dealer info), whether results are stale, and how page/limit interact with in-memory filtering. It is adequate but not exhaustive.

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 each parameter already has clear meaning. The description adds the important cross-cutting note that price/year/odometer filters are applied in-memory, which is not evident per-parameter. That is genuinely valuable. Baseline 3 is appropriate because the schema already documents parameters fully; the description adds a useful caveat but does not deeply describe interaction effects.

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 a specific resource (carsales.com.au), a specific action (search), and enumerates the supported filter dimensions (make/model, state, body style, transmission, fuel type, condition, badge, keyword) plus what is returned. It clearly differentiates from siblings like search_facebook_cars and search_gumtree_cars by naming the source site.

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 explains what filters are available and that price/year/odometer are applied in-memory, so an agent understands mechanics. However, it does not explicitly say when to choose this over search_all_cars, get_listing_details, or watch_search, nor does it state whether this should be used for viewing vs. saving vehicles. No explicit exclusion criteria are given.

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

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

With no annotations, the description carries full responsibility. It discloses a key limitation: 'Best-effort: depends on Facebook not blocking the request from your IP.' However, it omits other behavioral aspects such as authentication requirements, error handling, or read-only status. The single caveat is useful but the coverage is thin.

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 compact (three sentences) and front-loads the core purpose. The caveat about blocking is placed at the end, and the technical phrase 'native, hardened through the same browser/proxy engine as carsales' adds minor noise but does not undermine clarity. Efficient overall.

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?

The description covers the return fields (price, title, location, seller, photo) which is important given no output schema. However, it lacks details on pagination, ordering, error conditions, or whether authentication is needed (siblings include set_auth/auth_status). For a tool with 5 parameters and no output schema, this is moderate but not exhaustive.

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% with clear descriptions for all five parameters (query, limit, location, minPrice, maxPrice). The tool description adds no extra parameter semantics beyond the schema, so it meets the baseline but provides no added value.

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 clearly states the verb and resource: 'Search Facebook Marketplace for cars' and explicitly lists the return fields (price, title, location, seller, photo). This distinguishes it from sibling tools like search_gumtree_cars and search_cars, making 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.

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

The description implies Facebook-specific usage but does not explicitly compare with alternatives or state when not to use it. No mention of using search_all_cars for aggregated results or other exclusions. Usage is inferred from the tool name and first sentence, but not stated explicitly.

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 must carry the behavioral disclosure burden. It does disclose a key limitation ('depends on Gumtree not blocking the request from your IP') and implies read-only search, but it does not mention authentication requirements, rate limits, or error handling. The coverage is partial; more detail on failure modes would be needed.

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 two sentences, front-loading the primary action and immediately stating the output format. It includes the essential caveat about blocking without unnecessary detail. This is efficient and well-structured.

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 search tool with 6 parameters, no output schema, and no annotations, the description is sparse. It does not explain how parameters interact (e.g., whether radius requires location), pagination, result ordering, or potential error scenarios. An agent may correctly call it for a simple query but lacks guidance for complex or edge-case usage.

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 each parameter (query, limit, radius, location, minPrice, maxPrice) is already documented in the schema. The description adds no additional semantic meaning beyond what the schema provides; it only notes the output fields, which do not relate to parameter usage. 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 clearly states the verb ('Search'), the resource ('Gumtree.com.au'), and the domain ('cars'), and specifies the output fields (price, title, location, link). It distinguishes itself from siblings by naming the specific site, though it does not explicitly contrast with search_facebook_cars or search_all_cars.

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 context (native, FOSS, no paid API) and a caveat (best-effort, may be blocked), but it does not state when to prefer this tool over the sibling search tools (search_cars, search_facebook_cars, search_all_cars). No explicit usage guidance or exclusions are provided.

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 burden. It discloses that cookies are stored at a specific path (/root/.carsales-mcp/cookies.json), and that the action enables authenticated operations. It does not explicitly state overwrite behavior or validation, but the intended effect and storage location are clear.

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 consists of two dense sentences with no wasted words. It front-loads the purpose, then provides the storage path and a practical sourcing suggestion. Every sentence adds value.

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-parameter tool with no output schema, the description is surprisingly complete. It explains what the tool does, why it matters, where cookies are stored, and how to construct the input. No essential context is missing for an agent 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 schema already covers the parameter, but the description adds valuable guidance on how to obtain the cookies (from DevTools > Application > Cookies or a cookie export extension). This goes beyond the schema's generic description and directly instructs the agent on the format and source of the value.

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 clearly states the tool's purpose: importing a login session via cookies, with the specific benefit of enabling authenticated actions like saving vehicles and making offers. It distinguishes itself from sibling auth_status by its direct action (setting vs. checking) and is specific about the resource (carsales.com.au session).

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 implies when to use it (when you need authenticated access to carsales) and even explains the underlying purpose (so the server can save vehicles, make offers, contact sellers). However, it does not explicitly mention alternatives like auth_status or state when not to use it, leaving the routing partially 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?

No annotations are provided, so the description carries the full burden. It discloses that it's FOSS (no paid service), that it watches for price drops, and that check_watch must be re-run later. However, it doesn't state side effects (e.g., whether a watch record is created, duplication behavior) or prerequisites (like auth), leaving some behavioral gaps.

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 two compact sentences. It front-loads the core purpose ('Watch a SINGLE listing for a PRICE DROP'), then adds the FOSS note, the follow-up action (check_watch), and platform support. Every word earns its place with no redundancy or padding.

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 simple 3-parameter, 1-required tool with no output schema, the description is fairly complete. It explains the purpose, the necessary follow-up, and supported sources. It omits details like what happens on success or error, but these are minor given the tool's simplicity and the availability of sibling tools for auth and listing checks.

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 input schema has 100% description coverage, so each parameter (url, name, listingId) is already documented with clear purpose and examples. The description adds context (supported platforms) that helps interpret the url parameter but does not introduce new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Watch' with a precise resource 'a SINGLE listing' and a concrete goal 'for a PRICE DROP'. It clearly distinguishes from sibling tools like watch_search by emphasizing 'SINGLE', and it specifies supported platforms (carsales, Facebook, Gumtree), leaving no ambiguity about what the tool does.

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 explicitly directs the user to re-run check_watch later to see price changes, establishing a clear workflow. It implies a use case (single listing vs. search) by emphasizing 'SINGLE', but does not explicitly name watch_search as the alternative for search-based watches. However, the context and sibling list make the intended usage fairly clear.

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 burden. It discloses that this is a FOSS (open-source) alerts service and lists supported sources with carsales as default. It also implies statefulness by referencing check_watch to see new listings since the last check. However, it does not mention authentication requirements (e.g., set_auth), whether the watch persists, what the tool returns on success, or any error scenarios. With several behavioral unknowns, this is adequate but not comprehensive.

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 two sentences plus a source list, totaling ~30 words. It is front-loaded with the core action and workflow. The parenthetical "(FOSS alerts - no paid service)" adds a selling point but is not essential to usage, making it slightly extraneous. Overall, it is concise and well-structured, though a shorter version could omit that detail.

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 9 parameters, no output schema, and no annotations, the description should provide more context to ensure correct usage. It gives the essential workflow (save then check_watch) and lists sources, but it does not explain prerequisites like authentication (set_auth), how the watch interacts with other tools (list_watches, remove_watch), or what happens when the watch is saved successfully. This is sufficient for a basic understanding but leaves several operational details undocumented.

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 input schema has 100% coverage with descriptive parameters for all 9 fields. The description adds only the source defaults (carsales, gumtree, facebook) which the schema already covers via the sources parameter description. There is no additional explanation of parameter semantics beyond what the schema provides. Since the schema does the heavy lifting, a baseline of 3 is appropriate; the description does not add meaningful value.

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 uses the specific verb "Save" with the resource "a search to watch for NEW listings", which clearly indicates this tool creates a persistent watch on a search query rather than a single listing. It also mentions re-running check_watch, which differentiates it from immediate search tools like search_cars. This makes the tool's purpose unambiguous and distinct from its siblings.

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 provides a clear usage pattern: save a search first, then re-run check_watch later to see new listings. This implies the tool is for ongoing monitoring, not immediate results. However, it does not explicitly state when to use this over search_cars or other search tools, nor does it mention alternatives like search_facebook_cars. The guidance is clear for the intended workflow but lacks explicit exclusions.

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