Click on "Install 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.
Preview, 0.0.x. Not for navigation. The tool surface will change without notice.
An MCP server that answers "what lights may this vessel show" from colregs-engine, and hands back the answer in a form a language model cannot quietly simplify: every lawful display, every light with its own modality, every entry with its paragraph cite, and the verbatim rule text those cites resolve to.
It has no semantics of its own. The engine decides; this package only decides how the answer is written down. That is the whole job, and the response shape section is the part worth reading.
Not on npm yet. Clone and build:
git clone https://github.com/mark-brannan/colregs-mcp && cd colregs-mcp && npm install && npm run buildThen register the stdio server with your client. Claude Code:
claude mcp add colregs -- node /absolute/path/to/colregs-mcp/dist/cli.jsAny other MCP client: command node, argument dist/cli.js, no
environment.
Related MCP server: US Regulations MCP Server
tool | input | returns |
|
| every lawful display, cited and with modality per light |
|
| the applicability entries that hold, as |
|
| verbatim paragraph text from colregs |
|
| a light's definition from colregs |
facts is a colregs fact record: the keys and values of colregs'
data/facts.json, namespaced (fact:propulsion, propulsion:sail). The
input schema is generated from that file at startup, so it follows the data.
A key or value outside the vocabulary is an error, never an empty answer.
Every tool description carries the coverage limits: COLREGS Part C lights only, international text only, lights at night only, pre-release data.
The same two vessels as colregs-engine's README.
{ "facts": { "fact:propulsion": "propulsion:sail", "fact:activity": "activity:none",
"fact:position": "position:underway", "fact:length_m": 11.6 } }Trimmed response:
{
"colregs": { "version": "0.2.0", "source": "resolved" },
"applied": [
{ "id": "25a", "cite": "25(a)", "modality": "shall" },
{ "id": "25b", "cite": "25(b)", "modality": "may" },
{ "id": "25c", "cite": "25(c)", "modality": "may" }
],
"exempted": [], "excluded": [],
"lawful_displays": {
"count": 3,
"relation": "any_one_of",
"options": [
{ "option": 1, "of": 3, "chosen": [],
"lights": [
{ "light": "light:sidelights", "name": "sidelights", "modality": "shall", "prescribed_by": { "id": "25a", "cite": "25(a)" } },
{ "light": "light:sternlight", "name": "sternlight", "modality": "shall", "prescribed_by": { "id": "25a", "cite": "25(a)" } } ] },
{ "option": 2, "of": 3, "chosen": [ { "id": "25b", "cite": "25(b)", "modality": "may" } ],
"lights": [
{ "light": "light:sidelights", "name": "sidelights", "combined": true, "position": "at or near the top of the mast", "modality": "may", "prescribed_by": { "id": "25b", "cite": "25(b)" } },
{ "light": "light:sternlight", "name": "sternlight", "combined": true, "position": "at or near the top of the mast", "modality": "may", "prescribed_by": { "id": "25b", "cite": "25(b)" } } ] },
{ "option": 3, "of": 3, "chosen": [ { "id": "25c", "cite": "25(c)", "modality": "may" } ],
"lights": [
{ "light": "light:sidelights", "name": "sidelights", "modality": "shall", "prescribed_by": { "id": "25a", "cite": "25(a)" } },
{ "light": "light:sternlight", "name": "sternlight", "modality": "shall", "prescribed_by": { "id": "25a", "cite": "25(a)" } },
{ "light": "light:all_round", "name": "all-round light", "color": "red", "count": 1, "position": "upper, at or near the top of the mast", "modality": "may", "prescribed_by": { "id": "25c", "cite": "25(c)" } },
{ "light": "light:all_round", "name": "all-round light", "color": "green", "count": 1, "position": "lower, at or near the top of the mast", "modality": "may", "prescribed_by": { "id": "25c", "cite": "25(c)" } } ] }
]
},
"optional_additions": { "relation": "any_subset_of", "items": [] },
"modality_key": { "shall": "mandatory", "may": "permitted alternative" },
"cited_paragraphs": {
"25(a)": "A sailing vessel underway shall exhibit: (i) sidelights; (ii) a sternlight.",
"25(b)": "In a sailing vessel of less than 20 meters in length the lights prescribed in Rule 25(a) may be combined in one lantern carried at or near the top of the mast where it can best be seen.",
"25(c)": "A sailing vessel underway may, in addition to the lights prescribed in Rule 25(a), exhibit at or near the top of the mast, where they can best be seen, two all-round lights in a vertical line, the upper being red and the lower green, but these lights shall not be exhibited in conjunction with the combined lantern permitted by Rule 25(b)."
}
}Three is the right number, and the response is built so that "a 12 m sloop
shows sidelights and a sternlight" cannot be read off it. The fact record
describes a situation, not a fitted vessel. There is no equipment fact in
colregs' data/facts.json (checked: nothing in that file names a lantern,
a fitting or a piece of gear), so nothing in the input can settle 25(b)
against 25(c). The Rules leave that to the skipper, and so does this.
{ "facts": { "fact:propulsion": "propulsion:power", "fact:activity": "activity:fishing",
"fact:position": "position:aground", "fact:length_m": 30 } }{
"applied": [
{ "id": "26c-id", "cite": "26(c)(i)", "modality": "shall" },
{ "id": "30d-anchor", "cite": "30(d)", "modality": "shall" },
{ "id": "30d-red", "cite": "30(d)", "modality": "shall-if-practicable" }
],
"excluded": [
{ "id": "30a", "cite": "30(a)", "by": { "id": "26c-id", "cite": "26(c)(i)" } },
{ "id": "30b", "cite": "30(b)", "by": { "id": "26c-id", "cite": "26(c)(i)" } }
],
"lawful_displays": {
"count": 1, "relation": "exactly_one",
"options": [ { "option": 1, "of": 1, "chosen": [], "lights": [
{ "light": "light:all_round", "color": "red", "count": 1, "position": "upper", "modality": "shall", "prescribed_by": { "id": "26c-id", "cite": "26(c)(i)" } },
{ "light": "light:all_round", "color": "white", "count": 1, "position": "lower", "modality": "shall", "prescribed_by": { "id": "26c-id", "cite": "26(c)(i)" } },
{ "light": "light:all_round", "color": "red", "count": 2, "arrangement": "vertical", "modality": "shall-if-practicable", "prescribed_by": { "id": "30d-red", "cite": "30(d)" } } ] } ]
},
"modality_key": { "shall": "mandatory", "shall-if-practicable": "mandatory where practicable, with a stated fallback" },
"cited_paragraphs": { "26(c)(i)": "…", "30(d)": "…", "30(a)": "…", "30(b)": "…" }
}Rule 26(a) says a fishing vessel shows only the lights of that Rule; the anchor lights of 30(a)/(b) are struck and the response says which entry struck them. The excluded paragraphs are still cited verbatim so the veto can be checked, not just believed.
Three properties, each tested in test/examples.test.ts:
Cited, verbatim. Every entry id travels with its paragraph cite, and
cited_paragraphs holds the text of every paragraph a response cites,
straight from colregs data/rules.json. This package writes no prose of
its own into a response; the only sentences in it are the Rules'.
Modality per light. shall, may, shall-if-practicable and the
rest are kept on each light, not summarised per display. Option 3 above
is two shall lights and two may lights, and it says so four times.
modality_key carries colregs' own one-line glossary for the modalities
the response uses.
Plural by construction. lawful_displays opens with count and
relation (exactly_one or any_one_of) before any lights appear; each
option numbers itself n of count and names the choice entries that
distinguish it; and there is no top-level lights field to mistake for
the answer. The tool description says why plural is correct, in the terms
above.
A vessel that lawfully shows nothing gets one empty display, not an error, matching the engine. An error is reserved for input outside the vocabulary.
Every response carries colregs.version and, on evaluate_display,
colregs.source, both straight from the engine. The server refuses to start
if its own copy of colregs and the engine's are different releases.
colregs-engine is pure, total and has no runtime dependencies, and formal-methods work is planned on top of it. A transport and a server SDK belong somewhere else. This is that somewhere.
colregs-engine is a git dependency on that repository's main branch,
because the engine is not yet published to npm. package-lock.json
records the commit an install resolved; npm update colregs-engine moves
it to the current tip. Breakage from an engine change is accepted at this
stage.
colregs is the published data package. The engine and this package
must resolve the same release; a split install fails at startup with a
message saying so.
Version 0.0.x. Tool names, argument names and response fields may all change. The three response properties above are the commitment; nothing else is.
Apache-2.0. Nothing here is advice to mariners; the fitness-for-navigation disclaimer in colregs carries over.
The colregs applicability entries whose conditions hold for a fact record, as {id, cite} pairs in data order, without composing displays. Use evaluate_display for the lights; this is the cheaper question "which paragraphs speak to this vessel". Same input as evaluate_display. 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 |
|---|---|---|---|
| facts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial non-obvious behavior: output ordering, verbatim provenance from the data package, coverage limitations, pre-release data status, and a stability warning that the surface may change without notice. This goes 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 description is dense but well organized: purpose first, then the key alternative, then scope limitations, then data-provenance and stability caveats. Every sentence adds necessary information, and the most decision-relevant content is front-loaded.
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?
Given the complex nested input and no output schema, the description is unusually complete: it specifies the output shape ({id, cite} pairs in data order), the exact coverage boundaries, the source data version, the preview instability, and the fact that entries are verbatim rather than paraphrased. Nothing essential for invoking the tool correctly is missing.
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 single top-level facts parameter has no inline description in this tool, and schema description coverage is 0%. However, the description says 'Same input as evaluate_display', linking the agent to the sibling schema, and frames the input as a fact record. The nested schema itself documents each fact property in detail, so an agent can construct valid input despite the top-level cross-reference.
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 verb and resource: it returns COLREGS applicability entries that hold for a fact record, as {id, cite} pairs in data order. It also clearly distinguishes itself from evaluate_display by framing this as the cheaper 'which paragraphs speak to this vessel' question, so an agent can tell the tools apart.
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 explicitly tells the agent when to use evaluate_display instead and what this tool is for: 'Use evaluate_display for the lights; this is the cheaper question'. It also gives hard exclusions via the coverage statement: no day shapes, no sound signals, no Part B steering rules, and not for navigation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every complete, lawful set of navigation lights one vessel may show, from a fact record (propulsion, activity, position, length, and the other facts in colregs data/facts.json) under the COLREGS. Returns the applied entries, the entries exempted or excluded and by which entry, 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. 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. 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 |
|---|---|---|---|
| facts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent; the description goes much further by explaining how multiple lawful displays are represented, that all options are equally correct, that 'shall' and 'may' lights are not merged, and that results are verbatim from a pre-release data package. No annotation contradiction.
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 long, but the tool is complex and nearly every sentence carries a distinct caveat or output detail. It is front-loaded with the purpose and returns, though the density of the prose makes it harder to scan than a bulleted structure would be.
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?
Given there is no output schema, the description thoroughly explains return fields, relation semantics, option numbering, optional additions, citations, coverage limits, and data stability. It lacks a concrete call example and does not discuss invalid/empty fact inputs, but is otherwise complete for typical 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?
With 0% schema description coverage, the description compensates by naming the core fact fields (propulsion, activity, position, length), referencing the facts data package, and adding the crucial semantic that the input describes a situation, not a fitted vessel, so equipment choices are not settled. Per-field value details are left to the input schema, which provides them.
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 explicitly states the tool evaluates every complete lawful set of navigation lights from a fact record under COLREGS, and enumerates the returned data (applied entries, exemptions, lawful_displays). This makes the tool's purpose unambiguous and distinguishes it from a generic rule-text or single-light tool.
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?
It gives clear when-to-use context (COLREGS Part C lights at night, from a fact record) and explicit exclusions (no day shapes, sound signals, or Part B rules). It does not name sibling tools or explicitly route to alternatives, which prevents a 5.
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_display returns, 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?
Beyond the readOnly/idempotent annotations, the description discloses that the content is verbatim from a pre-release data package, that nothing is paraphrased, that the surface is a 0.0.x preview subject to change, and that it is not for navigation. This is substantial behavioral context not available from annotations alone.
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 dense but front-loaded with the core purpose and output fields, followed by necessary caveats. A few caveats are repeated in spirit, but each sentence adds useful information for a tool with significant data-quality warnings.
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?
Despite having no output schema, the description enumerates the return fields, mentions the bearing convention for arcs, specifies coverage and exclusions, and warns about data maturity. For a single-parameter read-only tool, this is complete enough for an agent to call it correctly.
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% for the single 'id' parameter, so the baseline is 3. The description adds meaningful context by explaining that ids come from evaluate_display, giving concrete examples, and noting that the 'light:' prefix is optional.
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 one light's definition from the colregs data package, listing the exact fields included. It is distinct from sibling tools because it ties ids to evaluate_display, but it does not explicitly name or contrast the other sibling tools.
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 explicit scope and exclusions: COLREGS Part C lights only, international text only, lights at night only, and no day shapes/sound signals/Part B rules. It also clarifies the id provenance via evaluate_display, helping an agent decide when this tool is appropriate.
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. Dates show when Glama detected each change.
v0.0.1applied_entriesevaluate_displaylightrule_textThe tools are mostly distinct: rule_text retrieves paragraph text, light retrieves light definitions, and evaluate_display computes lawful displays. The main overlap is between applied_entries and evaluate_display, since both take the same input and both report applicable entries, but the descriptions clearly separate the cheaper applicability query from the full display evaluation.
The names are readable and domain-specific, but they do not follow a consistent pattern: evaluate_display is verb_noun, applied_entries and rule_text are noun phrases, and light is a bare noun. There is no strong predictable convention across the set.
Four tools is well-scoped for the server's narrow purpose of evaluating COLREGS Part C lights. Each tool has a distinct role in the workflow: evaluate displays, check applicable entries, look up rule text, and look up light definitions.
The core workflow is covered: a fact record can be evaluated, applicable entries identified, and supporting rule text and light definitions retrieved. Minor gaps exist, such as no tool to introspect the available fact schema or enumerate all rule cites and light ids, but these are workable from the response data.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Compliance lint for AI, scraping, and privacy law. Cited findings in 200 or more jurisdictions.
Resolve, search and verify legal citations against the official sources, with provenance.
AmpelOracle — 50-tool compliance traffic-light: Go/Caution/Stop signals for ESG, MiCA, AML.
Check if a dependency's license obligates you, based on how you ship. npm, PyPI, Go.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mark-brannan/colregs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
