Skip to main content
Glama

Gsa Calc

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Gsa Labor Rates

gsa_labor_rates
Read-onlyIdempotent

GSA schedule hourly labor rates for a job title — the ceiling rate vendors may charge the government under a GSA MAS contract. Use this to benchmark what a labor category costs: "typical GSA hourly rate for a project manager", "what do senior software engineers bill under MAS", "GSA schedule rate for a data scientist with 10 years experience". Returns individual rates with vendor name, contract number, SIN, education and experience requirements, plus a price summary (min, p25, median, p75, max) computed across EVERY matching rate, not just the ones returned. Filter by experience, education, worksite, business size, security clearance and price band. Example: gsa_labor_rates({ labor_category: "software engineer", min_experience: 5 })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many individual rates to return, 1-200 (default 25). The summary always covers every matching rate regardless of this.
sort_byNoSort field (default current_price).
max_rateNoOnly rates at or below this hourly price, USD.
min_rateNoOnly rates at or above this hourly price, USD.
sort_dirNoSort direction (default asc).
worksiteNoWhere the work is performed: "contractor" (vendor site) or "customer" (government site).
educationNoMinimum education: HS, AA, BA or MA. Plain spellings work too ("bachelors", "high school"). Combine with | for several, e.g. "BA|MA".
business_sizeNo"S" for small business or "O" for other than small. "small" and "large" also work.
labor_categoryYesJob title to benchmark, e.g. "software engineer", "project manager". Partial match against contract labor categories, which are free text — prefer a short phrase over a long one.
max_experienceNoMaximum years of experience required, inclusive.
min_experienceNoMinimum years of experience required, inclusive. Means "this many OR MORE" — mapped to the upstream range filter, because the upstream field of the same name is an exact match.
security_clearanceNo"yes" to only rates requiring a clearance, "no" to exclude them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, nondestructive behavior. The description adds meaningful behavioral context: rates are ceiling prices, the summary applies to every matching rate rather than only returned rows, and returned rows include vendor, contract, SIN, and requirement fields. 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.

Conciseness5/5

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

The description is front-loaded with the core definition, followed by usage examples, return contents, filters, and an illustrative call. Every sentence adds useful information and there is no redundant restatement of the schema.

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?

Despite having no output schema, the description explains exactly what will be returned, including the individual rate fields and the price summary statistics. Combined with the fully documented input schema, an agent has enough context to call the tool correctly and interpret its results.

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?

Schema description coverage is 100%, so the schema already documents all 12 parameters. The description contributes a little extra semantic framing, such as the example call and the list of available filters, but it does not materially extend parameter-level documentation beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

The description clearly identifies the tool as a lookup/benchmark for GSA MAS labor rates by job title, and it lists concrete outputs: individual vendor rates plus a price summary. It stops short of a 5 because it does not explicitly contrast itself with sibling tools like gsa_rate_stats or gsa_vendor_rates.

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

Usage Guidelines4/5

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

It gives strong when-to-use guidance with realistic examples such as 'typical GSA hourly rate for a project manager' and 'what do senior software engineers bill under MAS'. It lacks when-not-to-use guidance or explicit routing to alternatives, so it is a 4 rather than a 5.

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

All Gsa Calc 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