Ukrainian vessel registry: search by number/name/owner, full records, stats. No API key required.
Scored across 4 tools
The tools are mostly distinct: lookup_vessel is exact registration-number lookup, search_vessel_registries is free-text/filter search, and get_registry_stats handles aggregate count questions. There is slight overlap between get_dataset_metadata and get_registry_stats since both mention counts, but their primary purposes remain distinguishable.
All tool names use a consistent snake_case verb_noun pattern: get_dataset_metadata, get_registry_stats, lookup_vessel, search_vessel_registries. The verbs (get, lookup, search) clearly describe the action, and the nouns identify the target resource, making the naming predictable and easy to navigate.
With only 4 tools, the surface is tightly scoped to the server's purpose of inspecting Ukrainian vessel registries. Each tool covers a distinct need—discovery, stats, exact lookup, and search—without unnecessary duplication or bloat.
The tool set appears complete for its stated domain: metadata describes the data sources, stats answers aggregate questions, lookup_vessel handles exact registration numbers, and search_vessel_registries supports exploratory queries with filters. There are no obvious dead ends for common registry lookups or research tasks.
Describes available data sources (Державний судновий реєстр / Суднова книга), freshness (import dates), record counts, and available fields.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| api | Yes | |
| fields | Yes | |
| data_sources | Yes | |
| example_queries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context about freshness, record counts, and fields, which goes beyond the annotations, but it does not disclose return structure or any additional behavior such as filtering or default limits.
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 one dense sentence that front-loads the purpose and lists the key metadata dimensions without repetition or filler. Every phrase earns its place.
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, parameterless metadata tool with a read-only annotation set and an output schema present, the description is complete. It tells the agent what kind of information will be available (sources, freshness, counts, fields), which is all that is needed to select and invoke the tool 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?
The tool has zero parameters, so parameter documentation is not needed. The schema coverage is effectively 100%, and the description's mention of data sources and fields naturally frames what the returned metadata covers, which is sufficient for a parameterless call.
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 uses a specific verb ('Describes') tied to a clear resource (available vessel-registry datasets) and enumerates the content: data sources, freshness, record counts, and fields. This clearly differentiates it from the sibling tools: get_registry_stats, lookup_vessel, and search_vessel_registries.
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 intended use is implied: agents should call this when they need an overview of available datasets rather than individual vessel lookups or registry statistics. However, the description does not explicitly state when to prefer this tool over siblings or mention any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate public vessel counts for answering "how many vessels" questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sources | Yes | |
| total_vessels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'public' scope and aggregate nature, which is useful but minimal. No contradiction exists, and with annotations carrying the behavioral burden, a 3 is appropriate.
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?
One sentence, no filler, and the core purpose is front-loaded. Every word contributes to clarifying the tool's function.
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?
With no parameters, rich annotations (readOnly, idempotent, non-destructive), and an output schema present, the single-sentence description covers all necessary context. Nothing essential is missing for an agent to invoke this tool 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?
The tool has zero parameters, so the input schema is empty. With 0 params, the baseline is 4, and the description doesn't need to add parameter-specific semantics. It correctly omits any parameter discussion.
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 ('Aggregate'), a clear resource ('public vessel counts'), and the exact question type it answers ('how many vessels'). This cleanly distinguishes it from sibling tools like lookup_vessel or search_vessel_registries, which operate at the individual-vessel level.
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 phrase 'for answering "how many vessels" questions' provides clear context for when to use this tool. It does not explicitly name alternatives or state exclusions, but the use case is specific enough that an agent can infer when this is the right choice versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a vessel in the Ukrainian vessel registries using its registration number. Handles -, ., and space variance and Latin/Cyrillic forms. Returns the full public registry record, including a web_url pointing to the public vessel information page.
| Name | Required | Description | Default |
|---|---|---|---|
| registration_number | Yes | Registration number, for example УПС-0129. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| match | Yes | |
| source | Yes | |
| tonnage | Yes | |
| web_url | Yes | |
| home_port | Yes | |
| build_year | Yes | |
| owner_name | Yes | |
| source_name | Yes | |
| vessel_type | Yes | |
| owner_address | Yes | |
| registration_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the lowering bar is met. The description adds useful behavioral context beyond annotations: it normalizes separators and Latin/Cyrillic variants, and it reveals the return includes a web_url to the public page.
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 compact and front-loaded: purpose first, then normalization behavior, then return value. Every sentence earns its place with no redundant filler.
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 single parameter, rich annotations, and presence of an output schema, the description is nearly complete. It could mention not-found behavior, but that gap is minor for such a simple lookup tool.
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 description coverage is 100% and the parameter already has an example. The description does not add parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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: look up a vessel in Ukrainian vessel registries by registration number. It also distinguishes itself from search_vessel_registries by specifying exact-number lookup rather than searching.
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 clearly implies this tool is for when the caller already has a registration number, but it does not explicitly mention alternatives or exclusion conditions. The sibling list suggests search_vessel_registries for broader search, but no direct when-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public data from the Ukrainian State Ship Registry and Ship Book by free-text query and structured filters. Deterministic ordering with exact registration-number matches first. Handles Cyrillic and Latin scripts and separator-insensitive numbers (УПС-0129 ≡ УПС 0129 ≡ UPS-0129). Each result includes a web_url pointing to the public vessel information page.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Registration number, vessel name, or owner name. Accepts Latin or Cyrillic. | |
| limit | No | Page size. | |
| offset | No | Pagination offset. | |
| source | No | Dataset to search. | |
| home_port | No | Partial match on home port. | |
| vessel_type | No | Partial match on vessel type (e.g. земснаряд). | |
| build_year_max | No | Inclusive maximum build year. | |
| build_year_min | No | Inclusive minimum build year. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals deterministic ordering ('exact registration-number matches first'), normalization rules (Cyrillic/Latin, separator-insensitive numbers), and a per-result web_url field—none of which appear in annotations. It aligns with readOnlyHint/idempotentHint and adds genuinely useful behavior beyond the structured fields.
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?
Three sentences, each with a distinct role: purpose/scope, ordering, normalization + output shape. No filler; the most decision-relevant information 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?
For an 8-parameter optional-query tool with a rich output schema, the description covers search semantics, ordering, normalization, and output URL without duplicating the schema. Pagination and defaults are already in the input schema, so nothing critical 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?
Schema already documents all 8 parameters (100% coverage), so baseline is 3. The description goes beyond by defining q normalization equivalence (УПС-0129 ≡ УПС 0129 ≡ UPS-0129) and 'partial match' filtering intent, which helps the agent use q and filters correctly.
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?
Description opens with a specific verb ('Search'), names the exact resources ('Ukrainian State Ship Registry and Ship Book'), and states the mechanism ('free-text query and structured filters'). This differentiates it from sibling lookup_vessel by emphasizing free-text search rather than a single exact identifier.
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 implies the search use case but never tells the agent when to prefer this tool over lookup_vessel or get_registry_stats. It names no alternatives, no exclusions, and no prerequisites, so an agent must infer routing from the tool name and sibling list.
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.
get_dataset_metadataget_registry_statslookup_vesselsearch_vessel_registriesVessel tracking for 750,000+ ships, with ownership, inspections, port records, routes, and more.
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
Global customs trade data and company registry. Search shipments, and look up legal entities.
Add one secure layer between your agents and this server.
