Read-only marine equipment library: models, makers, categories, values with source labels.
Scored across 5 tools
Most tools target clearly different operations: get_equipment_model retrieves one model, while the two list tools expose facets and search_equipment_models performs targeted lookup. The main overlap is find_by_manufacturer versus search_equipment_models, since both return model lists and both accept category/ship_area filters; the descriptions cross-reference each other, which mitigates but does not eliminate the risk of misselection.
All names are snake_case and verb-first, generally following a predictable verb_noun pattern: get_equipment_model, list_categories, list_ship_areas, search_equipment_models. find_by_manufacturer is a minor stylistic deviation (verb_by_noun), though still clear and internally consistent with the set.
Five tools is well-scoped for a read-only equipment library: search, manufacturer browsing, detail retrieval, and two facet listings. Each tool covers a distinct access path, with no redundant or trivial tools.
The read-only lifecycle is well covered for identification: search, browse by manufacturer, retrieve details, and enumerate categories and ship areas. However, there is no list_manufacturers tool analogous to the other facet lists, and no direct way to browse all models by category or ship area without a manufacturer or search query; these are workaroundable but noticeable gaps.
List models of one manufacturer, best-documented first, at most 8 per call and no paging (total_matches shows the size). Narrow with category or ship_area, or use search_equipment_models with a designation to reach a specific model.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results; values above 8 are capped at 8. | |
| category | No | Category name from list_categories, e.g. 'Radar & ECDIS'. | |
| ship_area | No | Ship area slug from list_ship_areas: engine_room, deck, electrical, navigation, safety, cargo, hvac. | |
| manufacturer | Yes | Manufacturer name, e.g. 'Alfa Laval'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond the readOnly/idempotent/non-destructive annotations: a hard cap of 8 results per call, no paging, and total_matches as the escape hatch for result-set size. The cap partially duplicates the schema's limit description ('values above 8 are capped at 8'), which keeps it just short of a 5.
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?
Two sentences, front-loaded with the core action and ordering, then the narrowing options, then the fallback to a sibling. Nothing is redundant or padded.
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?
A read-only, four-parameter lookup with an output schema and full schema coverage needs the result cap, the no-paging constraint, and the sibling alternative — all present. Nothing an agent needs in order to call it 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?
Schema coverage is 100%, so manufacturer, category, ship_area and limit are already documented. The description adds only the framing that category and ship_area are narrowing filters, which is marginal value on top of an already self-documenting schema.
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?
States a specific verb and resource ('List models of one manufacturer') plus the ordering ('best-documented first'), which tells an agent exactly what comes back and in what order. It is immediately distinguishable from search_equipment_models, which is named as the alternative for designation-based lookup.
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?
Gives explicit selection logic: use this tool plus category/ship_area to narrow a manufacturer's catalog, or switch to search_equipment_models when the agent already has a designation and wants a specific model. The sibling routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one library model (model_ref from a search, or manufacturer + exact designation): category, ship area, page URL, manufacturer datasheet link if any, and the stored technical characteristics. Each value has source_document (label of the catalogue/datasheet it was extracted from; may cover a model series) and source_page. Values were extracted automatically and are not individually reviewed. If there are no stored values the response says so explicitly; never guess specifications in that case. OceanSphere does not hold stock.
| Name | Required | Description | Default |
|---|---|---|---|
| model_ref | No | model_ref returned by search_equipment_models or find_by_manufacturer. | |
| designation | No | Alternative to model_ref: exact model designation (together with manufacturer). | |
| manufacturer | No | Alternative to model_ref: manufacturer (together with designation). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds genuinely new behavioral facts: values are auto-extracted and not individually reviewed, source_document may describe a whole model series rather than the single model, an empty result is signalled explicitly, and OceanSphere holds no stock. Those caveats materially change how an agent should present and trust the returned data, which annotations alone could not 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?
Front-loaded with the action and the returned fields, then the data-provenance caveats; no sentence is filler. The field enumeration overlaps slightly with the existing output schema, and the closing 'does not hold stock' line is a domain caveat rather than core invocation guidance, but both are short and useful.
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 zero-required-parameter read tool with a full output schema, the description supplies exactly the parts structured data cannot: how to identify the model, the reliability of extracted values, the series-level scope of source labels, empty-result behavior, and the stock caveat. Nothing an agent needs to call it correctly or interpret the response 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 description coverage is 100% and every parameter already documents its role, including the model_ref/designation alternation, so the baseline is 3. The description reinforces the 'exact designation' requirement and the pairing with manufacturer, but adds no syntax, format, or precedence detail beyond what the schema states (e.g. what happens if both model_ref and designation are supplied).
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 opens with a specific verb and resource ('Get one library model') and immediately names the two accepted identity modes ('model_ref from a search, or manufacturer + exact designation'). It then enumerates the returned fields (category, ship area, page URL, datasheet link, technical characteristics), which is enough for an agent to distinguish this single-record lookup from the search/list siblings without opening a schema.
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 tells the agent how to reach this tool (take a model_ref from a search, or supply manufacturer + exact designation) and adds a hard rule for the empty case: 'never guess specifications in that case.' What is missing is an explicit negative case naming when to prefer search_equipment_models or find_by_manufacturer instead, though the 'from a search' phrasing implies the sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the equipment categories with model counts, optionally for one ship_area. Use the names as category filter.
| Name | Required | Description | Default |
|---|---|---|---|
| ship_area | No | Ship area slug from list_ship_areas: engine_room, deck, electrical, navigation, safety, cargo, hvac. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context that results carry model counts, but says nothing about ordering, pagination, or behavior when ship_area matches no categories.
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?
Two short sentences, front-loaded with the core action and with no redundant restatement of the name or title. The closing sentence is terse to the point of being slightly cryptic, but it is not wasted space.
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?
An output schema exists, so return values need not be explained, and the single optional parameter is fully described in the schema. For a one-parameter read tool this is essentially complete, with only minor gaps around result ordering and empty-result behavior.
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% and the ship_area parameter already documents the full slug list and its default of null. The description only reinforces that the parameter is optional and singular ("one ship_area"), adding little beyond the schema; baseline 3 applies.
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 opens with a specific verb and resource ("List the equipment categories") and adds scope detail ("with model counts, optionally for one ship_area"). It is clearly distinct from get_equipment_model or search_equipment_models, though it never names those siblings explicitly.
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?
"Optionally for one ship_area" implies the filtering case, and "Use the names as category filter" tells the agent what to do with the output. However, there is no explicit when-to-use vs. when-not guidance and no named alternative among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ship areas of the library (engine room, deck, electrical, navigation, safety, cargo, HVAC) with model counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds that the area set is a fixed enumeration and that results carry model counts, but says nothing about ordering or whether empty areas appear.
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, front-loaded with the verb and resource, with the area list parenthetically bounded rather than sprawled across clauses. Nothing is wasted or repeated from the schema.
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 inputs, a full annotation set, and an output schema covering the return shape, the description carries all the burden it needs to. The only shortfall is the lack of any routing hint relative to the sibling list and search tools.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of 'model counts' is the only semantic addition and it concerns output rather than input.
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?
States a specific verb and resource ('List the ship areas of the library') and enumerates the exact area taxonomy, so the agent knows precisely what comes back. It does not differentiate from the similarly-shaped sibling list_categories, which an agent could easily confuse it with.
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?
Usage is only implied: a zero-parameter browse tool whose purpose makes it obviously a discovery/overview call. There is no explicit statement of when to call this versus list_categories or search_equipment_models, and no follow-up routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the OceanSphere equipment library (marine engines, auxiliaries, pumps, deck machinery, navigation and electrical equipment) by model designation, equipment type or keywords; optionally filter by manufacturer, ship_area or category. Returns at most 8 models (no paging) with manufacturer, designation, category, ship area, the number of source-referenced characteristics, a model_ref and the library page URL. Models without stored values are flagged 'no stored values'. Results with stored values come first. The library identifies equipment; it is not a parts shop - OceanSphere does not list stock. Use model_ref with get_equipment_model.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results; values above 8 are capped at 8. | |
| query | Yes | Model designation, equipment type or keywords, e.g. 'S50ME-C' or 'fuel injection pump'. | |
| category | No | Category name from list_categories, e.g. 'Radar & ECDIS'. | |
| ship_area | No | Ship area slug from list_ship_areas: engine_room, deck, electrical, navigation, safety, cargo, hvac. | |
| manufacturer | No | Optional manufacturer filter, e.g. 'MAN Energy Solutions'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, it discloses ranking ('results with stored values come first'), a data-quality flag ('no stored values'), and the hard result cap that overrides the schema's nominal limit — all behavior an agent cannot infer from structured fields. It also describes the returned record shape, which goes well past what the annotations declare.
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?
It is front-loaded with the search scope, then filters, then result shape and cap, then the follow-up tool — a logical order with no filler sentences. Dense parenthetical lists are used efficiently rather than restating the name or title.
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 5-parameter filtered search with full schema coverage and an output schema, the description covers scope, ranking, caps and the next-step tool, so an agent can call it correctly. The only gap is that it never states how the query is matched (substring vs exact designation) or what happens on zero results, which matters for a search 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 already documents query, limit, category, ship_area and manufacturer with examples and enum-like slugs. The description confirms which filter dimensions exist and reinforces the 8-result cap, but adds no new syntax, matching semantics or format detail beyond the schema, so the baseline 3 applies.
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 opens with a specific verb and resource ('Search the OceanSphere equipment library') and enumerates the covered equipment domains, the searchable fields (model designation, equipment type, keywords) and the optional filters. It also draws a clear boundary ('it is not a parts shop - OceanSphere does not list stock') that separates this tool from any parts/stock sibling.
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 concrete usage context: result cap of 8 with no paging, and an explicit handoff ('Use model_ref with get_equipment_model'), which routes the agent along the correct follow-up path. It does not explicitly contrast against find_by_manufacturer or say when manufacturer-only lookup is preferable, so it falls short of full when/when-not guidance.
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.
find_by_manufacturerget_equipment_modellist_categorieslist_ship_areassearch_equipment_modelsRead-only sourced engineering materials data: every value with unit, conditions and source.
Read-only cannabis compound, receptor, anatomy and evidence data, every value sourced.
Read-only firearm specifications: calibers, ammunition, manufacturers and attachment fitment.
Live AIS ship positions, vessel history, port calls and events, plus sanctions flags. Read-only.
Add one secure layer between your agents and this server.
