Skip to main content
Glama
Sign In

SignalTender B2B, GovCon & LegalTech MCP Server

by io.github.aarbchen
OverviewDiscussionsAdmin

Audit Contract Risks & Generate Legal Redlines

audit_contract_risks
Read-onlyIdempotent

Audit commercial and B2B legal agreements (MSAs, NDAs, SaaS terms, subcontracts) to detect high-risk clauses, compute a 0-100 overall risk score, and generate verbatim clause quotes paired with ready-to-paste fallback redline language. This operation is read-only, stateless, and non-destructive (requires X-RapidAPI-Key; raw_text accepts 50 to 100,000 characters, and party_perspective shifts redline rewrites to protect the 'vendor', 'buyer', or 'neutral' counsel). Use this tool when reviewing commercial/legal terms (indemnification, liability caps, IP ownership, termination for convenience); use scan_far_dfars_clauses instead for federal FAR/DFARS/CMMC regulatory flow-down audits, or parse_b2b_contract for basic metadata extraction.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "raw_text": "<raw_text>"
    },
    "name": "audit_contract_risks"
  }
}

Input Schema

NameRequiredDescriptionDefault
raw_textYesFull or partial legal contract text (MSA, NDA, subcontract, or SaaS agreement) to audit for commercial, IP, indemnification, and termination risks (50 to 100,000 characters).
focus_categoriesNoOptional list of specific clause risk categories to prioritize during the audit.
party_perspectiveNoNegotiating party perspective ('vendor' protects service provider liability/IP, 'buyer' strengthens customer remedies/SLAs, 'neutral' balances mutual terms).vendor

Output Schema

