regulatory-radar

Assess compliance

assess_compliance

Read-onlyIdempotent

Screen a company's posture against applicable regulations.

Returns compliance level, percentage, gaps, and remediation priorities.
Gated obligations count only when their applicability is established from
inputs. California SB 253 needs revenue over $1B in each of the two
previous fiscal years (`annual_revenue_usd` = most recent year,
`prior_year_revenue_usd` = the year before) and an `entity_profile` with
entity_form (corporation|partnership|llc|other_business_entity),
formed_under_us_law, does_business_in_california and exemption
(none|tax_exempt_nonprofit|insurance|government_majority_owned|
wholesale_electricity_only|payroll_only). Missing inputs list it under
applicability_unconfirmed and the level is "undetermined", never
"compliant". Screening only, not legal advice.

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": {
      "company_name": "<company_name>",
      "sector": "<sector>",
      "jurisdiction": "<jurisdiction>"
    },
    "name": "assess_compliance"
  }
}

Input Schema

Name	Required	Description	Default
`sector`	Yes
`request_id`	No
`disclosures`	No
`payment_ref`	No
`company_name`	Yes
`jurisdiction`	Yes
`entity_profile`	No
`annual_revenue_usd`	No
`prior_year_revenue_usd`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / entity_profile

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Entity Profile"
+}

addedInput schema / properties / prior_year_revenue_usd

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Prior Year Revenue Usd"
+}

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / annual_revenue_usd

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Annual Revenue Usd"
+}

Changed2 schema fields changedJul 27, 2026

addedInput schema / properties / payment_ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Payment Ref"
+}

addedInput schema / properties / request_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Request Id"
+}

First observedJul 10, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds genuinely valuable behavior — that gated obligations only count when applicability is established, and that missing inputs yield 'undetermined' rather than 'compliant' — which is exactly the kind of non-obvious rule an agent needs. It does not, however, explain cost, latency, or how partial inputs change the output beyond that one rule.

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?

It is front-loaded with purpose, then results, then the gating rule, then the disclaimer. The SB 253 parenthetical is dense but justified because the schema provides no field descriptions; a few clauses (the nested enum list) are heavy but each carries real information.

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?

For a screening tool with an output schema present, the description need not detail return values, yet it names them briefly and explains the central conditional rule and the key revenue/entity inputs. It is incomplete on sector, jurisdiction, disclosures, and payment_ref, which matter for a 9-parameter tool.

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 0% across 9 parameters, so the description carries the burden and does explain annual_revenue_usd, prior_year_revenue_usd, and the entity_profile sub-fields including their enum vocabularies. It says nothing about sector, jurisdiction, disclosures, payment_ref, or request_id, leaving half the surface undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Screen a company's posture against applicable regulations,' and later clarifies scope as 'Screening only, not legal advice.' It implicitly separates this from scan_regulations (which presumably finds regulations) but never names a sibling, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Screening only, not legal advice' line sets a useful scope boundary, and the gating rules imply this tool is for scoring applicability rather than discovering rules. However, there is no explicit when-to-use/when-not guidance relative to scan_regulations, build_evidence_pack, or monitor_changes, leaving the choice to inference.

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

All regulatory-radar 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.