Sbir

Sbir Get Award

sbir_get_award

Read-onlyIdempotent

Get full details for one SBIR/STTR award, identified by its contract number or agency tracking number (the contract/agency_tracking_number fields returned by sbir_search_awards). sbir.gov has no lookup-by-id endpoint, so this searches www.sbir.gov/awards by that identifier as a keyword and verifies a candidate's own contract/tracking number matches before returning it — start from sbir_search_awards rather than guessing an id.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

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

Input Schema

Name	Required	Description	Default
`award_id`	Yes	Contract number or agency tracking number, exactly as returned in `contract` or `agency_tracking_number` by sbir_search_awards.

Output Schema

Name	Required	Description
`city`	No	City location
`phase`	No	Funding phase
`state`	No	2-letter state code
`agency`	Yes	Funding agency code
`branch`	No	Agency branch or division
`company`	Yes	Company name
`program`	No	SBIR/STTR program type
`abstract`	No	Award abstract or summary
`award_id`	No	Unique award identifier
`award_year`	No	Year award was made
`topic_code`	No	Topic or program code
`award_title`	Yes	Title of the award
`award_amount`	No	Award amount in dollars

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "award_id": "W911NF-22-C-0033"
-  }
-]New value: +[
+  {
+    "award_id": "2537984"
+  }
+]

changedInput schema / properties / award_id / description

Previous value: -"Contract number or agency tracking number, exactly as returned in `award_id` or `contract` by sbir_search_awards."New value: +"Contract number or agency tracking number, exactly as returned in `contract` or `agency_tracking_number` by sbir_search_awards."

Changed2 schema fields changedJul 31, 2026

changedInput schema / examples

Previous value: -[
-  {
-    "award_id": "2024-DOD-SB241-001"
-  }
-]New value: +[
+  {
+    "award_id": "W911NF-22-C-0033"
+  }
+]

changedInput schema / properties / award_id / description

Previous value: -"The unique award ID"New value: +"Contract number or agency tracking number, exactly as returned in `award_id` or `contract` by sbir_search_awards."

Changed1 schema field changedMay 13, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "abstract": {
+      "description": "Award abstract or summary",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "agency": {
+      "description": "Funding agency code",
+      "type": "string"
+    },
+    "award_amount": {
+      "description": "Award amount in dollars",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "award_id": {
+      "description": "Unique award identifier",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "award_title": {
+      "description": "Title of the award",
+      "type": "string"
+    },
+    "award_year": {
+      "description": "Year award was made",
+      "type": [
+        "number",
+        "string",
+        "null"
+      ]
+    },
+    "branch": {
+      "description": "Agency branch or division",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "city": {
+      "description": "City location",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "company": {
+      "description": "Company name",
+      "type": "string"
+    },
+    "phase": {
+      "description": "Funding phase",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "program": {
+      "description": "SBIR/STTR program type",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "state": {
+      "description": "2-letter state code",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "topic_code": {
+      "description": "Topic or program code",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "company",
+    "agency",
+    "award_title"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "award_id": "2024-DOD-SB241-001"
+  }
+]

First observedApr 22, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, so the bar is lower, yet the description still adds real context beyond them: there is no lookup-by-id endpoint, so the tool performs a keyword search against www.sbir.gov/awards and verifies the candidate's own contract/tracking number matches before returning. It does not say what happens when no candidate matches (error vs empty), which is the one behavioral gap.

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?

Two compact sentences that front-load what the tool does, then the lookup constraint and the routing advice. Dense but every clause carries information; the em-dash aside about the missing lookup endpoint is slightly long but justified.

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 so return values need not be explained, and the description covers identity input, resolution mechanism, and the upstream tool to call first. Only the no-match/failure outcome is unaddressed, which is a minor omission for a single-parameter read tool.

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 100% and the single parameter's description already states it must be the contract number or agency tracking number exactly as returned by sbir_search_awards, so the description largely repeats the schema rather than adding new semantics. Baseline 3 applies because the schema fully carries the parameter burden.

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 (get) and resource (full details for one SBIR/STTR award) plus the identity key (contract number or agency tracking number), which cleanly distinguishes it from the sibling sbir_search_awards that returns many awards.

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 routes the agent: 'start from sbir_search_awards rather than guessing an id,' and names the fields of that tool that supply the argument. It says when-not (guessing an id) as well as the alternative, which is the strongest form of guidance.

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

All Sbir 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.