Skip to main content
Glama
Sign In

SignalTender B2B, GovCon & LegalTech MCP Server

by io.github.aarbchen
OverviewDiscussionsAdmin

Generate SBIR / STTR Phase I–III Technical Work Plan, TRL Matrix & Commercialization Plan

generate_sbir_sttr_commercialization
Read-onlyIdempotent

Convert R&D technical specifications and an SBIR/STTR solicitation topic description into a DoD/AFWERX/SpaceWERX/NSF SBIR/STTR Technical Work Plan, a TRL 1–9 progression matrix, a Phase III Dual-Use Commercialization & Transition Plan, and a pre-award DFARS 252.227-7018 / FAR 52.227-20 SBIR Data Rights assertion schedule. This is a read-only, stateless, non-destructive R&D proposal and IP compliance generator (requires X-RapidAPI-Key; sbir_sttr_topic_and_rd_specs accepts 20 to 45,000 characters and company_technology_and_ip_baseline accepts 20 to 35,000 characters). Use this tool when preparing Phase I, Phase II, Direct-to-Phase II (AFWERX/SpaceWERX), or Phase III SBIR/STTR technical volumes, commercialization plans, and DFARS 252.227-7018 IP data-rights tables; use generate_rfp_response instead for standard FAR Part 15 technical approach volumes, or scan_far_dfars_clauses for general Section I clause flow-down audits.

Input Schema

NameRequiredDescriptionDefault
target_phase_and_programNoTarget SBIR/STTR phase ('Phase_I_Feasibility_and_Proof_of_Concept', 'Direct_to_Phase_II_or_Phase_II_Prototype', 'Phase_IIB_or_STRATFI_TACFI_Matching', or 'Phase_III_Sole_Source_Transition_15_USC_638_r_4').Direct_to_Phase_II_or_Phase_II_Prototype
sbir_sttr_topic_and_rd_specsYesFull or excerpted DoD, AFWERX, SPACEWERX, Navy, Army, DARPA, NSF, NASA, or DHS SBIR/STTR topic instructions, Phase I/II/III technical objectives, and evaluation criteria (20 to 45,000 characters).
sponsoring_agency_or_programNoOptional sponsoring agency, PEO, or Phase III transition customer (e.g., USAF AFWERX / SpaceWERX, Office of Naval Research, NSF TIP).USAF AFWERX / DoD DSIP
company_technology_and_ip_baselineYesSummary of the small business offeror's R&D technology, current TRL, Principal Investigator (PI) credentials, prior IRAD/patents, STTR university/lab partner (if applicable), and dual-use commercial traction (20 to 35,000 characters).

Output Schema

