Skip to main content
Glama
mark-brannan

colregs-mcp

Evaluate the circumstances

evaluate
Read-onlyIdempotent

Determines every lawful COLREGS navigation light display for a vessel's given circumstances, returning each option with per-light modality, paragraph citations and verbatim rule text.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
circumstancesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.5

TDQS

A3.8/5.0
Behavior5/5

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.

Conciseness2/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools