Skip to main content
Glama
Sign In

GSA Per Diem

by com.1102tools
OverviewDiscussionsAdmin

get_data_status

Read-only

Report which fiscal years are bundled, their GSA source files, and which tools call the GSA API.

ZIP, state, and M&IE lookups for bundled fiscal years are answered from GSA's published files with no network call. City requests with a supplied county for a bundled year also need no key or network call. City-name requests without a county, and unbundled years, use the live GSA Per Diem API. Credential presence is reported without revealing or validating any value.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_data_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description clears it by disclosing the network behavior per lookup type and, notably, that credential presence is reported without revealing or validating any value. That privacy/security detail is real added context not present in structured fields. It stops short of saying whether the report is cached or how fresh the bundled-file list is.

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 core purpose is front-loaded in the first sentence, and the following lines carry genuinely useful routing detail rather than filler. It runs slightly long because it spends several lines describing the behavior of sibling lookup tools rather than this tool's own output, but every sentence is informative.

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?

With an output schema present, the description needn't enumerate return fields, and it instead supplies the operational context an agent needs: the bundled/live split, the county-and-bundled-year exception, and credential handling. For a zero-parameter status tool this is close to complete; only a hint about when the report should be refreshed is missing.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter claims are made that could mislead an agent.

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 first sentence gives a specific verb ('Report') and a precise resource set (bundled fiscal years, GSA source files, tools using the GSA API), so the tool's purpose is immediately clear. It doesn't name any sibling tool directly, but the routing explanation of which lookups hit the network versus bundled files implicitly distinguishes it from the lookup_* siblings.

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

Usage Guidelines3/5

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

The description explains the data-availability model (bundled vs. live GSA API) but never states when an agent should call get_data_status rather than compare_locations or estimate_travel_cost. Usage is only implied — you'd call it to discover what's bundled — with no explicit trigger condition or exclusion.

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

All GSA Per Diem 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