Skip to main content
Glama

govauctions.app

by app.govauctions
OverviewDiscussionsAdmin

Search live GSA listings

search_listings
Read-onlyIdempotent

Search live GSA federal-surplus auction listings (facts only — no images). Filter by state, category, keyword, price, or distance from a US ZIP code. Works signed out (up to 25 rows per page). Raw listings cover sanctioned federal sources; sold-price comps span the full market.

Input Schema

NameRequiredDescriptionDefault
qNoTitle keyword
zipNoUS 5-digit ZIP to search around. Limits results to lots within radiusMiles, orders them nearest-first, and adds distanceMiles to each.
sortNoResult 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.
limitNoRows per page. Signed out, capped at 25.
stateNo2-letter state code
offsetNo
sourceNogsa
countryNoUS
categoryNo
priceMaxNo
priceMinNo
radiusMilesNoRadius from `zip`, in miles (default 100, max 500). Requires `zip`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / limit / description
      Added value: +"Rows per page. Signed out, capped at 25."
  2. Changed1 schema field changed
    • addedInput schema / properties / sort
      Added 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"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / radiusMiles
      Added value: +{
+  "default": 100,
+  "description": "Radius from `zip`, in miles (default 100, max 500). Requires `zip`.",
+  "maximum": 500,
+  "type": "number"
+}
    • addedInput schema / properties / zip
      Added 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"
+}
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real context: no images in results, works without auth, 25-row signed-out cap, and the data-coverage note about sanctioned sources vs full-market comps. The final clause is slightly cryptic but still informative.

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

Conciseness4/5

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

Three tight sentences with the core purpose front-loaded and filters/preconditions following. Efficient overall, though the trailing sold-price-comps clause is somewhat tangential to the tool's own behavior and could be trimmed.

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

Completeness4/5

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

For a search tool with 12 optional params, no output schema, and full annotation coverage, the description supplies the essentials: what it searches, how to filter, auth/page constraints, and result scope. It is only lightly thin on pagination and return-shape expectations.

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

Parameters3/5

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

With 50% schema description coverage, the description helps by enumerating the filter surface (state, category, keyword, price, distance/ZIP) and the signed-out row cap. However it leaves sort, offset/pagination, source, and country behavior entirely to the schema, so it only partially compensates for the coverage gap.

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

Purpose5/5

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

States a specific verb+resource ('Search live GSA federal-surplus auction listings') and immediately scopes it with 'facts only — no images' and the filterable dimensions. This clearly separates it from singular retrieval siblings like get_listing and from the comp/history tools.

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

Usage Guidelines3/5

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

The description implies the tool's role (filter-based discovery of live listings) and notes signed-out access, but it never states when to prefer it over siblings such as get_listing, get_sold_comps, or get_sold_history. Usage is inferable rather than explicit.

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

All govauctions.app toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources