GSA CALC+

vendor_rate_card

Read-only

Get ceiling rates for a specific vendor, one page at a time.

For a complete vendor card or a role-specific subset (for example,
project managers), fetch every page: while has_more is true, call this
tool again with page=next_page and the same vendor_name, page_size,
ordering, and sort. Stop only when has_more is false, then combine the
pages and match the requested roles client-side.
If you stop early, say clearly that the results are partial, report
the fetched returned_range against total_rates, and explain that later
pages may contain additional matching roles or rates. Do not claim a role is absent
or present a complete role-specific rate range from a partial card.

Auto-discovers the exact vendor name via suggest-contains, then pulls
their rate records. Returns labor categories, rates, education levels,
experience requirements, SINs, contract numbers, contract end dates, and
worksite. A vendor often lists the same category twice at two prices,
one for work at the customer's site (Customer_Facility) and one at the
contractor's site (Contractor_Facility); check worksite before comparing.

Pass a partial name (e.g., 'booz' for Booz Allen Hamilton). The tool
finds the exact registered name automatically. Use part of the legal
name, not an acronym ('Science Applications', not 'SAIC').

total_rates counts rate rows, not titles: one title can have several
rows (worksite, contract, SIN). distinct_labor_categories is the number
of distinct titles (case-sensitive); when a vendor has more than 500 it
is null and distinct_labor_categories_min gives the floor.

Large vendors span many pages: Booz Allen Hamilton carries ~1,900 rate
rows (more than 500 distinct titles). The default page_size is 100 (~23KB) because a 500-row page
for a vendor that size is ~114KB and overflows MCP client output limits.
Rows are ordered by labor_category ascending by default, so a partial
card is alphabet-biased and may omit all requested roles on page 1.

There is no server-side way to intersect a vendor with a labor-category
keyword (the v3 API ignores vendor_name and labor_category as filter
fields; live-verified). To find specific categories, page through the
full card and match client-side.

If the discovery term matches multiple vendors, this tool picks the one
with the most rate records and returns a _candidates list so the caller
can re-query with a more specific term if needed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "vendor_name": "<vendor_name>"
    },
    "name": "vendor_rate_card"
  }
}

Input Schema

Name	Required	Default
`page`	No
`sort`	No	asc
`ordering`	No	labor_category
`page_size`	No
`vendor_name`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the readOnly/openWorld annotations: page-size limits and MCP output overflow risk, default labor_category ordering and alphabet bias, total_rates vs distinct_labor_categories semantics, null handling above 500 categories, duplicate labor categories by worksite, and candidate selection when discovery matches multiple vendors.

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 long but front-loads the core purpose and pagination procedure, then layers useful caveats. Some guidance is repeated in the partial-results paragraph, and the density could be tightened, but most sentences carry operational value.

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?

Complete for a paginated read tool: it explains pagination termination, partial-result handling, vendor-name discovery, output size constraints, and key return-field semantics. Because an output schema already exists, it does not need to explain every returned field in detail.

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%, so the description must carry parameter meaning, and it does: vendor_name should be a partial legal name rather than an acronym, page is used for pagination with page=next_page, page_size defaults to 100 for output-size reasons, and ordering defaults to labor_category ascending. Sort direction is also covered through the same ordering/sort pagination instructions.

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 and resource: 'Get ceiling rates for a specific vendor, one page at a time.' It also clarifies scope and distinguishes the tool's pagination model from server-side filtering by explaining that no server-side vendor+keyword intersection exists.

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?

Gives strong operational guidance: fetch every page when a complete card or role subset is needed, stop when has_more is false, and clearly label partial results if stopping early. It does not explicitly route the agent to sibling tools such as exact_search or filtered_browse for alternative approaches, so it falls short of a full when-to-use-vs-alternatives statement.

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

All GSA CALC+ tools Inspect

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.