viridis-agent-fleet

Overview Schema Source Related Servers Discussions Admin

regulatory-radar__scan_regulations

[regulatory-radar — CSRD/TNFD compliance-as-a-service] Scan a jurisdiction (e.g. EU, US, california, or CA for Canada), optionally filtered by sector.

Instructions

[regulatory-radar — CSRD/TNFD compliance-as-a-service] Scan a jurisdiction (e.g. EU, US, california, or CA for Canada), optionally filtered by sector.

Returns regulations with urgency flags and effective dates. Price: $0.25 per call after 10 free calls/day. Pay at /x402/regulatory-radar/scan_regulations with Base USDC, cash-fund payment_ref through escrow_checkout + confirm_escrow_funding, or use /seats.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sector`	No
`request_id`	No
`payment_ref`	No
`jurisdiction`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.13Sep 13, 2026

addedInput schema / properties / request_id

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

Changed10 schema fields changedv0.1.11Jul 18, 2026
- addedInput schema / properties / jurisdiction / title
```
Added value: +"Jurisdiction"
```
- addedInput schema / properties / payment_ref / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / payment_ref / default
```
Added value: +null
```
- addedInput schema / properties / payment_ref / title
```
Added value: +"Payment Ref"
```
- removedInput schema / properties / payment_ref / type
```
Removed value: -"string"
```
- addedInput schema / properties / sector / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / sector / default
```
Added value: +null
```
- addedInput schema / properties / sector / title
```
Added value: +"Sector"
```
- removedInput schema / properties / sector / type
```
Removed value: -"string"
```
- addedInput schema / title
```
Added value: +"scan_regulationsArguments"
```
Changed7 schema fields changedv0.1.9Jul 16, 2026
- removedInput schema / properties / jurisdiction / title
```
Removed value: -"Jurisdiction"
```
- addedInput schema / properties / payment_ref
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / sector / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / sector / default
```
Removed value: -null
```
- removedInput schema / properties / sector / title
```
Removed value: -"Sector"
```
- addedInput schema / properties / sector / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"scan_regulationsArguments"
```
Changed6 schema fields changedJul 13, 2026
- addedInput schema / properties / jurisdiction / title
```
Added value: +"Jurisdiction"
```
- addedInput schema / properties / sector / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- addedInput schema / properties / sector / default
```
Added value: +null
```
- addedInput schema / properties / sector / title
```
Added value: +"Sector"
```
- removedInput schema / properties / sector / type
```
Removed value: -"string"
```
- addedInput schema / title
```
Added value: +"scan_regulationsArguments"
```
Changed6 schema fields changedJul 13, 2026
- removedInput schema / properties / jurisdiction / title
```
Removed value: -"Jurisdiction"
```
- removedInput schema / properties / sector / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / sector / default
```
Removed value: -null
```
- removedInput schema / properties / sector / title
```
Removed value: -"Sector"
```
- addedInput schema / properties / sector / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"scan_regulationsArguments"
```
First observedJul 13, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does a good job: it discloses the return contents ('urgency flags and effective dates'), a rate limit (10 free calls/day), per-call price ($0.25), and three payment paths (x402/Base USDC, escrow-funded payment_ref, /seats). Missing: what happens on payment failure or whether the scan is cached/idempotent.

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?

Purpose and scope are front-loaded in the first two sentences, with the return shape summarized before pricing. The payment block is long but operationally necessary given the pay-per-call model; only request_id-related detail is missing rather than wasted.

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?

No output schema exists, yet the description states what is returned (regulations with urgency flags and effective dates), and it covers the payment/cost dimension that would otherwise block a caller. The gaps are request_id semantics and any guidance on choosing among the other regulatory-radar tools.

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% with 4 params, so the description must compensate. It explains jurisdiction with concrete examples and the CA-vs-california ambiguity, and ties payment_ref to the escrow funding flow, but leaves request_id and the sector value format entirely undocumented.

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?

States a specific verb+resource ('Scan a jurisdiction' returning regulations), and the CSRD/TNFD framing plus the 'scan vs assess vs monitor' distinction separates it informally from siblings like regulatory-radar__assess_compliance and monitor_changes. It never names a sibling, so it falls short of the top score.

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?

'optionally filtered by sector' and the jurisdiction examples (EU, US, california, CA for Canada) imply when to use it, and the disambiguation of CA vs california is genuinely useful. However, there is no explicit when-to-use/when-not guidance relative to assess_compliance or monitor_changes, so usage is only implied.

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

Deploy Server

regulatory-radar__scan_regulations

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools