Skip to main content
Glama

search_subawards

DoD and DHS subcontract records (FY2024 on) for a prime contract (piid) or a company as prime or as sub (role=prime|sub), biggest first. $0.02/call or 1 credit from an API key.

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": "search_subawards"
  }
}

Input Schema

NameRequiredDescriptionDefault
ueiNo
fromNoYYYY-MM-DD
piidNo
roleNo
limitNo
companyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does add real value by disclosing the cost model ($0.02/call or 1 credit via API key) and default ordering (biggest first). It says nothing about pagination, result caps, coverage limits within DoD/DHS, or auth failure behavior, which matters for a 6-param search with no safety hints.

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?

A single front-loaded sentence packing scope, filters, sort order, and pricing with no filler. Dense constructions like 'biggest first' and 'as prime or as sub' are terse to the point of mild ambiguity.

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

Completeness3/5

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

For a 6-parameter, annotation-free search tool with no output schema, the description is missing limit semantics (default/max), what uei does relative to company, and any hint of what a record contains. The cost note partially offsets this, but an agent could still mis-call it.

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 coverage is 17%, so the description must compensate; it explains piid, company, the role enum values, and implied date filtering, but leaves uei and limit entirely undefined in both schema and description. Roughly half the meaningful parameters remain opaque.

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?

States a specific resource (DoD/DHS subcontract records), a time boundary (FY2024 on), and the two lookup modes (by piid or by company), which clearly separates it from prime-award siblings like search_awards. It never names the sibling it is not, so differentiation is implicit rather than explicit.

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 conveys the query patterns (piid for a prime contract, company plus role=prime|sub for a company view) and the sort order, which implies when to reach for it. It gives no explicit exclusions or steering away from search_awards / get_sub_network for overlapping needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources