SignalTender B2B, GovCon & LegalTech MCP Server

Generate DFARS 252.227-7017 & FAR 52.227-14 IP & Data Rights Assertion Table

generate_data_rights_assertion_table

Read-onlyIdempotent

Audit software components, AI/ML models and weights, firmware, technical data packages, and CDRL deliverables by development funding history (100% private expense, SBIR/STTR, mixed funding, or government-funded) to generate a 4-column DFARS 252.227-7017 Data Rights Assertion Table, verbatim DFARS 252.227-7013/7014/7018 and FAR 52.227-14 restrictive marking legends, a 10 U.S.C. 4401 Modular Open Systems Approach (MOSA) boundary and DFARS 252.227-7027 deferred-ordering protection plan, and a pre-award IP negotiation checklist. This is a read-only, stateless, non-destructive Government Contracts IP compliance generator (requires X-RapidAPI-Key; software_modules_and_cdrl_deliverables_text accepts 20 to 45,000 characters, while governing_acquisition_regime and modular_open_systems_approach_mosa_context calibrate DoD DFARS vs. Civilian FAR data rights rules and 10 U.S.C. 4401 open interface boundaries). Use this tool when building a proposal's DFARS 252.227-7017 / FAR 52.227-14 Data Rights Assertion Table, verbatim restrictive legends, or MOSA IP segregation plan; use generate_sbir_sttr_commercialization instead for full SBIR/STTR Phase I-III work plans, or scan_far_dfars_clauses for general Section I FAR/DFARS clause scanning.

Input Schema

Name	Required	Description	Default
`governing_acquisition_regime`	No	Applicable IP clause framework: DoD DFARS 252.227-7013/7014/7015/7017/7018 (SBIR) or Civilian FAR 52.227-14 / 52.227-19 (defaults to 'DoD_DFARS_252_227_7013_7014_7015_7017_And_7018').	DoD_DFARS_252_227_7013_7014_7015_7017_And_7018
`modular_open_systems_approach_mosa_context`	No	10 U.S.C. 4401 Modular Open Systems Approach (MOSA) interface strategy separating open APIs/form-fit-function data from proprietary source code and model weights (defaults to 'MOSA_Open_API_Boundary_Preserving_Proprietary_Core_Algorithms').	MOSA_Open_API_Boundary_Preserving_Proprietary_Core_Algorithms
`software_modules_and_cdrl_deliverables_text`	Yes	Inventory of software components, AI/ML models, weights, firmware, technical data packages, and CDRL deliverables with their development funding history (100% private expense, mixed funding, SBIR/STTR, or government-funded; 20 to 45,000 characters).

Output Schema

Name	Required	Description
`status`	No	Execution status ('success').
`ip_strategy_executive_overview`	No	Executive summary of the data rights assertion posture, background IP protection, and MOSA alignment.
`dfars_252_227_7017_assertion_table`	No	Complete 4-column DFARS 252.227-7017 Identification and Assertion of Use, Release, or Disclosure Restrictions table.
`pre_award_ip_negotiation_checklist`	No	Pre-award checklist for submitting the signed DFARS 252.227-7017 attachment with the proposal and negotiating Specially Negotiated License Rights.
`restrictive_marking_and_legend_templates`	No	Verbatim DFARS/FAR restrictive legends and placement instructions for source code, binaries, and technical data deliverables.
`mosa_and_deferred_ordering_protection_plan`	No	10 U.S.C. § 4401 MOSA interface boundary plan, black-box encapsulation strategy, and DFARS 252.227-7027/7037 audit defense.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 29, 2026

changedOutput schema / properties / mosa_and_deferred_ordering_protection_plan / description

Previous value: -"10 U.S.C. 4401 MOSA interface boundary plan, black-box encapsulation strategy, and DFARS 252.227-7027/7037 audit defense."New value: +"10 U.S.C. § 4401 MOSA interface boundary plan, black-box encapsulation strategy, and DFARS 252.227-7027/7037 audit defense."

changedOutput schema / properties / pre_award_ip_negotiation_checklist / description

Previous value: -"Pre-award checklist for submitting the signed DFARS 252.227-7017 attachment and negotiating Specially Negotiated License Rights."New value: +"Pre-award checklist for submitting the signed DFARS 252.227-7017 attachment with the proposal and negotiating Specially Negotiated License Rights."

AddedOct 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world, so safety needs little defense. The description adds genuinely new operational facts: an X-RapidAPI-Key is required and the call is stateless. It does not discuss determinism of generated legal legends or edge-case handling, which would be the remaining useful detail given the compliance stakes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and output inventory are front-loaded, which is good, but the parenthetical re-specifies character limits, the third parameter's accepted range, and the optional parameters' roles — all already in the schema. The result is a dense, hyphen-heavy block where a sentence of redundant detail dilutes the routing guidance.

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 no explanation, and annotations are rich. The description still covers the auth key, statelessness, input-size bounds, and the full set of generated artifacts — enough for an agent to call it correctly. Only nuance around determinism or input-token expectations is absent.

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 parenthetical about how `governing_acquisition_regime` and `modular_open_systems_approach_mosa_context` 'calibrate' DoD vs. Civilian rules and 10 U.S.C. 4401 boundaries largely restates the schema's own parameter descriptions, adding only light framing about how the two axes interact.

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 (audit / generate) and a highly specific resource: a 4-column DFARS 252.227-7017 Data Rights Assertion Table plus DFARS/FAR restrictive legends and a MOSA boundary plan. The artifact produced is unmistakable, and no sibling tool produces an IP assertion table, so it is trivially distinguishable.

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 states when to use it ('when building a proposal's DFARS 252.227-7017 / FAR 52.227-14 Data Rights Assertion Table, verbatim restrictive legends, or MOSA IP segregation plan') and names two alternatives with their distinct scopes. Each routing condition maps to a concrete deliverable.

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