Live listings, sold prices and resale scores from GovAuctions.app, the public surplus-auction site.
Scored across 8 tools
Each tool has a clearly distinct purpose: live listing search/retrieval, sold-price comps, sold history, price trend, flip scoring, coverage metadata, and API usage. The comps-family tools could overlap conceptually, but their descriptions sharply separate aggregate comps, underlying sales evidence, and month-by-month trend.
All tool names use consistent snake_case verb_noun phrasing, dominated by get_* with one search_listings tool. There is no mixing of camelCase or vague verb styles.
Eight tools is well scoped for a read-only auction data and valuation API. Each tool covers a distinct facet without obvious redundancy or bloat.
The read-only surface covers live listings, sold comps/history/trend, flip scoring, coverage checks, and API usage pacing. A minor gap is the absence of an explicit list-markets or list-categories tool, though coverage checks partially address category limitations.
This key's usage for the current month: total calls and the separate valuation allowance (which comps, sold history, trend and flip-score draw down), plus the reset date. Call it to pace a long run instead of hitting a 429 mid-task.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so safety is covered. The description adds non-obvious behavioral context beyond that: the quota is split into a general call pool and a valuation allowance consumed by specific features, and the 429 failure mode it helps avoid.
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, front-loaded with the return contents and closed with the operational reason to call it. Every clause carries information, including the parenthetical naming which features draw down the allowance.
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 parameters and no output schema, the description carries the full burden and discharges it by describing the returned fields (total calls, valuation allowance breakdown, reset date). An agent knows what it will get and what to do with it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the schema to document and no semantic gap to fill; the baseline of 4 applies. The description correctly implies the key is inferred from auth rather than passed in.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (this key's API usage for the current month) and enumerates exactly what comes back: total calls, the separate valuation allowance broken out by which features draw it down (comps, sold history, trend, flip-score), and the reset date. No sibling tool covers quota/usage, so the differentiation is 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?
Gives an explicit, actionable trigger: 'Call it to pace a long run instead of hitting a 429 mid-task.' That is a clear when-to-use condition, though it does not describe when not to bother calling (e.g., short single-call tasks) and there are no alternative tools to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much sold-price data we hold per category for a market, and which categories can never be priced. Check this before building on the comps tools — it is the honest answer about what we cannot do.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | US |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive profile, so the description does not need to restate them. It adds useful behavior beyond annotations by disclosing that the tool returns limitations and capability gaps ('which categories can never be priced', 'honest answer about what we cannot do'). No contradiction 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?
Two dense sentences, front-loaded with the tool's output and followed by an actionable usage rule. Every phrase earns its place; no redundant restatement of the title or schema.
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, one-optional-parameter read-only tool with no output schema, the description is nearly complete: it covers what data is returned, the inherent limitation report, and the recommended call context. It does not describe the exact output format, but that is a minor gap given how self-contained the tool is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single country parameter, and the description only indirectly references it as 'a market' without clarifying the enum values or default. The schema itself carries the enum and default, but the description does not compensate for the missing parameter documentation.
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 exactly what the tool reports—sold-price data coverage per category for a market and categories that can never be priced. This clearly distinguishes it from sibling comps tools like get_sold_comps or get_price_trend, which return actual comps data rather than coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells an agent when to call the tool: 'Check this before building on the comps tools.' It also frames the tool as the preflight/feasibility gate versus using the comps tools themselves, so the decision between this and siblings is stated rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GovAuctions Flip Score resale signal for one live lot, from any source, in any market with sold-price comps (valued against that market's comp archive): estimated value, effective bid, discount, and the link to the lot on its source site. Pass the lot id as it appears in a govauctions.app lot URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those: the tool returns a calculated resale signal with specific fields, and it is conditioned on the market having sold-price comps. 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 a single dense sentence with no filler. It front-loads the tool's purpose and output components, then closes with the necessary input instruction. It is slightly long but every clause contributes meaning.
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 no output schema, the description names all returned components (estimated value, effective bid, discount, source link), explains the single input's format, and states the comp-market prerequisite. This is sufficient for a low-complexity, one-parameter, safely annotated read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only a bare 'id' string with no description. The description compensates by explaining that the id is the lot id as it appears in a govauctions.app lot URL, which is exactly the format guidance an agent needs. With 0% schema coverage, this carries the full weight and does so adequately.
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 resource ('one live lot') and what it produces ('resale signal' with estimated value, effective bid, discount, and link). It distinguishes from sibling tools by focusing on the Flip Score computation rather than listing details, comp history, or trends, though it doesn't name specific 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 gives clear selection context: use it for a single live lot across any source/market where sold-price comps exist. It also specifies the required input format ('lot id as it appears in a govauctions.app lot URL'). It stops short of explicitly contrasting with sibling tools, but the scope is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one live GSA listing by its id (facts only).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds only 'live' (scope to active listings) and 'facts only' (suggests no derived analysis), which is modest extra context rather than rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with verb and resource, with the scope qualifiers inline. Nothing is wasted or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-param read with full annotation coverage and no output schema, this is largely adequate. However, 'facts only' is undefined and could mislead an agent about what fields come back, so it falls short of 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 0% and the single parameter is undocumented in the schema. 'By its id' merely restates the parameter's existence without stating format, source, or whether it is a GSA id versus a marketplace id, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one live GSA listing'), and 'live' plus 'by its id' narrows the scope usefully. It does not explicitly distinguish itself from the sibling search_listings, but the singular retrieve-by-id framing is clear enough for an agent to tell them 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?
No when-to-use or when-not-to-use guidance. With siblings like search_listings and get_sold_comps nearby, the description never says to use this when you already have an id rather than searching, nor what happens for a non-live or missing listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Month-by-month median sale price for an item, plus the first-to-last change — 'is this category softening?'. Computed from the same comps as get_sold_comps, so it never contradicts that range. Returns an empty series when too few months clear the sample threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Item description, e.g. 'forklift' | |
| state | No | Optional 2-letter state/region code. | |
| country | No | US | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds useful behavioral detail: the series is empty when too few months clear the sample threshold, and results never contradict get_sold_comps. It doesn't cover timeframe or recency of data, but this is a meaningful addition beyond 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 dense sentences with no filler: the core computation, the relationship to get_sold_comps, and the empty-series edge case are each stated once and in priority order. 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 there is no output schema, the description adequately states the return shape and the edge case, while annotations cover the safety profile. The main gaps are the semantically empty category parameter and the absence of explicit guidance for choosing between this tool and get_sold_history. Still, an agent has enough to invoke it correctly for a typical request.
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?
Only q has a real description in the schema; category is completely undocumented. The description adds the idea of an 'item' and category-level softening, but it does not explain how state, country, or category affect the series. With only 50% schema description coverage, the description fails to compensate for the undocumented 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 clearly states the tool computes a month-by-month median sale price plus a first-to-last change, which is a specific deliverable. It also distinguishes itself from get_sold_comps by noting it is computed from the same comps. However, it never contrasts itself with get_sold_history, so sibling differentiation is incomplete.
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 phrase 'is this category softening?' implies the tool is for assessing price trends, and the get_sold_comps reference suggests it should be used alongside sold comps. But there is no explicit 'use this when' or 'instead of' guidance, and no mention of when the trend tool is preferable to get_sold_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sold-price comps for a described item, computed across the full government-surplus market in any market listed in country. Signed out: coverage only (how many comparable sales, confidence, and a coarse price band). Signed in or with an API key: the actual 25th/median/75th percentile final prices. liveListingsUrl links to the live auctions for the same item. A miss says which kind it is: reason insufficient_comps (too few comparable sales yet) is worth retrying, reason category_not_priceable (real-estate) never is — that category cannot be priced from a title. A catch-all category such as miscellaneous is not refused: it is dropped and the item is priced on its title alone, with requestedCategory and categoryDropped echoed back — check the resolved category and confidence before trusting the range.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Item description, e.g. '2015 Ford F-150' | |
| limit | No | How many underlying sales to return with include=comps. Capped by plan. | |
| state | No | Optional 2-letter state/region code for a regional range. Falls back to the national range when that state has too few sales; the response's `scope` field says which you got. | |
| country | No | US | |
| include | No | Set to "comps" to also return the individual sales the range was computed from (title, final price, sale month, state). Requires a key; the number returned is capped by plan. Not served for EU markets (DE, FR, NL, PL): the range is returned with `compsWithheld: true`. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior well beyond the annotations: signed-out returns coverage only vs signed-in returns actual percentiles, EU markets return `compsWithheld: true`, miss reasons are typed and actionable, and catch-all categories are dropped with `requestedCategory`/`categoryDropped` echoed back. This is rich, non-obvious operational 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?
Dense and front-loaded, leading with the core purpose before the auth-tier and miss-reason detail. It is long, but nearly every sentence carries operational information, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so thoroughly, naming `coverage`, `confidence`, price band/percentiles, `liveListingsUrl`, `scope`, `compsWithheld`, `requestedCategory`, and `categoryDropped`. An agent has enough to interpret results 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?
At 67% schema coverage the description meaningfully supplements the schema: it explains the `include=comps` key requirement and plan cap, EU withholding, and the category-dropping behavior. It adds real meaning but not for every parameter (e.g. `limit`, `state` fallback are already covered by 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+resource ('Sold-price comps for a described item') and scope ('full government-surplus market in any market listed in `country`'). It is clearly distinguishable from siblings like get_comp_coverage, get_sold_history, and get_price_trend since it returns a computed percentile range plus a live-listings link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives strong when-to-retry guidance by distinguishing `insufficient_comps` (worth retrying) from `category_not_priceable` (never retry), and explains auth-tier behavior. It lacks an explicit 'use this instead of get_sold_history/get_price_trend' routing statement against named siblings, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The individual archived sales behind an item: title, final price, sale month and state, plus the range they produce. Use when you want the evidence rather than just the number. Query-anchored — describe an item; there is no way to list the archive.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Item description, e.g. '2015 Ford F-150' | |
| limit | No | How many sales to return. Capped by plan. | |
| state | No | Optional 2-letter state/region code. | |
| country | No | US | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the read-only, idempotent, non-destructive, closed-world safety profile, so the description is not required to carry that burden. It adds genuine behavioral context: the tool is query-anchored with no enumerate-the-archive mode, and it discloses the shape of the returned evidence. It does not mention the plan cap on results or pagination 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?
Three tight sentences that are front-loaded with the core purpose, followed by the usage condition and the query-anchored constraint. No filler, though the second and third sentences are somewhat terse fragments rather than fully integrated guidance.
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 read-only query tool whose annotations already cover the safety profile and with no output schema, the description is nearly complete: it explains what evidence is returned, the query-anchored nature, and when to prefer it. Only the result cap and the exact alternative tool are left unstated.
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 60%, so the schema documents most parameters itself. The description reinforces the required q parameter ('describe an item') and mentions state among returned fields, but adds no syntax or format detail for limit, country, or category beyond what the schema provides. Baseline 3 is appropriate at this coverage level.
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-resource pair (retrieve individual archived sales behind an item) and enumerates the returned fields (title, final price, sale month and state, plus the resulting range). It contrasts with an unnamed sibling via 'the evidence rather than just the number,' which implicitly distinguishes it from aggregate tools like get_sold_comps, but never names that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use when you want the evidence rather than just the number' gives a clear scenario, and 'Query-anchored — describe an item; there is no way to list the archive' states a hard usage constraint. It stops short of naming which sibling to use for the aggregate number, leaving that comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live GSA federal-surplus auction listings (facts only — no images). Filter by state, category, keyword, price, or distance from a US ZIP code. Raw listings cover sanctioned federal sources; sold-price comps span the full market.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Title keyword | |
| zip | No | US 5-digit ZIP to search around. Limits results to lots within radiusMiles, orders them nearest-first, and adds distanceMiles to each. | |
| sort | No | Result order. Default is soonest-ending (nearest-first when `zip` is given). Use `newest` to order by the lot's own listing date, newest first - that is the ordering a recurring "what is new" check needs, because under the default a brand-new lot can sit anywhere in the results. | |
| limit | No | ||
| state | No | 2-letter state code | |
| offset | No | ||
| source | No | gsa | |
| country | No | US | |
| category | No | ||
| priceMax | No | ||
| priceMin | No | ||
| radiusMiles | No | Radius from `zip`, in miles (default 100, max 500). Requires `zip`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), lowering the bar. The description adds useful context: output is facts-only with no images, and raw listings come from sanctioned federal sources while comps span the full market. It does not disclose pagination behavior or result shape, so it is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with the core purpose front-loaded and no filler. The trailing clause about sold-price comps is slightly tangential but serves disambiguation, so it 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?
With 12 parameters, no required fields, 42% schema coverage, and no output schema, the description covers filters and data scope but omits pagination (limit/offset) and sort semantics beyond what the schema states. It is minimally complete for a search tool but leaves gaps an agent would want.
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 42%, so the description must compensate, and it does list the main filter axes (state, category, keyword, price, ZIP distance), which map to q/state/category/priceMin/priceMax/zip/radiusMiles. However, several params (limit, offset, source, country) and the max-100 limit are left entirely to the schema, so the compensation is only partial.
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 (search) and resource (live GSA federal-surplus auction listings) with a scope qualifier (facts only, no images). It also implicitly separates itself from the sold-comps siblings by noting comps 'span the full market,' but does not name an alternative tool directly, so sibling differentiation is only partial.
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 lists filter capabilities (state, category, keyword, price, distance) but gives no when-to-use versus siblings, no prerequisites, and no exclusions. A small hint about sold-price comps exists, but it is a data-provenance statement rather than routing guidance.
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.
get_comp_coverage1 field changedInput schema / properties / country / enumPrevious value: -[
- "US",
- "UK",
- "CA",
- "AU"
-]New value: +[
+ "US",
+ "UK",
+ "CA",
+ "AU",
+ "DE"
+]get_price_trend1 field changedInput schema / properties / country / enumPrevious value: -[
- "US",
- "UK",
- "CA",
- "AU"
-]New value: +[
+ "US",
+ "UK",
+ "CA",
+ "AU",
+ "DE"
+]get_sold_comps2 fields changedInput schema / properties / country / enumPrevious value: -[
- "US",
- "UK",
- "CA",
- "AU"
-]New value: +[
+ "US",
+ "UK",
+ "CA",
+ "AU",
+ "DE"
+]Input schema / properties / include / descriptionPrevious value: -"Set to \"comps\" to also return the individual sales the range was computed from (title, final price, sale month, state). Requires a key; the number returned is capped by plan."New value: +"Set to \"comps\" to also return the individual sales the range was computed from (title, final price, sale month, state). Requires a key; the number returned is capped by plan. Not served for EU markets (DE, FR, NL, PL): the range is returned with `compsWithheld: true`."search_listings1 field changedInput schema / properties / sortAdded value: +{
+ "description": "Result order. Default is soonest-ending (nearest-first when `zip` is given). Use `newest` to order by the lot's own listing date, newest first - that is the ordering a recurring \"what is new\" check needs, because under the default a brand-new lot can sit anywhere in the results.",
+ "enum": [
+ "ending-soonest",
+ "newest"
+ ],
+ "type": "string"
+}get_api_usageget_comp_coverageget_price_trendget_sold_comps2 fields changedInput schema / properties / includeAdded value: +{
+ "description": "Set to \"comps\" to also return the individual sales the range was computed from (title, final price, sale month, state). Requires a key; the number returned is capped by plan.",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "How many underlying sales to return with include=comps. Capped by plan.",
+ "type": "integer"
+}get_sold_historysearch_listings2 fields changedInput schema / properties / radiusMilesAdded value: +{
+ "default": 100,
+ "description": "Radius from `zip`, in miles (default 100, max 500). Requires `zip`.",
+ "maximum": 500,
+ "type": "number"
+}Input schema / properties / zipAdded value: +{
+ "description": "US 5-digit ZIP to search around. Limits results to lots within radiusMiles, orders them nearest-first, and adds distanceMiles to each.",
+ "type": "string"
+}get_sold_comps2 fields changedInput schema / properties / country / enumPrevious value: -[
- "US"
-]New value: +[
+ "US",
+ "UK",
+ "CA",
+ "AU"
+]Input schema / properties / stateAdded value: +{
+ "description": "Optional 2-letter state/region code for a regional range. Falls back to the national range when that state has too few sales; the response's `scope` field says which you got.",
+ "type": "string"
+}get_flip_scoreget_listingget_sold_compssearch_listingsGovernment Auctions MCP — physical-asset auctions (surplus, seized, forfeited,
Collector-car auction history, live listings, bid trails, and market statistics for AI agents.
ShopGoodwill auctions — active listings, closed auctions with final sale
GSA Auctions API MCP — US federal government surplus auctions (keyed).
Add one secure layer between your agents and this server.
