This server answers COLREGS questions through three read-only MCP tools, returning cited, verbatim rule-backed results.
Evaluate a vessel’s circumstances (self, others, conditions) to get lawful light displays, signal details, appraisal readings, and indications from observed lights, shapes, or sounds.
Inspect applied, exempted, and overridden signals plus lawful_displays options and optional additions, with paragraph cites and verbatim cited_paragraphs.
Retrieve exact COLREGS paragraph text by cite such as 25(b), bare rule 25, or range 24(a)(ii)-(iv), including source and retrieval date.
Look up a light id such as light:sidelights or masthead for its Rule 21 definition: colour, character, arc, and placement.
Use it only for COLREGS Part C lighting at night under international high-seas text; no day shapes, sound signals, Part B steering rules, or compliance over time yet.
Treat output as non-navigational preview data; the server is read-only and makes no network requests of its own.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@colregs-mcp What lights must a 12-meter sailboat under way show?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Not for navigation. This is a preview (0.0.x) built on pre-release rule data. Do not use its output to decide what to do on the water. The tool surface will change without notice.
An MCP server that answers questions under the COLREGS. Every answer carries its paragraph cites and the verbatim rule text those cites resolve to, so a language model cannot quietly simplify it. The rules are evaluated by colregs-engine; this package only decides how the answer is written down.
Claude Code:
claude mcp add colregs -- npx -y colregs-mcpClaude connector directory: in Claude, open Settings → Connectors,
search for COLREGS and click Connect. No configuration is needed.
Any other MCP client: command npx, arguments -y colregs-mcp, no
environment.
From a clone:
git clone https://github.com/mark-brannan/colregs-mcp && cd colregs-mcp && npm install && npm run buildthen command node, argument /absolute/path/to/colregs-mcp/dist/cli.js.
Related MCP server: Claude Patent Creator MCP Server
tool | input | returns |
|
| one evaluation: |
|
| the verbatim text of a COLREGS paragraph |
|
| one light's definition: colour, character, arc, placement |
circumstances is the whole picture one vessel is in: self (her own
facts), others (each other vessel, with what is known or observed of
her) and conditions (visibility, environment). One call evaluates the
picture; the response carries four readings of it.
signals: every complete, lawful set of lights self may show. Each
light carries its modality (shall, may, shall-if-practicable) and
the paragraph that prescribes it.
appraisal: what the Rules require of self on her own, and then
against each other vessel: the kind of encounter, whether risk of
collision is asserted, and each vessel's role (stand-on, give-way,
shall-not-impede).
indicated: for each other vessel, what her observed lights, shapes
and sounds indicate she could be.
compliance: over a track of circumstances sampled through time, one
verdict per vessel per obligation that attached: kept, breached or
pending.
Every id travels with its paragraph cite, and cited_paragraphs holds the
verbatim text of every paragraph the response cites. The input vocabulary
is generated from the colregs data package at startup. A key or value
outside it is an error, never an empty answer.
Takes a paragraph path such as 25(b) or 26(c)(i), a bare rule number
such as 25 for every paragraph of that rule, or a range such as
24(a)(ii)-(iv). Returns the International text as transcribed from the
USCG amalgamated Navigation Rules, with its source and retrieval date.
Takes a light id as it appears in a response, such as light:sidelights
or light:all_round. Returns the Rule 21 definition: colour, character,
arc in degrees and placement.
A 12 m sloop under way, alone.
{
"circumstances": {
"self": {
"fact:propulsion": "propulsion:sail",
"fact:activity": "activity:none",
"fact:position": "position:underway",
"fact:length_m": 11.6
}
}
}Trimmed response:
{
"colregs": { "version": "0.3.4" },
"signals": {
"applied": [
{ "id": "rule:25a", "cite": "25(a)", "modality": "modality:shall" },
{ "id": "rule:25b", "cite": "25(b)", "modality": "modality:may" },
{ "id": "rule:25c", "cite": "25(c)", "modality": "modality:may" }
],
"lawful_displays": {
"count": 3,
"relation": "any_one_of",
"options": [
{
"option": 1,
"of": 3,
"lights": [
{
"light": "light:sidelights",
"modality": "modality:shall",
"prescribed_by": { "id": "rule:25a", "cite": "25(a)" }
},
{
"light": "light:sternlight",
"modality": "modality:shall",
"prescribed_by": { "id": "rule:25a", "cite": "25(a)" }
}
]
},
{ "option": 2, "of": 3, "...": "..." },
{ "option": 3, "of": 3, "...": "..." }
]
},
"modality_key": { "modality:shall": "mandatory", "modality:may": "permitted alternative" },
"cited_paragraphs": {
"25(a)": "A sailing vessel underway shall exhibit: (i) sidelights; (ii) a sternlight.",
"25(b)": "…",
"25(c)": "…"
}
},
"appraisal": { "self": { "...": "..." }, "others": [] },
"indicated": []
}The sloop has three lawful displays, because the Rules give her the choice and nothing in the input settles it.
docs/demo.md puts the same question to the same model with and without this server and shows both answers as captured.
Three properties hold for every response:
Cited, verbatim. Every entry id travels with its paragraph cite, and
cited_paragraphs holds the text of every paragraph cited. The only
sentences in a response are the Rules' own.
Modality per light. shall, may and shall-if-practicable are
kept on each light, not summarised per display. modality_key is a
one-line glossary of the modalities the response uses.
Plural by construction. lawful_displays opens with count and
relation before any lights appear, and each option numbers itself
n of count. There is no top-level lights field to mistake for the
answer.
A vessel that lawfully shows nothing gets one empty display, not an error. An error is reserved for input outside the vocabulary.
Every response carries colregs.version. The server refuses to start if its
own copy of colregs and the engine's are different releases.
colregs-engine and colregs are installed from GitHub main, not from
npm releases; the lockfile pins the commit. Both must resolve the same
release.
The server collects nothing. It runs as a local stdio process, answers from
the colregs data package installed beside it, and makes no network request
of its own. There is no telemetry, no logging of what it is asked, and no
account. The only network transaction is the install itself, which is npm's.
Automatic from the release tag: npm, the MCP registry, and a .mcpb bundle
on the GitHub Release. The remaining by-hand steps are in
docs/releasing.md.
AGPL-3.0-only. The fitness-for-navigation disclaimer in colregs carries over.
One evaluation of the circumstances one vessel is in, under the COLREGS, with three readings. signals: every complete, lawful set of navigation lights self may show, from her fact record (propulsion, activity, position, length, and the other facts in colregs data/facts.json): the applied entries; exempted (relieved by a rel:exempts entry) and overridden (displaced by a superior obligation's rel:overrides) entries, each with the entry that did it; and lawful_displays: {count, relation, options}. relation is "none", "exactly_one" or "any_one_of". A fact record describes a situation, not a fitted vessel: colregs data/facts.json has no equipment fact, so nothing in the input can settle a choice the Rules leave to how the vessel is fitted or what the skipper elects, such as Rule 25(b), the combined masthead lantern a sailing vessel under 20 m may carry, against Rule 25(c), the all-round red over green she may add. When lawful_displays.count is greater than 1, every option is equally lawful, the correct report is all of them, and reporting any one as "the" display for this vessel is wrong. Displays are listed in the order to consider the rules in, most specific concession first, and the first is the one a vessel of that description usually shows. Each option numbers itself "n of count", names the choice entries that distinguish it (chosen) and lists its lights with their own modality, so "shall" and "may" lights in one display are never merged. optional_additions are lawful extras (relation any_subset_of) that do not multiply the display set. Every id carries its paragraph cite, and cited_paragraphs holds the verbatim text of every cited paragraph. appraisal: what Part B requires of self on her own, then against each other vessel (kind of encounter, risk of collision, each vessel's role). indicated: per other vessel, what her observed lights, shapes and sounds say she could be. appraisal and indicated are passed through from colregs-engine as returned, without the cite resolution signals has. Compliance over time is not read yet. Not for navigation. Coverage: COLREGS Part C lights only, international (high seas) text only, lights at night only (no day shapes, no sound signals, no Part B steering rules), evaluated against pre-release colregs data (0.x), whose content is still being checked. Every entry id and paragraph cite in a response is verbatim from the colregs data package; nothing is paraphrased. This tool surface is a 0.0.x preview and will change without notice.
| Name | Required | Description | Default |
|---|---|---|---|
| circumstances | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses many behavioral details beyond the annotations: lawful_displays ambiguity, ordering of displays, optional additions, pass-through behavior for appraisal and indicated, cite resolution, and pre-release coverage limits. The read-only annotations are consistent with an evaluation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the description is a very long, dense block with run-on sentences and extensive rule-specific examples. It contains useful material, yet it is not structured for quick agent consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return behavior, and it does: signals, lawful_displays, optional_additions, appraisal, indicated, cites, and coverage limitations. It also warns that the surface is a preview, making the definition sufficiently complete for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds important conceptual input semantics, especially that the fact record describes a situation rather than a fitted vessel and cannot settle choices left to equipment or skipper election. However, with schema_description_coverage reported at 0%, it does not fully compensate by documenting the nested input fields themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: evaluate one vessel's COLREGS circumstances and return three readings (signals, appraisal, indicated). It is distinct from a pure light lookup or rule-text lookup, though it does not explicitly name the sibling tools or contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives important exclusions and coverage limits ('Compliance over time is not read yet', 'Not for navigation', Part C lights only), but it does not explicitly say when to choose this tool over light or rule_text. Usage is implied by the three-reading scope rather than directly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The definition of one light from colregs data/lights.json, verbatim: name, the Rule 21 paragraph that defines it, colour, character, arc in degrees and placement. Ids are the light ids that evaluate returns in signals, such as "light:sidelights" or "light:all_round"; the "light:" prefix is optional. Arcs use the bearing convention returned alongside. Not for navigation. Coverage: COLREGS Part C lights only, international (high seas) text only, lights at night only (no day shapes, no sound signals, no Part B steering rules), evaluated against pre-release colregs data (0.x), whose content is still being checked. Every entry id and paragraph cite in a response is verbatim from the colregs data package; nothing is paraphrased. This tool surface is a 0.0.x preview and will change without notice.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Light id, e.g. "light:masthead" or "masthead". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent hints already covering the safety profile, the description adds real context: the data is a pre-release 0.x package whose content is still being checked, entries and paragraph cites are verbatim, and the tool surface is a 0.0.x preview subject to change. It does not state what happens on an unknown id, but the provenance and stability disclosure is well beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core definition is front-loaded and the coverage limits are useful, but the text repeats itself: verbatim is asserted twice and the pre-release/0.x caveat appears in two separate places. Tightening would remove redundancy without losing any constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup with no output schema, the description supplies the return shape, the id format, and the data-coverage boundaries, which is close to sufficient. The main gap is error behavior for an invalid or unknown light id, which the agent cannot infer from either the schema or the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds two facts the schema lacks: the "light:" prefix is optional, and arcs follow the bearing convention returned alongside the id. Those directly affect how the agent constructs and interprets the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb+resource: returns the definition of one light from colregs data, and enumerates exactly which fields come back (name, Rule 21 paragraph, colour, character, arc, placement). It partly separates itself from siblings by scoping out Part B steering rules and saying it is not for navigation, though it never names rule_text or evaluate directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The negative scope ("Not for navigation", no day shapes, no sound signals, no Part B steering rules) implies that rule_text or evaluate cover those cases, and the id example hints that evaluate consumes these ids. But there is no explicit statement of when to call this versus the two siblings, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The verbatim text of a COLREGS paragraph from colregs data/rules.json, by its cite as used in every other response here: a paragraph path such as "25(b)" or "26(c)(i)", a bare rule number such as "25" for every paragraph of that rule, or a range such as "24(a)(ii)-(iv)". The text is the International text as transcribed from the USCG amalgamated Navigation Rules; the response names the source and retrieval date. Not for navigation. Coverage: COLREGS Part C lights only, international (high seas) text only, lights at night only (no day shapes, no sound signals, no Part B steering rules), evaluated against pre-release colregs data (0.x), whose content is still being checked. Every entry id and paragraph cite in a response is verbatim from the colregs data package; nothing is paraphrased. This tool surface is a 0.0.x preview and will change without notice.
| Name | Required | Description | Default |
|---|---|---|---|
| cite | Yes | Paragraph path, rule number or range, e.g. "25(b)", "25", "24(a)(ii)-(iv)". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only and idempotent behavior, but the description adds substantial behavioral context: the source file, retrieval date, no-paraphrasing guarantee, pre-release data quality, and version instability. This goes well beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by cite syntax and then important limitations. It is longer than strictly necessary for a one-parameter tool, but every sentence contributes useful safety or provenance information, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description is complete: it defines the parameter format, scope, source, caveats, and versioning behavior. Even without an output schema, it explains what the response contains (verbatim text plus source and retrieval date).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage for the 'cite' parameter with examples, so the baseline is 3. The description adds meaningful extras: bare rule numbers return every paragraph of that rule, ranges are accepted, and cites follow the exact format used elsewhere in the system. This strengthens the parameter semantics beyond the schema's short example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the verbatim text of a COLREGS paragraph from a specific data source, addressed by cite. The verb 'retrieve' is implied through 'the verbatim text ... by its cite,' and the detailed cite syntax distinguishes it from sibling tools like light or evaluate_display.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context for when to use the tool: whenever verbatim paragraph text is needed by a COLREGS cite, and it explicitly lists coverage exclusions (no day shapes, no sound signals, no Part B rules). It does not explicitly name alternative tools or say 'use X instead,' but the scope and limitations are clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.5applied_conduct_entriesapplied_encounter_entriesapplied_entriesevaluateevaluate_circumstancesevaluate_complianceevaluate_displayevaluate_rule2_departurev0.0.3evaluate_circumstancesevaluate_complianceevaluate_conductevaluate_encounterv0.0.2applied_conduct_entriesapplied_encounter_entriesapplied_entries8 fields changedInput schema / properties / facts / properties / fact:full_display_impracticableAdded value: +{
+ "description": "Cite 27(e). 27(e)'s gate: the diving vessel's size makes it impracticable to exhibit all the lights and shapes of 27(d). The Convention leaves that judgement to the vessel and no source reduces it to a length (IMO text and Annex I, 33 CFR 83.27, the UK, Canadian and NZ variants, Cockcroft & Lameijer), so this package asks rather than inventing a threshold, as for 'very large vessel' (Q-42). Absent reads as false: the full 27(d) display.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:mannedAdded value: +{
+ "description": "Cite 35(e). 35(e)'s condition on the towed vessel's own signal: the last vessel of a tow sounds it only if she is manned.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:motorsailingAdded value: +{
+ "description": "Refines fact:propulsion=propulsion:power. Proceeding under sail when also being propelled by machinery. Rule 3(c) makes her a power-driven vessel, so the lights are Rule 23's; 25(e)'s cone is the only signal that reads this.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:nearing_obscured_bendAdded value: +{
+ "description": "Cite 34(e). Nearing a bend, or an area of a channel or fairway where other vessels may be obscured by an intervening obstruction. A place fact in the family of `fact:near_channel`, read of one vessel and set by the helm from the chart.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:on_mooring_buoyAdded value: +{
+ "description": "Refines fact:position=position:moored. Made fast to a mooring buoy rather than to the shore. Rule 3(i) makes both 'moored', and the Convention prescribes no lights for either. Only a jurisdiction that deems a buoy-moored vessel to be at anchor reads it -- US Inland, 33 CFR 90.5 -- so under intl it selects nothing.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:partly_submergedAdded value: +{
+ "description": "Cite 24(g). The vessel or object being towed is inconspicuous and partly submerged, or a combination of such vessels or objects. True selects 24(g) in place of 24(e); absent leaves her on 24(e).",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:seaplaneAdded value: +{
+ "description": "Cite 3(e). The vessel is a seaplane, an aircraft designed to manoeuvre on the water; her lights are the power-driven vessel's, and Rule 31 is what reads this.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:tow_display_impracticableAdded value: +{
+ "description": "Cite 24(h). From any sufficient cause it is impracticable for the vessel or object being towed to exhibit the 24(e) or 24(g) lights or shapes. The Convention leaves the cause to the vessel, so this package asks rather than deriving it, as for fact:full_display_impracticable.",
+ "type": "boolean"
+}evaluate_conductevaluate_display8 fields changedInput schema / properties / facts / properties / fact:full_display_impracticableAdded value: +{
+ "description": "Cite 27(e). 27(e)'s gate: the diving vessel's size makes it impracticable to exhibit all the lights and shapes of 27(d). The Convention leaves that judgement to the vessel and no source reduces it to a length (IMO text and Annex I, 33 CFR 83.27, the UK, Canadian and NZ variants, Cockcroft & Lameijer), so this package asks rather than inventing a threshold, as for 'very large vessel' (Q-42). Absent reads as false: the full 27(d) display.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:mannedAdded value: +{
+ "description": "Cite 35(e). 35(e)'s condition on the towed vessel's own signal: the last vessel of a tow sounds it only if she is manned.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:motorsailingAdded value: +{
+ "description": "Refines fact:propulsion=propulsion:power. Proceeding under sail when also being propelled by machinery. Rule 3(c) makes her a power-driven vessel, so the lights are Rule 23's; 25(e)'s cone is the only signal that reads this.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:nearing_obscured_bendAdded value: +{
+ "description": "Cite 34(e). Nearing a bend, or an area of a channel or fairway where other vessels may be obscured by an intervening obstruction. A place fact in the family of `fact:near_channel`, read of one vessel and set by the helm from the chart.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:on_mooring_buoyAdded value: +{
+ "description": "Refines fact:position=position:moored. Made fast to a mooring buoy rather than to the shore. Rule 3(i) makes both 'moored', and the Convention prescribes no lights for either. Only a jurisdiction that deems a buoy-moored vessel to be at anchor reads it -- US Inland, 33 CFR 90.5 -- so under intl it selects nothing.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:partly_submergedAdded value: +{
+ "description": "Cite 24(g). The vessel or object being towed is inconspicuous and partly submerged, or a combination of such vessels or objects. True selects 24(g) in place of 24(e); absent leaves her on 24(e).",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:seaplaneAdded value: +{
+ "description": "Cite 3(e). The vessel is a seaplane, an aircraft designed to manoeuvre on the water; her lights are the power-driven vessel's, and Rule 31 is what reads this.",
+ "type": "boolean"
+}Input schema / properties / facts / properties / fact:tow_display_impracticableAdded value: +{
+ "description": "Cite 24(h). From any sufficient cause it is impracticable for the vessel or object being towed to exhibit the 24(e) or 24(g) lights or shapes. The Convention leaves the cause to the vessel, so this package asks rather than deriving it, as for fact:full_display_impracticable.",
+ "type": "boolean"
+}evaluate_encounterevaluate_rule2_departurev0.0.1applied_entriesevaluate_displaylightrule_textScored across 3 tools
The three tools have clearly distinct roles: evaluate runs the COLREGS assessment engine, light returns a single light definition by id, and rule_text returns verbatim rule text by cite. Although evaluate's output references light ids and paragraph cites, there is no functional overlap with the two lookup tools.
The names are readable and all lowercase/snake_case, but they do not follow a single convention: evaluate is a verb while light and rule_text are noun-style lookup names. The mixed convention is minor given only three tools, but it is not a predictable verb_noun pattern.
Three tools is slightly thin but reasonable for a narrowly scoped COLREGS lights evaluator. Each tool serves a distinct purpose: assessment, light-definition lookup, and rule-text retrieval.
The core workflow is covered: evaluate a fact record, look up any light returned, and retrieve cited rule paragraphs. Minor gaps remain, such as no enumeration of all lights or rules and explicitly no compliance-over-time reading, but these are not fatal for the stated preview scope.
Resolve, search and verify legal citations against the official sources, with provenance.
Classify any AI system under the EU AI Act: risk tier + binding Articles, verbatim from the law.
Declare what your app does and where it operates; get cited, jurisdiction-specific findings.
AmpelOracle — 50-tool compliance traffic-light: Go/Caution/Stop signals for ESG, MiCA, AML.
