Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sam_search_wage_determinations

Read-only

Find SCA or DBA wage determinations for a locality by state, county, and construction type. Scans all pages for the state to find the single-county match first.

Instructions

Find the Service Contract Act (SCA) or Davis-Bacon Act (DBA) wage determination(s) for a locality (keyless SAM SGS). For a Davis-Bacon lookup pass state + county + constructionType (e.g. 'IL', 'Cook', 'Building') — the tool scans ALL pages for the state so no WDs are missed, ranks single-county WDs first (the most specific match), and reports real match counts. Then call sam_get_wage_rates on the top result to read the rate table. SCA: pass state + county. constructionType is DBA-only: Building (federal buildings/schools), Residential, Heavy (bridges/utilities), Highway (roads). NOTE: query matches WD number/title only, NOT occupation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo0-based page index (default 0). Ignored when county or constructionType is given — a full-state scan is performed instead.
limitNoPage size (default 20, max 50). Ignored when county or constructionType is given — a full-state scan is performed instead.
queryNoMatches the WD NUMBER/TITLE only — NOT occupation/job title (q=guard returns 0).
stateNo2-letter USPS state code (e.g. 'IL'), applied SERVER-SIDE. A full name is applied client-side instead.
countyNoCounty name (substring match, e.g. 'Cook'). When given, ALL pages for the state are scanned before filtering so no WDs are missed.
coverageYesWhich wage-determination law: 'sca' (Service Contract Act — services) or 'dba' (Davis-Bacon Act — construction). 'dba' is normalized to the API's 'dbra' index.
activeOnlyNoOnly currently-active WDs (default true).
standardOnlyNoOnly standard (non-non-standard) WDs (default true).
constructionTypeNoDBA construction type (Building | Residential | Heavy | Highway). This is the PRIMARY key for a Davis-Bacon lookup: pass state + county + constructionType to pinpoint the correct WD. E.g. Building = federal buildings, schools; Heavy = bridges, utilities; Highway = roads.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.16.0
    • addedInput schema / properties / constructionType
      Added value: +{
+  "description": "DBA construction type (Building | Residential | Heavy | Highway). This is the PRIMARY key for a Davis-Bacon lookup: pass state + county + constructionType to pinpoint the correct WD. E.g. Building = federal buildings, schools; Heavy = bridges, utilities; Highway = roads.",
+  "enum": [
+    "Building",
+    "Residential",
+    "Heavy",
+    "Highway"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / county / description
      Previous value: -"County name (substring match), applied CLIENT-SIDE over the fetched page only (the API has no county filter)."New value: +"County name (substring match, e.g. 'Cook'). When given, ALL pages for the state are scanned before filtering so no WDs are missed."
    • changedInput schema / properties / limit / description
      Previous value: -"Page size (default 20, max 50)."New value: +"Page size (default 20, max 50). Ignored when county or constructionType is given — a full-state scan is performed instead."
    • changedInput schema / properties / page / description
      Previous value: -"0-based page index (default 0)."New value: +"0-based page index (default 0). Ignored when county or constructionType is given — a full-state scan is performed instead."
    • changedInput schema / properties / state / description
      Previous value: -"2-letter USPS state code (e.g. 'VA'), applied SERVER-SIDE. A full name is applied client-side instead."New value: +"2-letter USPS state code (e.g. 'IL'), applied SERVER-SIDE. A full name is applied client-side instead."
  2. Addedv1.12.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses meaningful non-obvious behavior: a full-state scan avoids missed WDs, single-county results are ranked first, real match counts are reported, and constructionType is DBA-only. These details materially change how an agent interprets results and handles paging.

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?

The description is dense but well-organized: purpose, usage patterns, workflow, DBA construction-type mapping, and a critical caveat. Every sentence carries information; it could be slightly tightened to reduce overlap with the schema, but it remains readable and front-loaded with the most important lookup guidance.

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?

Given 9 parameters, two statutory regimes, and no output schema, this description covers selection and invocation remarkably well. It clearly explains mode-specific parameters, paging behavior, and the follow-up tool. The main gap is that it never describes the actual return shape beyond 'real match counts' and 'top result', so an agent must infer what fields are available to pass to sam_get_wage_rates.

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

Parameters4/5

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

The input schema already covers all parameters at 100%, so the baseline is 3. The description adds extra value by prescribing which parameter combinations work for SCA vs DBA, labeling constructionType as the primary DBA key, and providing concrete examples. It mostly reinforces schema detail rather than introducing wholly new semantics, but the usage patterns are genuinely helpful.

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?

The description states a specific verb ('Find') and resource ('SCA or DBA wage determination(s) for a locality'), and clearly separates lookup logic for SCA vs DBA. It also distinguishes itself from the downstream sibling sam_get_wage_rates by describing the search-then-retrieve workflow.

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

Usage Guidelines5/5

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

It gives explicit call patterns: for DBA pass state + county + constructionType; for SCA pass state + county. It also names the next tool to call (sam_get_wage_rates) and warns that query matches WD number/title only, not occupation, preventing a common mis-invocation.

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

Deploy Server

Other Tools