NameRequiredDescriptionDefault
trl_progression_and_technical_work_planNoStructured Phase I/II Technical Work Plan and TRL 1-9 progression milestones with quantifiable exit criteria.
executive_technical_and_dual_use_summaryNoExecutive summary of the R&D innovation, warfighter/agency operational impact, and commercial dual-use market thesis.
recommended_phase_and_transition_pathwayNoStrategic SBIR/STTR pursuit and transition recommendation.
sbir_pwin_and_transition_readiness_scoreNo0-100 score evaluating technical merit, TRL feasibility, dual-use commercialization potential, and Phase III Program-of-Record transition readiness.
dfars_252_227_7018_sbir_data_rights_assertionsNoPre-populated DFARS 252.227-7018 / FAR 52.227-20 SBIR/STTR Data Rights Assertion Table protecting core IP for 20 years.
phase_iii_dual_use_commercialization_and_work_plan_narrativeNoComplete, paste-ready SBIR/STTR Volume 2 Technical Work Plan & Commercialization Plan narrative including Customer Memorandum (MOU) justification, TAM/SAM/SOM dual-use revenue forecast, and 15 U.S.C. § 638(r)(4) Phase III sole-source transition roadmap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / sponsoring_agency_or_program
      Added value: +{
+  "default": "USAF AFWERX / DoD DSIP",
+  "description": "Optional sponsoring agency, PEO, or Phase III transition customer (e.g., USAF AFWERX / SpaceWERX, Office of Naval Research, NSF TIP).",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / target_phase_and_program / description
      Previous value: -"Target SBIR/STTR phase ('Phase_I_Feasibility_and_Proof_of_Concept', 'Direct_to_Phase_II_or_Phase_II_Prototype' [default], 'Phase_IIB_or_STRATFI_TACFI_Matching', or 'Phase_III_Sole_Source_Transition_15_USC_638_r_4')."New value: +"Target SBIR/STTR phase ('Phase_I_Feasibility_and_Proof_of_Concept', 'Direct_to_Phase_II_or_Phase_II_Prototype', 'Phase_IIB_or_STRATFI_TACFI_Matching', or 'Phase_III_Sole_Source_Transition_15_USC_638_r_4')."
    • removedInput schema / properties / target_phase_and_program / enum
      Removed value: -[
-  "Phase_I_Feasibility_and_Proof_of_Concept",
-  "Direct_to_Phase_II_or_Phase_II_Prototype",
-  "Phase_IIB_or_STRATFI_TACFI_Matching",
-  "Phase_III_Sole_Source_Transition_15_USC_638_r_4"
-]
    • addedInput schema / properties / target_phase_and_program / maxLength
      Added value: +120
    • addedInput schema / properties / target_phase_and_program / minLength
      Added value: +1
    • changedOutput schema / properties / phase_iii_dual_use_commercialization_and_work_plan_narrative / description
      Previous value: -"Complete, paste-ready SBIR/STTR Volume 2 Technical Work Plan & Commercialization Plan narrative including Customer MOU justification, TAM/SAM/SOM dual-use revenue forecast, and 15 U.S.C. 638(r)(4) Phase III sole-source transition roadmap."New value: +"Complete, paste-ready SBIR/STTR Volume 2 Technical Work Plan & Commercialization Plan narrative including Customer Memorandum (MOU) justification, TAM/SAM/SOM dual-use revenue forecast, and 15 U.S.C. § 638(r)(4) Phase III sole-source transition roadmap."
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description largely restates those traits but adds genuinely new operational facts – an X-RapidAPI-Key is required, the tool is stateless, and the two primary inputs have 20 to 45,000 / 20 to 35,000 character bounds. It stops short of noting any latency or rate-limit behavior, but the output schema covers return shape, so a 4 is appropriate.

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 deliverable enumeration is front-loaded and each clause carries real information about scope and routing. It loses a point for restating annotation-derived traits ('read-only, stateless, non-destructive') and for a long, load-bearing final sentence that packs three use cases and two alternatives into one run-on.

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?

For a generator with four parameters, an output schema, and full annotation coverage, nothing an agent needs is missing: it knows the artifacts produced, the required inputs and their size bounds, the auth requirement, and where to go when the task is actually a FAR Part 15 response or a clause audit. Return format is delegated to the output schema, which is the correct division of labor.

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 the baseline is 3. The description's parameter content (character ranges for the two required fields) is already stated as minLength/maxLength in the schema, and it does not add examples or clarify the enumerated phase values beyond what the schema's description already lists. It neither compensates for nor adds beyond the schema here.

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 names a specific verb (convert) and enumerates the exact artifacts produced: Technical Work Plan, TRL 1–9 progression matrix, Phase III Dual-Use Commercialization & Transition Plan, and a DFARS/FAR data-rights assertion schedule. It also names the inputs it consumes (topic description + company R&D/IP baseline), so the tool is unmistakable against siblings like generate_rfp_response or generate_data_rights_assertion_table.

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 states exactly when to use this tool (Phase I, Phase II, Direct-to-Phase II AFWERX/SpaceWERX, Phase III technical volumes; commercialization plans; DFARS 252.227-7018 IP tables) and explicitly routes two adjacent needs elsewhere: generate_rfp_response for FAR Part 15 technical approach and scan_far_dfars_clauses for general Section I flow-down audits. That is the when/when-not/alternative triad in full.

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

All SignalTender B2B, GovCon & LegalTech MCP Server 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