No key needed. Search real products and live dealer inventory, price-check, keep standing wants.
Scored across 13 tools
Most tools map clearly to distinct actions, and the pairings like create/cancel/list_watches or request/introduction_status are easy to tell apart. The main ambiguity is among demand.ask, demand.search, and demand.find_vehicle, which all find purchasable things, though their descriptions provide reasonably clear usage boundaries.
All tools share the consistent 'demand.' prefix and lowercase snake_case style, which is good. However, the second half mixes verb_noun patterns (create_watch, cancel_watch) with noun-like names (health, price_check, introduction_status), so the convention is not perfectly uniform.
Thirteen tools is well within a coherent scope for a commerce/search API that supports discovery, vehicle-specific search, standing watches, introductions, and protocol discovery. Each tool has a plausible role and none feel redundant.
The tool descriptions repeatedly reference demand.create_want as the way to commit a want, but that tool is not actually present, which creates a dead end for the core commit-to-buy workflow. The set otherwise covers search, watches, pricing, and introductions, but this missing referenced operation is a significant gap.
Talk to iwant.fyi in plain language to find something to buy. Call this when the user's request is conversational or incomplete - e.g. 'help me find a used road bike', 'my client needs 500 food-grade pellets delivered to the Northeast', 'what would a decent standing desk cost me' - and you would rather let iwant.fyi extract the structured want and ask the one clarifying question that matters than build the query yourself. Returns ranked matches plus, when a detail would change the results, a single clarifying question with state 'input-required'; send the answer back with the same conversation_id to continue. Prefer demand.search when you already have a clean title and constraints. Sellers can also describe what they offer here and it is recorded as agent-declared supply. Nothing is saved as a Want; use demand.create_want to commit.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | What the user wants, in plain language. Include budget, condition, and location when known. | |
| conversation_id | No | Returned by a prior demand.ask call. Pass it back to continue the same conversation (for example to answer a clarifying question). |
| Name | Required | Description |
|---|---|---|
| reply | Yes | What to tell the user |
| state | Yes | completed or input-required |
| intent | No | |
| matches | No | |
| match_count | No | |
| conversation_id | Yes | |
| clarifying_question | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false) already establish safety. The description adds valuable behavioral context beyond annotations: it states nothing is saved as a Want, describes the clarifying-question mechanism with state 'input-required' and conversation_id continuation, and notes that seller offers are recorded as agent-declared supply. This fully discloses the tool's interaction pattern without contradicting 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 longer than average but information-dense; every sentence contributes to usage guidance, behavioral disclosure, or example. It is front-loaded with the main action and purpose, then expands into when-to-use, then the interaction flow. While not minimal, it avoids redundancy and stays focused on the agent's decision-making needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered externally. The description explains the conversational flow (clarifying question, conversation_id continuation), the non-persistent nature, and the seller use case. It also provides routing guidance to siblings. There is no missing information an agent would need to correctly invoke this 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 coverage is 100% and both parameters already have descriptive comments (message includes budget/condition/location; conversation_id explains it is returned by prior call and used to continue). The description reiterates the conversation flow ('send the answer back with the same conversation_id to continue') but adds no new semantic information beyond what the schema already provides. Baseline 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 purpose: 'Talk to iwant.fyi in plain language to find something to buy.' It distinguishes itself from siblings by explicitly contrasting with demand.search ('Prefer demand.search when you already have a clean title and constraints') and demand.create_want ('use demand.create_want to commit'). This makes the tool's role 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 provides explicit when-to-use guidance: 'Call this when the user's request is conversational or incomplete' with concrete examples. It also gives the alternative: 'Prefer demand.search when you already have a clean title and constraints.' Additionally, it covers the seller use case ('Sellers can also describe what they offer here'), leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a standing want by id. Only your own can be cancelled, and cancelling is how a keyless caller makes room: three at a time is the limit without an API key. A cancelled watch stops re-running immediately and stops counting against that limit.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | Yes | The watch id from demand.create_watch / demand.list_watches | |
| client_ref | No | The same opaque reference you created the watch with. Required to cancel a keyless watch; ignored when you send an API key. |
| Name | Required | Description |
|---|---|---|
| id | No | The watch that was cancelled. |
| cancelled | No | True when the watch was found and deactivated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond the annotations: a cancelled watch stops re-running immediately and stops counting against the keyless limit. It also surfaces the ownership restriction and the API-key/keyless distinction. This adds useful runtime semantics that readOnlyHint=false alone would not convey.
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 compact sentences earn their place: the main action, the key constraints, and the after-effect. The most important information is front-loaded, and there is no repetition of schema content.
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 two-parameter cancellation tool with a full output schema and clear annotations, the description covers operation, ownership, quota mechanics, and immediate effect. Nothing an agent needs to decide whether and how to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents watch_id and client_ref thoroughly. The description adds context about ownership and the keyless quota, which indirectly illuminates why client_ref matters, but it does not add specific parameter-level 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 opens with 'Stop a standing want by id' — a specific verb and resource that immediately identifies this as the cancellation counterpart to demand.create_watch and demand.list_watches. It also clarifies the ownership constraint ('Only your own can be cancelled'), which distinguishes it clearly from any admin or cross-account operation.
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 when cancellation matters: it is how a keyless caller makes room under the three-watch limit. This gives clear context for choosing cancel_watch when quota is tight or a watch is no longer needed. It does not enumerate alternatives explicitly, but none are needed because cancellation is the obvious inverse of create_watch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover which optional protocol features this server supports (webhooks, idempotency, failure transparency, error taxonomy) and its operational limits (rate limit, maximum standing watches, minimum watch interval). Call once when you connect and adapt to the answer - skip webhook setup if 'webhooks' is absent, and respect the limits rather than discovering them by being throttled. Free, instant, no side effects. Protocol v1.1 §8.2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| limits | No | Operational limits to respect. |
| features | No | Optional features supported, e.g. webhooks, idempotency, failure_transparency, error_taxonomy. |
| protocol_version | Yes | Demand-protocol version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'Free, instant, no side effects' and adds practical behavioral guidance like 'call once' and adapting based on the answer. It goes beyond the annotations by describing performance and idempotent usage, without contradicting them.
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 three sentences with no redundancy. It leads with purpose, immediately gives actionable usage guidance, and closes with a protocol reference. 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?
Given the presence of an output schema (which will define the return structure), the description covers why to call, when to call, and how to use the result. It also notes the tool is side-effect-free, which is sufficient for a capabilities discovery endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is an empty object, so schema coverage is effectively 100%. The description adds no parameter details because none exist; the baseline of 4 is appropriate since there is nothing to clarify.
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 clear verb ('Discover') and a specific resource ('optional protocol features... and its operational limits'), listing concrete examples (webhooks, idempotency, rate limit, etc.). It is distinct from sibling tools like demand.health or demand.list_constraints, which focus on status or constraints, not feature discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call once when you connect' and instructs how to adapt: skip webhook setup if 'webhooks' is absent, and respect limits to avoid throttling. While it doesn't name alternative tools, the context makes it clear this is the initial discovery call. Slight deduction for not explicitly contrasting with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a STANDING WANT: keep searching for what the user wants to buy and get notified when a NEW match appears, across sessions. Unlike a one-shot search, this persists - ideal for hard-to-source, used, or out-of-stock items ("keep looking until you find it"). Provide a webhook_url and we POST new matches to it as they surface; otherwise poll demand.list_watches. Same query shape and enforced constraints as demand.search. WITHOUT AN API KEY this works too, under limits: no webhooks, three standing wants at a time, a six-hour minimum re-check, and a seven-day life. Any limit applied to your request comes back in notes.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | What to keep watching for (3-200 chars) | |
| category | No | Broad kind of thing. Defaults to goods; use services for labour. | |
| min_score | No | Only notify on matches at/above this relevance (0..1, default 0.5) | |
| constraints | No | Machine-evaluable constraints (rules.condition_min, rules.specs). Enforced like demand.search. | |
| description | No | Further detail that did not belong in the title: intended use, acceptable substitutes, what is already ruled out. | |
| price_cents | No | Budget ceiling in cents. $1,200 is 120000. Enforced as a maximum for the life of the watch, so a wrong ceiling means it can never match. | |
| webhook_url | No | https URL we POST new matches to (type: want.matches). Requires an API key - a keyless request naming one is refused rather than silently ignored. | |
| client_token | No | Optional idempotency key (<=128 chars). Retrying with the same token returns the original watch instead of creating a duplicate. (v1.1 §E) | |
| check_interval_minutes | No | How often to re-check, in minutes (>=5 with a key, >=360 without, default 60). A request below the floor is raised and the change reported in `notes`. |
| Name | Required | Description |
|---|---|---|
| notes | No | Any limit applied to your request, stated plainly rather than applied silently. |
| watch | Yes | The standing want as stored. |
| message | No | Human-readable summary. |
| webhook_secret | No | Shown once, on first creation only. Signs every delivery. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint false, openWorldHint true, destructiveHint false), so the description carries the full burden. It discloses persistence, notification via webhook or polling, API-key-dependent limits (no webhooks, three watches, six-hour re-check, seven-day life), and that limits are reported in `notes`. It also mentions idempotency via client_token. No contradictions with 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 moderately long but each sentence adds critical info: the core concept, the alternative, webhook vs polling, keyless limits, and the notes field. It is front-loaded with the key purpose. A minor reduction in wordiness could be achieved, but nothing is 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?
Given 9 parameters, nested objects, and an output schema, the description covers all necessary operational aspects: usage context, alternatives, configuration details, limitations, and idempotency. The existence of an output schema covers return format. No missing piece that 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 each parameter has a description, but the tool description adds substantial meaning: price_cents 'wrong ceiling means it can never match', check_interval_minutes floor behavior, webhook_url requiring an API key and refusal on keyless requests, client_token idempotency, and constraints being 'same as demand.search'. This goes well 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 tool's function: create a standing want that persists across sessions and notifies on new matches. It explicitly contrasts with one-shot search and names the sibling tool demand.search, making it easy to distinguish. The resource (standing want) and action (create) 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?
The description provides explicit when-to-use guidance ('ideal for hard-to-source, used, or out-of-stock items') and contrasts with one-shot search. It also explains the two consumption modes (webhook vs. polling demand.list_watches) and notes that the same query shape and constraints as demand.search apply, giving clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a specific car, truck, SUV or van for sale near the user, new or used, from live dealer inventory. Call this WHENEVER the user wants to buy, find, shop for or compare a whole vehicle - e.g. '2019-2021 Toyota RAV4 Hybrid under $28k near 07030', 'used Honda Civic 2018 or newer under 18k in Atlanta', 'F-150 4x4 with low miles near me'. Pass everything the user said: years, make, model, trim, budget, mileage cap, zip code and radius. Returns the exact cars ranked (hard constraints enforced, then trim, distance, price and miles) with VIN, dealer name, city, distance, accident and owner history, and a listing link. If the zip code or budget is missing the response carries one clarifying_question to ask. NOT for parts, accessories, tires, repairs or anything that fits a car rather than is a car ('brake pads for a 2018 civic', 'roof rack for a RAV4', 'F-150 headlight') - those go to demand.search.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit US zip code to search near (required for local results) | |
| body | No | sedan, suv, truck, coupe, hatchback, minivan, van, wagon, convertible | |
| fuel | No | gas, hybrid, plug-in hybrid, electric, diesel | |
| make | No | Manufacturer, e.g. "Toyota". Optional - it is parsed from `query` when omitted. Pass it only to override what the text says. | |
| trim | No | Trim level, e.g. "XLE". Narrows hard, so omit unless the buyer named one. | |
| model | No | Model line, e.g. "RAV4 Hybrid". Optional; parsed from `query` when omitted. | |
| query | No | The user's request in their own words, e.g. '2020 or newer Chevy Silverado 4x4 under $35k near 75201' | |
| year_max | No | Latest model year to accept, inclusive. Omit for "2019 or newer". | |
| year_min | No | Earliest model year to accept, inclusive. Four digits. | |
| condition | No | "cpo" is manufacturer certified pre-owned. "any" searches all three; omitting it does not exclude used cars. | |
| client_ref | No | Optional stable, non-identifying reference for this end user (any opaque string; we hash it). Lets us count repeat askers without knowing who they are. | |
| mileage_max | No | Maximum odometer miles, e.g. 60000. | |
| radius_miles | No | Search radius, default 50 | |
| price_max_cents | No | Budget ceiling in cents. $35,000 is 3500000. Enforced as a maximum. |
| Name | Required | Description |
|---|---|---|
| cars | Yes | |
| summary | No | |
| search_id | No | |
| match_count | Yes | |
| missing_field | No | |
| sources_consulted | No | |
| clarifying_question | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior, so the description doesn't need to repeat that. It adds useful behavioral details: ranking logic (hard constraints enforced, then trim, distance, price, miles), return fields (VIN, dealer name, distance, history), and the clarifying_question behavior when zip/budget is missing. These are beyond the 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 long but well-structured: it front-loads the core purpose, provides concrete examples, explains return behavior and clarifying questions, and ends with explicit exclusions. Every sentence adds value for a tool with 14 parameters; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the presence of an output schema, and annotations covering safety, the description is complete: it covers when to use, what to pass, return ranking, and missing-data behavior. It doesn't mention default radius (50) but that is in the schema. Minor gaps remain, but nothing critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds a high-level instruction to 'Pass everything the user said: years, make, model, trim, budget, mileage cap, zip code and radius,' but this is a general hint rather than per-parameter detail. Baseline 3 is appropriate; the description doesn't significantly exceed it.
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 clear verb ('Find a specific car') and resource ('from live dealer inventory'), with specific vehicle types (car, truck, SUV, van) and conditions (new/used). It explicitly contrasts with the sibling demand.search for non-vehicle parts, making it unambiguous which tool handles whole-vehicle searches.
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 says 'Call this WHENEVER the user wants to buy, find, shop for or compare a whole vehicle' and gives concrete examples. It also explicitly excludes parts/accessories and directs those to demand.search, providing a clear alternative and when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the server is up and see which supply sources are currently answering. Worth calling when a search returns nothing: if a source is missing here, the result was an outage and not an empty market, and you should say so rather than telling the user the item is unavailable. Free, instant, no side effects. Protocol v1.0 §8.2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| server | No | Server name and version. |
| status | Yes | "ok" when the server can answer searches. |
| degraded | No | True when one or more supply sources are failing. |
| supply_sources | No | Supply sources currently reachable. A short list means degraded matching, not an empty market. |
| protocol_version | No | Demand-protocol version this server implements. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations: it states the tool is 'free, instant, no side effects' which aligns with readOnlyHint and destructiveHint. It also mentions that it checks supply sources, which is a behavioral detail, and references a protocol section for further detail. While the annotations already declare the tool as read-only and non-destructive, the description enriches the understanding with the purpose of checking supply sources and the free/instant aspect, which is useful for agents concerned about cost and latency.
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 front-loaded: it starts with the primary purpose, then provides usage guidance, and ends with operational details. Every sentence earns its place: the first sentence states the function, the second explains when to use it and how to interpret results, and the third provides cost and side-effect information. No fluff, no repetition, and the protocol reference is a nice touch but not generic.
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 the tool has no parameters, has an output schema that likely describes the health status, and has annotations that cover safety, the description is complete. It provides enough context for an agent to know when and how to use it, what to do with the results, and that it has no side effects. There is no missing information that would prevent correct invocation or interpretation.
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 no parameters, and the schema description coverage is 100%, meaning there is nothing to explain. The description appropriately doesn't waste space on parameters. Since there are no parameters, the tool's behavior is fully self-contained, and there is no need for additional parameter semantics. A baseline of 4 is appropriate because the schema covers everything, and the description adds no redundant information.
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: to check server status and supply source availability. It uses a specific verb ('check') and resource ('server', 'supply sources'), and distinguishes itself from sibling tools by focusing on health rather than search or market operations. The description makes it evident that this is a diagnostic tool, not a data retrieval tool.
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 states when to use the tool: when a search returns nothing, to determine if the result is an outage. It provides clear guidance on how to interpret the results (if a source is missing, it's an outage, not an empty market) and advises the user to communicate accordingly. This goes beyond simple when-to-use and includes decision-making guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a seller has answered an introduction created by demand.request_introduction, and read their reply. Call it when the user asks whether the dealer got back to them. Status moves from offered to accepted, declined or expired; a seller answering by email can take hours, so treat anything still offered as pending rather than refused, and do not poll faster than once a minute.
| Name | Required | Description | Default |
|---|---|---|---|
| introduction_id | Yes | The id returned by demand.request_introduction. Keep it from that response; it is the only handle on the introduction. |
| Name | Required | Description |
|---|---|---|
| reply | No | |
| dealer | No | |
| status | Yes | |
| offered_at | No | |
| accepted_at | No | |
| listing_title | No | |
| introduction_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint, openWorldHint, destructiveHint) already indicate a safe read operation, but the description adds crucial behavioral context: the possibility of delayed email replies, the meaning of 'offered' as pending, and the polling rate constraint. This enriches the agent's understanding beyond the annotation hints.
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 function and usage trigger, then adds necessary behavioral nuance. No redundant content; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (present but not shown) and the description clarifies status semantics and polling behavior, the tool is fully specified for correct invocation. Nothing critical is missing—the agent knows what to expect and how to 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 description coverage is 100% and the schema clearly documents introduction_id as returned by demand.request_introduction. The description doesn't add new parameter meaning; it only uses the parameter in context. Baseline of 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (check/read) and resource (introduction seller reply), and explicitly links to the creation tool demand.request_introduction, distinguishing it from siblings like demand.ask. It clearly tells the agent what operation is performed.
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 an explicit trigger ('when the user asks whether the dealer got back to them'), explains the status lifecycle (offered to accepted/declined/expired), and provides behavioral guidance on treating 'offered' as pending and not polling faster than once a minute. This covers when and how to use it, and implicitly advises against over-polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the filters this server will actually enforce on a search - budget ceilings, condition, brand, and the vertical-specific keys (mileage, drive size) plus any x_* extensions. Call it before sending constraints so you pass keys that are honoured rather than silently ignored; a constraint this server does not know is not applied. Free, instant, no side effects. Protocol v1.0 §8.2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| constraints | Yes | Every constraint key that can be enforced on a search or want. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the operation is free, instant, and has no side effects, and unknown constraints are not applied. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences front-load the core purpose and concrete filter examples, then immediately give usage guidance and the no-side-effects reassurance. No wasted words; every sentence contributes.
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, empty input schema, existing output schema, and strong annotations, the description is complete. The agent knows what the tool does, why to call it, when to call it, and what to expect behaviorally.
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 the description cannot reasonably add parameter-level meaning. The baseline for 0-parameter tools is 4, and the description fully covers what the agent needs to know about invocation.
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 a specific verb ('List') and resource ('filters this server will actually enforce on a search'), enumerating concrete filter categories and x_* extensions. This distinguishes it from siblings like demand.search and demand.capabilities by focusing on the constraint vocabulary rather than searching or capability discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to call the tool: before sending `constraints`, so the agent passes keys the server honors rather than silently ignored ones. It also explains the consequence of passing unknown constraints, making the usage intent unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the product categories this server can actually source, with the structured spec fields each one carries (a vehicle has year, make, model, mileage; a tool has drive size and torque). Call it before a first search to learn which vertical values are accepted, or when a search returns nothing and you need to check the category is covered at all. Free, instant, no side effects. Protocol v1.0 §8.2.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| verticals | Yes | Every vertical this server can match demand in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Free, instant, no side effects.' It adds context beyond the annotations by clarifying that this returns only categories the server can 'actually source' and references 'Protocol v1.0 §8.2', giving the agent confidence about scope without contradicting the structured hints.
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 three sentences with every sentence earning its place: purpose, usage timing, and side-effect safety. The core action and scope are front-loaded, and the protocol reference is kept to the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema, the description is complete. It covers what the tool returns, when to call it, and that it has no side effects, leaving no gap an agent would need to fill by opening the schema or guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description adds value by clarifying what the returned list contains (verticals plus their spec fields, e.g., vehicle vs tool), which helps an agent interpret the output schema correctly.
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 clear verb–resource pair: 'List the product categories this server can actually source' and further specifies that it includes 'the structured spec fields each one carries'. It differentiates itself from siblings like demand.search and demand.list_constraints by framing it as the pre-search way to learn accepted vertical values.
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 explicit conditions for use: 'Call it before a first search to learn which vertical values are accepted, or when a search returns nothing and you need to check the category is covered at all.' It tells the agent both when and why to call it, which is strong practical guidance despite not naming a specific sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your standing wants, with how many matches each has surfaced and when it last re-ran. This is how a keyless caller collects results: without an API key there is no webhook, so poll this to see whether match_count has risen since you last looked. Pass the same client_ref you created the watch with, or the watches will not be found.
| Name | Required | Description | Default |
|---|---|---|---|
| client_ref | No | The same opaque reference you passed to demand.create_watch. Required to find keyless watches; ignored when you send an API key. |
| Name | Required | Description |
|---|---|---|
| count | No | How many were returned. |
| watches | Yes | Your standing wants, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, but the description adds meaningful behavioral context: no webhook without an API key, polling semantics, match_count changes, and the client_ref dependency. This goes well beyond the structured 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?
Three sentences, all substantive and front-loaded with the core purpose before the usage caveat. No wasted words or redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with a single optional parameter and an output schema, this description covers purpose, when to use it, behavioral caveats, and parameter semantics. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains the client_ref behavior including the API-key caveat. The description restates the same constraint, adding only a consequence ('or the watches will not be found'), which is marginal value 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?
States a specific verb ('List') and resource ('your standing wants') and adds the distinguishing details that each watch shows match count and last re-run time. This clearly differentiates it from sibling create/cancel operations.
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 tells when this tool is the right choice: keyless callers have no webhook, so they must poll this endpoint to collect results. It also notes the client_ref requirement, giving a clear precondition for successful use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell the user whether the asking price on ONE specific car is a good deal. Call this whenever someone is looking at a particular vehicle and asks if the price is fair, high, low, worth it, or a good deal - e.g. 'I am thinking of a 2017 Lexus ES 350 with 80k miles for $21k, decent deal?', 'is $34,500 too much for this F-150?', or when they paste a listing link and ask what you think. Pass the whole sentence as query, plus the listing url if they gave one. Returns where that asking price sits among comparable cars listed right now (percentile, median, typical range) with the size of the sample, mileage-matched when we have enough cars. Use demand.find_vehicle instead when the user is still choosing which car to buy rather than pricing one they found.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Listing URL if they pasted one. We read the year/make/model from the link itself and never fetch the page. | |
| vin | No | 17-character VIN if known | |
| zip | No | 5-digit US zip. Without it the comparison is national rather than local. | |
| make | No | Manufacturer of the car being priced, e.g. "Toyota". | |
| trim | No | Trim level. Materially changes a fair price, so pass it when known. | |
| year | No | Model year of the car being priced. Optional if `query`, `url` or `vin` identifies it. | |
| model | No | Model line of the car being priced, e.g. "RAV4". | |
| query | No | What the user said, in their words, e.g. '2017 Lexus ES 350, 80k miles, asking $21k' | |
| mileage | No | Odometer miles. The single biggest thing a used price turns on; pass it whenever the user said it. | |
| client_ref | No | Optional stable, non-identifying reference for this end user (any opaque string; we hash it). | |
| radius_miles | No | Comparison radius, default 100 | |
| asking_price_cents | No | The asking price in cents, if you can state it exactly |
| Name | Required | Description |
|---|---|---|
| caveats | No | |
| verdict | Yes | |
| headline | Yes | |
| comparison | Yes | |
| percentile | No | |
| understood | No | |
| delta_cents | No | |
| clarifying_question | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, non-destructive, and open-world, and the description adds useful behavioral context beyond them: it never fetches a pasted URL, compares against currently listed cars, returns percentile/median/typical range with sample size, and mileage-matches when enough data exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, followed by examples, parameter guidance, return behavior, and the alternative tool. It is somewhat long, but every section earns its place given the 12-parameter schema and the need to disambiguate from siblings.
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 is complete for an agent to select and call the tool: it covers when to use it, what to pass, what behavior to expect, and when not to use it. The output schema handles return structure details, and the description already summarizes the key return values.
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 extra value by directing the agent to pass the whole user sentence as `query`, clarifying that `url` is parsed locally and never fetched, and noting that `zip` changes the comparison from national to local.
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 ('tell the user whether the asking price on ONE specific car is a good deal') and defines the exact scope. It also distinguishes itself from demand.find_vehicle, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call it ('whenever someone is looking at a particular vehicle and asks if the price is fair...'), provides concrete user-phrase examples, and names the sibling alternative (demand.find_vehicle) with the condition that should route to that tool instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask a specific seller to answer the user about one car from demand.find_vehicle. Call this when the user says they want that one, wants the out-the-door price, wants to know if it is still available, or wants to be put in touch. Pass the listing_id from demand.find_vehicle and the user's question. We deliver it only to dealers who have joined iwant.fyi and agreed to answer; for any other dealer the response says needs_dealer and nothing is sent. No personal details about the user ever reach the dealer. Ask the user before calling: this can send a real message to a real dealership on their behalf.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit zip the search used | |
| query | No | The original search in the user's words; used to re-find the listing if the id has aged out | |
| message | No | What the user wants to know or say, in their words. No phone numbers, emails or addresses. | |
| client_ref | No | Optional stable, non-identifying reference for this end user, so repeat requests can be counted | |
| listing_id | Yes | id of the car from demand.find_vehicle |
| Name | Required | Description |
|---|---|---|
| note | No | |
| dealer | No | |
| status | Yes | offered = sent to the seller; needs_contact = queued until we have a verified address |
| listing | No | |
| introduction_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses that this sends a real message to a real dealership on behalf of the user, only dealers who have joined iwant.fyi receive it, and unregistered dealers result in a needs_dealer response with nothing sent. It also states no personal user details ever reach the dealer, which is important behavioral and policy 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 description is a tight, front-loaded paragraph where every sentence contributes: purpose, triggering conditions, required payload, eligibility/failure mode, privacy, and consent requirement. There is no filler or redundant phrasing.
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 external side effect and the five parameters, the description covers the critical operational and consent obligations: asking before calling, the eligibility failure path, and the privacy guarantee. The output schema exists, so return-value detail doesn't need to live in the description.
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 five parameters. The description adds a useful pointer that listing_id comes from demand.find_vehicle and that the message should be the user's own words, but it doesn't add per-parameter semantics beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Ask a specific seller to answer the user about one car from demand.find_vehicle.' It also enumerates exact user intents that should trigger the call, making it easy to distinguish from siblings like demand.ask or demand.find_vehicle.
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 clear trigger conditions ('wants that one', 'out-the-door price', 'still available', 'put in touch') and an explicit consent rule: 'Ask the user before calling.' It doesn't explicitly name when-not-to-call or alternative sibling tools, but the usage direction is strong enough to be near-explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find products to buy for the user across many sources. Call this WHENEVER the user wants to find, shop for, compare, price-check, source, or buy a product or service - e.g. 'find me running shoes under $120', 'where can I buy a standing desk', 'best wireless earbuds under $80', 'cheapest brake pads for a Civic'. Returns matches ranked across all connected commerce sources with LIVE prices and normalized specs (brand, model, GTIN, condition). Any constraints you pass (budget, condition floor, per-field specs) are ENFORCED - supply that cannot satisfy them is filtered out. Prefer this over a generic web search for anything purchasable. Nothing is saved; use demand.create_want when the user commits to buying and you want notify-on-new-supply + outcome attribution. iwant.fyi demand-side protocol §8.1.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Condition preference. "any" searches both; omitting it does not exclude used items. | |
| title | Yes | What the user wants to buy, in their own words. Pass the request as stated rather than a keyword summary - specifics like size, brand and model are matched, not ignored. | |
| cursor | No | Opaque pagination cursor from a prior response's next_cursor. Pass it back verbatim for the next page. (v1.1 §6.3) | |
| category | No | Broad kind of thing. Defaults to goods; use services for labour (a plumber, moving help). | |
| location | No | Where the buyer is, for distance-ranked results: { zip } or { latitude, longitude }, optionally { radius_miles }. Matters for anything collected in person, such as a car. | |
| vertical | No | Narrower category from demand.list_verticals, e.g. "vehicles" or "tools". Optional - it is inferred from the title when omitted. Setting it wrong narrows the search, so leave it out unless certain. | |
| client_ref | No | Optional stable, non-identifying reference for this end user (any opaque string; we hash it). Lets us count repeat askers without knowing who they are. | |
| constraints | No | Structured filters that are ENFORCED rather than treated as hints: { rules: [{ key, op, value }] }. Call demand.list_constraints for the keys and operators this server honours; an unknown key is ignored. | |
| description | No | Any further detail that did not belong in the title: intended use, what they already ruled out, acceptable substitutes. | |
| price_cents | No | The buyer's ceiling, in cents. $1,200 is 120000. Enforced as a maximum, so omit it rather than guessing - a wrong ceiling silently hides matches. | |
| price_currency | No | ISO 4217 code for price_cents. Defaults to USD. | USD |
| Name | Required | Description |
|---|---|---|
| matches | Yes | |
| degraded | No | |
| search_id | No | |
| match_count | Yes | |
| next_cursor | No | |
| sources_consulted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/destructive annotations, the description discloses meaningful behavior: results are ranked across connected sources with LIVE prices, constraints are ENFORCED and non-matching supply is filtered, and 'Nothing is saved.' These behavioral facts are not inferable from the annotations alone and materially affect invocation.
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 not bloated; it front-loads the core purpose before examples, constraints, and alternatives. The protocol reference at the end is the only piece with limited actionable value for an agent. Overall, most sentences earn their place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter tool with an output schema, the description covers the essential decision context: when to call it, what it returns, how constraints behave, persistence semantics, and the correct sibling for follow-up. The output schema handles return-value detail, so nothing critical 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 the baseline is 3. The description adds cross-parameter meaning: it explains that budget, condition floor, and per-field specs are enforced, and that title specifics are matched rather than ignored. This enriches parameter understanding without repeating schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find products to buy for the user across many sources.' It supplies concrete example queries ('find me running shoes under $120') and explicitly contrasts itself with a generic web search and with demand.create_want. An agent can tell exactly what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-call conditions ('WHENEVER the user wants to find, shop for, compare, price-check, source, or buy'), an explicit preferred alternative ('Prefer this over a generic web search for anything purchasable'), and an explicit when-not-to-call ('use demand.create_want when the user commits to buying'). This routes the agent clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
demand.cancel_watchdemand.create_watchdemand.list_watchesdemand.capabilities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "features": {
+ "description": "Optional features supported, e.g. webhooks, idempotency, failure_transparency, error_taxonomy.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "limits": {
+ "additionalProperties": true,
+ "description": "Operational limits to respect.",
+ "properties": {
+ "max_watches": {
+ "description": "Standing watches one caller may hold.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "min_check_interval_seconds": {
+ "description": "Floor on how often a watch re-runs.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "rate_limit_per_minute": {
+ "description": "Calls per minute before throttling.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "protocol_version": {
+ "description": "Demand-protocol version.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "protocol_version"
+ ],
+ "type": "object"
+}demand.find_vehicle8 fields changedInput schema / properties / condition / descriptionAdded value: +"\"cpo\" is manufacturer certified pre-owned. \"any\" searches all three; omitting it does not exclude used cars."Input schema / properties / make / descriptionAdded value: +"Manufacturer, e.g. \"Toyota\". Optional - it is parsed from `query` when omitted. Pass it only to override what the text says."Input schema / properties / mileage_max / descriptionPrevious value: -"Maximum odometer miles"New value: +"Maximum odometer miles, e.g. 60000."Input schema / properties / model / descriptionAdded value: +"Model line, e.g. \"RAV4 Hybrid\". Optional; parsed from `query` when omitted."Input schema / properties / price_max_cents / descriptionPrevious value: -"Budget ceiling in cents"New value: +"Budget ceiling in cents. $35,000 is 3500000. Enforced as a maximum."Input schema / properties / trim / descriptionAdded value: +"Trim level, e.g. \"XLE\". Narrows hard, so omit unless the buyer named one."Input schema / properties / year_max / descriptionAdded value: +"Latest model year to accept, inclusive. Omit for \"2019 or newer\"."Input schema / properties / year_min / descriptionAdded value: +"Earliest model year to accept, inclusive. Four digits."demand.health1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "degraded": {
+ "description": "True when one or more supply sources are failing.",
+ "type": "boolean"
+ },
+ "protocol_version": {
+ "description": "Demand-protocol version this server implements.",
+ "type": "string"
+ },
+ "server": {
+ "description": "Server name and version.",
+ "type": "string"
+ },
+ "status": {
+ "description": "\"ok\" when the server can answer searches.",
+ "type": "string"
+ },
+ "supply_sources": {
+ "description": "Supply sources currently reachable. A short list means degraded matching, not an empty market.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}demand.introduction_status1 field changedInput schema / properties / introduction_id / descriptionAdded value: +"The id returned by demand.request_introduction. Keep it from that response; it is the only handle on the introduction."demand.list_constraints1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "constraints": {
+ "description": "Every constraint key that can be enforced on a search or want.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "What the constraint filters on.",
+ "type": "string"
+ },
+ "key": {
+ "description": "Constraint name, e.g. \"price_max\" or \"condition\".",
+ "type": "string"
+ },
+ "operators": {
+ "description": "Comparisons this key accepts, e.g. lte, eq, in.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "value_type": {
+ "description": "Expected value type.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "constraints"
+ ],
+ "type": "object"
+}demand.list_verticals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "verticals": {
+ "description": "Every vertical this server can match demand in.",
+ "items": {
+ "properties": {
+ "description": {
+ "description": "What this vertical covers.",
+ "type": "string"
+ },
+ "key": {
+ "description": "Identifier to pass as the `vertical` argument, e.g. \"vehicles\".",
+ "type": "string"
+ },
+ "spec_keys": {
+ "description": "Structured spec fields carried for items in this vertical.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "key"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "verticals"
+ ],
+ "type": "object"
+}demand.price_check4 fields changedInput schema / properties / make / descriptionAdded value: +"Manufacturer of the car being priced, e.g. \"Toyota\"."Input schema / properties / model / descriptionAdded value: +"Model line of the car being priced, e.g. \"RAV4\"."Input schema / properties / trim / descriptionAdded value: +"Trim level. Materially changes a fair price, so pass it when known."Input schema / properties / year / descriptionAdded value: +"Model year of the car being priced. Optional if `query`, `url` or `vin` identifies it."demand.search9 fields changedInput schema / properties / category / descriptionAdded value: +"Broad kind of thing. Defaults to goods; use services for labour (a plumber, moving help)."Input schema / properties / constraints / descriptionAdded value: +"Structured filters that are ENFORCED rather than treated as hints: { rules: [{ key, op, value }] }. Call demand.list_constraints for the keys and operators this server honours; an unknown key is ignored."Input schema / properties / description / descriptionAdded value: +"Any further detail that did not belong in the title: intended use, what they already ruled out, acceptable substitutes."Input schema / properties / location / descriptionAdded value: +"Where the buyer is, for distance-ranked results: { zip } or { latitude, longitude }, optionally { radius_miles }. Matters for anything collected in person, such as a car."Input schema / properties / mode / descriptionAdded value: +"Condition preference. \"any\" searches both; omitting it does not exclude used items."Input schema / properties / price_cents / descriptionAdded value: +"The buyer's ceiling, in cents. $1,200 is 120000. Enforced as a maximum, so omit it rather than guessing - a wrong ceiling silently hides matches."Input schema / properties / price_currency / descriptionAdded value: +"ISO 4217 code for price_cents. Defaults to USD."Input schema / properties / title / descriptionPrevious value: -"What to search for (same shape as demand.create_want)"New value: +"What the user wants to buy, in their own words. Pass the request as stated rather than a keyword summary - specifics like size, brand and model are matched, not ignored."Input schema / properties / vertical / descriptionAdded value: +"Narrower category from demand.list_verticals, e.g. \"vehicles\" or \"tools\". Optional - it is inferred from the title when omitted. Setting it wrong narrows the search, so leave it out unless certain."Search live US dealership inventory, get market prices, and send buyer inquiries. Free, no API key.
Golf equipment catalog, live retailer prices and daily price history. Keyless search, free key.
Live franchised-dealer inventory, quotes, and consented salesperson handoffs.
Search US vehicle listings from dealer sites, with price stats, VIN lookup, and dealer profiles.
Add one secure layer between your agents and this server.
