sbir_company_awardsGet complete SBIR/STTR award history for a company. Returns all awards with amounts, agencies, topics, and funding phases.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (default 50) | |
| company | Yes | Company name to search for |
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | Number of awards returned | |
| awards | Yes | ||
| company | Yes | Company name searched |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesPrevious value: -[
- {
- "company": "Acme Technologies Inc.",
- "limit": 50
- }
-]New value: +[
+ {
+ "company": "Luna",
+ "limit": 50
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "awards": {
+ "items": {
+ "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"
+ },
+ "type": "array"
+ },
+ "company": {
+ "description": "Company name searched",
+ "type": "string"
+ },
+ "count": {
+ "description": "Number of awards returned",
+ "type": "number"
+ }
+ },
+ "required": [
+ "company",
+ "count",
+ "awards"
+ ],
+ "type": "object"
+}Input schema / examplesAdded value: +[
+ {
+ "company": "Acme Technologies Inc.",
+ "limit": 50
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to return 'all awards' and calls it 'complete history,' but the schema includes a limit parameter with a default of 50, suggesting the result may be truncated by default. This is a significant behavioral discrepancy. Annotations (readOnlyHint, idempotentHint) cover safety, but the description undermines trust by overpromising completeness without addressing pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get,' and efficiently communicates the core function and expected output fields. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 no further explanation. However, the description omits critical details about the limit parameter's effect on 'completeness' and does not mention pagination strategies. This is a notable gap for a tool that promises 'complete award history,' despite good annotations and schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (company and limit), so the description adds minimal parameter-level meaning. It does not clarify how to achieve a truly complete history despite the 'all awards' claim, which would be valuable. The baseline of 3 applies since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get complete SBIR/STTR award history for a company' with specific return fields (amounts, agencies, topics, funding phases). The verb 'Get' and resource 'award history' are precise, and the company-specific scope distinguishes it from sibling search tools like sbir_search_awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a company's full award history, which is a clear usage context. However, it does not explicitly name alternatives (e.g., sbir_search_awards) or state when not to use this tool, so it falls short of a full 5. The company-focused input makes the primary use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.