Live listings, sold prices and resale scores from GovAuctions.app, the public surplus-auction site.
Scored across 8 tools
Each tool targets a distinct resource (listing, comp, trend, flip score, coverage, usage, search). The comps trio (get_sold_comps, get_sold_history, get_price_trend) overlaps in domain, but descriptions clearly differentiate their outputs (statistics, evidence, monthly series).
All tools follow a consistent verb_noun snake_case pattern: get_api_usage, get_comp_coverage, get_flip_score, get_listing, get_price_trend, get_sold_comps, get_sold_history, search_listings. The single 'search_' verb deviation is natural and predictable.
Eight tools is well-scoped for a domain-specific auction intelligence API. Each tool maps to a clear capability (usage pacing, coverage disclaimers, scoring, trends, comps, history, search), none feel redundant or missing.
Covers the core read-only workflows: find listings, get details, assess value via comps/trends/flip score, and check coverage/usage. No write operations exist, but the server appears read-only by design (auction data API), so this is complete for its purpose.
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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds non-obvious behavioral context — that results include categories which can never be priced and that this is the authoritative statement of what the service cannot do. Still no mention of return granularity (counts vs. ratios) or 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?
Two sentences, zero waste: the functional statement is front-loaded and the usage cue follows immediately. The closing clause is rhetoric but still carries the substantive point that unpriced categories are reported.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, output-schema-less diagnostic tool the description conveys enough to call it correctly (market scope, coverage semantics, unpriced categories). It would be stronger if it hinted at the shape of the coverage report or clarified that country is optional and defaults to US.
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 0% for the single 'country' parameter, which carries a 4-value enum and a default of US. The description only alludes to scoping via 'for a market' and never names the country dimension, its allowed values, or the default, so it does not fully compensate for the schema 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+resource and, crucially, what the return actually means: sold-price data volume per category for a market, plus categories that can never be priced. This distinguishes it from data-returning siblings like get_sold_comps — it is a coverage/meta tool, not a comps fetch.
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?
'Check this before building on the comps tools' gives an explicit trigger condition and frames it as a preflight step. No when-not guidance or named alternative beyond the collective 'comps tools' reference, so it falls just 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.
GovAuctions Flip Score resale signal for a live GSA listing (valued against the full-market comp archive): estimated value, effective bid, and discount.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds scope context: the score is computed against the full-market comp archive and returns three named fields. It doesn't cover caching, freshness, or error behavior, but that is reasonable given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence that front-loads the tool's purpose and ends with the three outputs. No padding, though the parenthetical about the comp archive is a bit terse.
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 it's a read-only single-param tool with rich annotations and no output schema, the description partly explains what gets returned (value, bid, discount). However, it says nothing about the 'id' parameter, error conditions, or what a 'Flip Score' numeric range means, leaving an agent's expectations partially undefined.
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 0% and the single parameter 'id' is completely undocumented in both the schema and the description. The description does not clarify that 'id' refers to a GSA listing identifier, nor does it specify the expected format. Baseline for 0 params would be 4, but here there is one undocumented required param and the description does not compensate.
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-like action (retrieve resale signal/flip score) and the resource (a live GSA listing), and names the three outputs (estimated value, effective bid, discount). It's distinguishable from siblings like get_sold_comps or get_price_trend, though the phrasing 'resale signal' is somewhat jargon-heavy.
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 guidance, no mention of prerequisites, and no comparison to alternatives. An agent cannot infer from the description whether this supersedes or complements get_sold_comps / get_price_trend.
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 cover the safety profile (readOnly, idempotent, non-destructive), so the burden is lighter. The description adds two useful behaviors: consistency with get_sold_comps and empty-series behavior when sample thresholds aren't met. It doesn't describe aggregation method or country/bucket handling, so it's adequate but not rich.
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 tight sentences; behavior (median series + change) is front-loaded, consistency note second, threshold note third. 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?
No output schema, so the description correctly sketches the return (month-by-month series plus first-to-last change) and its empty case. However, with no explicit output schema and only a schematic return description, an agent cannot fully rely on the shape. The 50% schema coverage also leaves category and country semantics thin. Adequate but incomplete.
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 50%, and the description adds no parameter-level detail beyond what the schema documents. For a 4-param tool at 50% coverage, that leaves undocumented parameters (category has no description at all) unaddressed. Baseline 3 with the schema carrying the load.
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?
Specific verb+resource: returns month-by-month median sale price plus first-to-last change for an item. The framing 'is this category softening?' anchors the resource as a market-trend signal, clearly distinguishing it from get_sold_comps and search_listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly routes the agent: it clarifies it uses the same comps as get_sold_comps and that the series is empty when too few months clear the sample threshold. No explicit 'use when/not when', but the threshold rule gives an operative condition for interpreting results.
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 the US, UK, CA or AU. Without an API key: coverage only (how many comparable sales, confidence, and a coarse price band). With an API key: the actual 25th/median/75th percentile final prices. Free keys at https://govauctions.app/developers. A miss says which kind it is: reason insufficient_comps (too few comparable sales yet) is worth retrying, reason category_not_priceable (miscellaneous, real-estate) never is — those categories cannot be priced from a title.
| 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. | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile, and the description adds substantial behavioral context beyond them: the tiered key/no-key output difference, plan-based caps on comps, and semantics of the two miss reasons (which are retryable vs terminal). This is richer than typical and directly informs invocation decisions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then the key/no-key difference and miss semantics; every sentence earns its place. Slightly dense with the URL and dual miss-reason clause, but no wasted 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?
With no output schema, the description compensates by describing return shapes (sales count, confidence, coarse band vs 25th/median/75th percentiles) and the response `scope` field. Nothing needed to call it correctly 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 67%, so most parameters are documented in the schema itself, and the description adds no parameter-level detail (e.g. how `state` fallback or `include=comps` behaves is in the schema). Baseline 3 is appropriate given the schema carries the load.
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 pins the scope to the government-surplus market across four named countries. An agent can distinguish this from siblings like get_comp_coverage and get_sold_history without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when the output differs (no key = coverage only; with key = percentile prices) and even advises retry behavior per miss reason. It does not explicitly route the agent away from sibling tools, so it stops short of a full when/when-not rubric.
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.
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_listingsLive US auction lots and sold prices from commercial auction houses and government surplus
Government Auctions MCP — physical-asset auctions (surplus, seized, forfeited,
Collector-car auction history, live listings, bid trails, and market statistics for AI agents.
GSA Auctions API MCP — US federal government surplus auctions (keyed).
Add one secure layer between your agents and this server.