NameRequiredDescriptionDefault
contract_typeNoIdentified legal document type (e.g., 'Master Services Agreement', 'Mutual NDA', 'Statement of Work').
flagged_clausesNoDetailed list of risky clauses identified in the contract, ordered by severity.
executive_summaryNoHigh-level deal-desk summary of the contract's risk posture and primary negotiation blockers.
party_perspectiveNoThe negotiating perspective used to evaluate risks ('vendor', 'buyer', or 'neutral').
overall_risk_levelNoAggregate risk severity classification ('LOW', 'MEDIUM', 'HIGH', or 'CRITICAL').
overall_risk_scoreNoQuantified overall risk score from 0 (minimal risk) to 100 (critical/unacceptable exposure).
missing_standard_protectionsNoList of standard protective clauses missing from the contract (e.g., 'No Limitation of Liability cap').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / focus_categories / default
      Added value: +[
+  "INDEMNIFICATION",
+  "LIMITATION_OF_LIABILITY",
+  "TERMINATION",
+  "IP_OWNERSHIP"
+]
    • addedInput schema / properties / focus_categories / items / enum
      Added value: +[
+  "INDEMNIFICATION",
+  "LIMITATION_OF_LIABILITY",
+  "TERMINATION",
+  "IP_OWNERSHIP",
+  "PAYMENT_TERMS",
+  "AUTO_RENEWAL",
+  "CONFIDENTIALITY",
+  "DATA_PRIVACY_SECURITY",
+  "NON_COMPETE_EXCLUSIVITY",
+  "GOVERNING_LAW_DISPUTE",
+  "WARRANTY_SLA",
+  "OTHER"
+]
  2. Changed9 schema fields changed
    • addedInput schema / properties / focus_categories
      Added value: +{
+  "description": "Optional list of specific clause risk categories to prioritize during the audit.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 100,
+  "type": "array"
+}
    • addedOutput schema / properties / contract_type
      Added value: +{
+  "description": "Identified legal document type (e.g., 'Master Services Agreement', 'Mutual NDA', 'Statement of Work').",
+  "type": "string"
+}
    • addedOutput schema / properties / executive_summary
      Added value: +{
+  "description": "High-level deal-desk summary of the contract's risk posture and primary negotiation blockers.",
+  "type": "string"
+}
    • changedOutput schema / properties / flagged_clauses / description
      Previous value: -"Detected risky clauses with verbatim quote, risk rationale, and recommended redline replacement."New value: +"Detailed list of risky clauses identified in the contract, ordered by severity."
    • addedOutput schema / properties / missing_standard_protections
      Added value: +{
+  "description": "List of standard protective clauses missing from the contract (e.g., 'No Limitation of Liability cap').",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / overall_risk_level
      Added value: +{
+  "description": "Aggregate risk severity classification ('LOW', 'MEDIUM', 'HIGH', or 'CRITICAL').",
+  "type": "string"
+}
    • changedOutput schema / properties / overall_risk_score / description
      Previous value: -"Composite contract risk score from 0 (low risk) to 100 (critical risk)."New value: +"Quantified overall risk score from 0 (minimal risk) to 100 (critical/unacceptable exposure)."
    • addedOutput schema / properties / party_perspective
      Added value: +{
+  "description": "The negotiating perspective used to evaluate risks ('vendor', 'buyer', or 'neutral').",
+  "type": "string"
+}
    • removedOutput schema / properties / risk_level
      Removed value: -{
-  "description": "Qualitative risk tier (LOW, MODERATE, HIGH, CRITICAL).",
-  "type": "string"
-}
  3. Changed5 schema fields changed
    • changedInput schema / properties / party_perspective / description
      Previous value: -"Negotiating perspective for redline generation ('vendor', 'buyer', or 'neutral')."New value: +"Negotiating party perspective ('vendor' protects service provider liability/IP, 'buyer' strengthens customer remedies/SLAs, 'neutral' balances mutual terms)."
    • changedInput schema / properties / raw_text / description
      Previous value: -"Full or partial contract text to audit for legal and commercial risks."New value: +"Full or partial legal contract text (MSA, NDA, subcontract, or SaaS agreement) to audit for commercial, IP, indemnification, and termination risks (50 to 100,000 characters)."
    • addedInput schema / properties / raw_text / maxLength
      Added value: +100000
    • addedInput schema / properties / raw_text / minLength
      Added value: +50
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "flagged_clauses": {
+      "description": "Detected risky clauses with verbatim quote, risk rationale, and recommended redline replacement.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "overall_risk_score": {
+      "description": "Composite contract risk score from 0 (low risk) to 100 (critical risk).",
+      "type": "integer"
+    },
+    "risk_level": {
+      "description": "Qualitative risk tier (LOW, MODERATE, HIGH, CRITICAL).",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  4. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the sentence 'read-only, stateless, non-destructive' largely restates them. It does add context annotations cannot carry: the X-RapidAPI-Key auth requirement, the 50-100,000 character input bound, and the fact that party_perspective changes the generated redlines. No return-format or rate-limit detail, but the output schema covers returns.

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?

Three sentences with purpose, behavior, and sibling routing in that order, so the most important information is front-loaded. Every clause is functional, though the first sentence is dense and some phrasing duplicates the schema's length bounds.

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?

An output schema exists, so the description need not spell out return values, yet it still signals the score, quotes, and redlines. Combined with the auth requirement, input bounds, perspective semantics, and explicit routing to two siblings, an agent has everything needed to call it correctly.

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 all three parameters are already documented, including the focus_categories enum and defaults. The description reinforces the raw_text length window and explains that party_perspective steers redline rewrites to protect 'vendor', 'buyer', or 'neutral', which is slightly deeper than the schema wording. It never mentions focus_categories at all, so it stays at the baseline rather than earning a 4.

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) plus the resource (commercial/B2B agreements: MSAs, NDAs, SaaS terms, subcontracts) and the concrete outputs (0-100 risk score, verbatim clause quotes, fallback redline language). It also names the sibling tools it is not, so an agent can separate it from scan_far_dfars_clauses and parse_b2b_contract without opening a schema.

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 says when to use it (reviewing commercial/legal terms such as indemnification, liability caps, IP ownership, termination for convenience) and names two alternatives with the condition that selects each: scan_far_dfars_clauses for federal FAR/DFARS/CMMC flow-downs, parse_b2b_contract for metadata extraction. 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 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