Skip to main content
Glama
govconapi

io.github.govconapi/govconapi

Official

Get Wage Rate Summary

get_wage_rate_summary
Read-onlyIdempotent

Find the regulatory labor-cost floor for any SCA occupation, aggregating base hourly percentiles and Health & Welfare fringe across wage determinations to price loaded labor for federal services bids.

Instructions

Get the labor-cost FLOOR for one occupation, aggregated across wage determinations: base hourly percentiles + Health & Welfare fringe + how many WDs set it, what a services bidder needs to price loaded labor, which on an SCA contract drives the bid far more than the award value.

Bid & Proposal / Negotiate tool, the DISTRIBUTION view, distinct from get_wage_rates
(individual county rate lines). Pair with get_labor_rate_benchmark for the awarded
(as-bid) rate comparison, this tool gives the regulatory floor instead.

- occupation_code: SCA 5-digit code, e.g. "11150" (Janitor), "27101" (Guard), the
  precise key, prefer this when known
- classification: name substring, e.g. "Guard", used when no occupation_code is given
- type: SCA (default) | DBA (CBAs have no rate table)
- state: 2-letter, scope to WDs covering that state

Response includes `distinct_classifications` (COUNT DISTINCT of matched titles), a broad `classification` substring can blend several distinct, differently-paid
titles into one distribution (e.g. "Computer" spans 10 titles from $10-$53/hr);
this discloses whether the returned label is one occupation or a blend. Prefer
`occupation_code` over `classification` whenever the pay spread matters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoSCA
stateNo
classificationNo
occupation_codeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already mark this read-only/idempotent, and the description adds significant behavioral context beyond them: it reveals the aggregation behavior, the distinct_classifications count, and the risk that a broad classification substring can blend multiple differently-paid titles into one distribution. This is genuinely useful for interpreting results and choosing parameters.

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

Conciseness5/5

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

The description is longer than average but every sentence earns its place: core definition, strategic use case, sibling distinction, explicit parameter semantics, and a behavioral caveat with concrete examples. The bullet-list parameter breakdown makes it scannable and the most important guidance is front-loaded.

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

Completeness5/5

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

Given the tool's moderate complexity, zero schema descriptions, and the presence of closely related siblings, the description is complete. It covers what the tool returns, how to choose parameters, what the field means, and how this tool differs from alternatives like get_wage_rates and get_labor_rate_benchmark.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully documents all four parameters: occupation_code with format and examples, classification as a name substring, type with SCA/DBA semantics, and state as a 2-letter scope. This more than compensates for the empty schema descriptions.

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 ('Get'), a precise resource ('labor-cost FLOOR for one occupation, aggregated across wage determinations'), and the key output components (base hourly percentiles + Health & Welfare fringe). It explicitly distinguishes this tool from siblings like get_wage_rates and get_labor_rate_benchmark, so an agent can select it correctly.

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?

The description clearly frames this as a Bid & Proposal / Negotiate tool, names the DISTRIBUTION view, and contrasts it with get_wage_rates and get_labor_rate_benchmark. It also gives concrete selection guidance: prefer occupation_code when known, use classification as fallback, and notes DBA CBAs have no rate table.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/govconapi/govconapi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server