Skip to main content
Glama

Sbir

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Sbir Agency Stats

sbir_agency_stats
Read-onlyIdempotent

"How many SBIR awards did DOE make last year, and how much total funding?" / "SBIR award count and dollar total for NASA in 2024" — per-agency SBIR/STTR TOTALS, live from www.sbir.gov/awards (the same source sbir_search_awards uses). Specify agency (e.g. "DOD", "NASA", "DOE") and, optionally, year to scope the count — year is the CALENDAR year sbir.gov's own "Award Year" field assigns to the award (verified against sbir.gov/awards' own year[YYYY] filter and each award's detail page, not a federal fiscal year). award_count is always exact: sbir.gov/awards states a precise "Showing X-Y of N results" total, never an "at least" estimate. When agency is given, this also returns funding_total: the dollar sum of award amounts across the matched awards. sbir.gov/awards has no funding-total aggregate of its own — the dollar amount lives only on each award's own detail page, one fetch per award — so funding_total sums at most the first 25 matching awards and sets funding_total_complete: true only when that covers every match; otherwise funding_total_complete: false and funding_note says how many of how many were actually summed (narrow with sbir_search_awards' company/state/keyword filters to bring a large match count under 25 for an exact sum — never trust a false total as the real figure). Omit agency to see counts only (no funding_total — aggregating funding across all major agencies in one call would mean hundreds of detail-page fetches) across the major agencies (DOD, HHS, NASA, NSF, DOE, USDA) at once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoFilter by award year (e.g., 2025) — sbir.gov's own calendar-year "Award Year" field, same as sbir_search_awards' `year` filter. Omit for an all-time total.
agencyNoSpecific agency to count, e.g. "DOD", "NASA", "NSF". Omit to cover all major agencies (count-only, no funding_total).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "agency": "DOW"
-  },
-  {}
-]New value: +[
+  {
+    "agency": "NASA"
+  },
+  {
+    "agency": "DOE",
+    "year": 2025
+  },
+  {}
+]
    • changedInput schema / properties / agency / description
      Previous value: -"Specific agency to count, e.g. \"DOW\" (formerly DOD), \"NASA\", \"NSF\". Omit to cover all major agencies. Note SBIR publishes no total-count field, so a result at the page cap reports `award_count_at_least` rather than a total."New value: +"Specific agency to count, e.g. \"DOD\", \"NASA\", \"NSF\". Omit to cover all major agencies (count-only, no funding_total)."
    • addedInput schema / properties / year
      Added value: +{
+  "description": "Filter by award year (e.g., 2025) — sbir.gov's own calendar-year \"Award Year\" field, same as sbir_search_awards' `year` filter. Omit for an all-time total.",
+  "type": "number"
+}
  2. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "agency": "DOD"
-  },
-  {}
-]New value: +[
+  {
+    "agency": "DOW"
+  },
+  {}
+]
    • changedInput schema / properties / agency / description
      Previous value: -"Specific agency to get count for (e.g., \"DOD\", \"NASA\"). Omit to get counts for all major agencies."New value: +"Specific agency to count, e.g. \"DOW\" (formerly DOD), \"NASA\", \"NSF\". Omit to cover all major agencies. Note SBIR publishes no total-count field, so a result at the page cap reports `award_count_at_least` rather than a total."
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "oneOf": [
+    {
+      "properties": {
+        "agency": {
+          "description": "Agency code",
+          "type": "string"
+        },
+        "award_count": {
+          "description": "Total award count for agency",
+          "type": "number"
+        }
+      },
+      "required": [
+        "agency",
+        "award_count"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "agencies": {
+          "items": {
+            "properties": {
+              "agency": {
+                "description": "Agency code",
+                "type": "string"
+              },
+              "award_count": {
+                "description": "Total award count for agency",
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "error": {
+                "description": "Error message if retrieval failed",
+                "type": "string"
+              }
+            },
+            "required": [
+              "agency"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "agencies"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  4. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "agency": "DOD"
+  },
+  {}
+]
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent safety, but the description adds substantial behavioral context beyond them: `award_count` is always exact, `funding_total` sums at most the first 25 matches with a `funding_total_complete` flag and `funding_note`, and omitting `agency` suppresses funding_total entirely because it would require hundreds of detail-page fetches. That is exactly the caveat an agent needs to avoid misusing a `false` total.

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 definition is front-loaded with concrete example queries and then explains mechanism in order of importance. It is dense but most sentences earn their place; there is mild redundancy around the funding_total limitation repeated in both the agency-present and agency-omitted paths.

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?

With an output schema present, the description need not enumerate return fields, yet it still explains the non-obvious semantics an agent must understand (the funding_total truncation response fields, and that omitting `agency` changes the response shape). Nothing needed to call it correctly is missing.

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 100%, so both parameters are already documented, including the calendar-year 'Award Year' semantics of `year` and the count-only behavior when `agency` is omitted. The description largely restates these (calendar year vs fiscal year is duplicated in the schema) and only adds marginal value through extra agency string examples, so the baseline 3 applies.

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?

The description states a specific verb+resource+scope: per-agency SBIR/STTR award counts and dollar totals from sbir.gov/awards. It explicitly distinguishes itself from siblings by noting it draws from 'the same source sbir_search_awards uses' and by framing itself as a totals/aggregate tool rather than a search tool.

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?

It gives explicit when-to-use guidance (asks like 'How many SBIR awards did DOE make last year?'), names the alternative to use for narrowing (sbir_search_awards' company/state/keyword filters), and states the condition that changes behavior (omit `agency` for count-only across major agencies). Nothing is left to inference.

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

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