GSA CALC+

sin_analysis

Read-only

Get rate distribution and statistics for a specific SIN.

Returns rate statistics, education breakdown, business size breakdown,
and labor_categories for a GSA MAS Special Item Number: the 25 titles
with the most rates on the SIN, with counts (exact, case-sensitive
titles). It does not return individual rate rows or per-title prices;
for what a title costs on the SIN, call igce_benchmark(title, sin=...).
When GSA's 500-title list is cut off, labor_categories.distinct is null
and records_in_titles_not_listed counts the rates under titles not
listed.

Common SINs for professional services (live-verified to return records):
- 54151S: IT Professional Services
- 541611: Management and Financial Consulting
- 541715: Engineering R&D
- 541330ENG: Engineering Services
- 561210FAC: Facilities Maintenance and Management
- 611430: Training

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": {
      "sin_code": "<sin_code>"
    },
    "name": "sin_analysis"
  }
}

Input Schema

Name	Required	Description	Default
`sin_code`	Yes
`page_size`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), and the description adds real behavior beyond them: the 25-title cap, case-sensitive exact title matching, the truncation failure mode where labor_categories.distinct is null and records_in_titles_not_listed counts the remainder. It also flags the sample SINs as live-verified, which tells the agent these are known-good inputs.

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?

Front-loaded with purpose and return shape, then the exclusion, then the edge case, then examples — a sensible priority order. The six-item SIN list is long but earns its place because it substitutes for missing enums; only minor trimming is possible without losing value.

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?

An output schema exists, yet the description still usefully names the returned sections (statistics, education breakdown, business size breakdown, labor_categories) and handles the truncation edge case. The remaining gap is page_size: with 2 parameters and a paginated result, the agent has no guidance on when or why to change the default of 100.

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 0%, so the description must carry both parameters. It partially compensates for sin_code by listing six concrete, live-verified SIN values (valuable given there are no enums), but says nothing about the string-or-integer anyOf union or case-sensitivity of the code itself. page_size is never mentioned in the description at all, leaving one of two parameters fully undocumented.

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?

Opens with a specific verb+resource pair ("Get rate distribution and statistics for a specific SIN") and immediately delimits scope: it returns aggregate statistics, not individual rate rows or per-title prices. An agent can tell this apart from igce_benchmark and the search siblings without opening any schema.

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?

Explicitly states the negative case ("It does not return individual rate rows or per-title prices") and routes to the correct alternative with the exact call form: igce_benchmark(title, sin=...). That is a concrete when-not plus a named alternative, which is the top of this dimension.

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.