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., "@mcp-yacht-specs get specs for a Lagoon 46 and compute its hydrodynamic coefficients"
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.
@nareyko/mcp-yacht-specsZero-Network MCP server for FairHelm yacht passport specs and hydrodynamic coefficients.
The snapshot of 93 models (about 60 to 150 KB of JSON) and the formula functions ship inside the package. Tool calls run locally. There is no HTTP call to api.fairhelm.com, no Postgres, no Railway load.
This is not a CapEx scanner or BoatAdDecoder. It does not read listings. For year-1 CapEx planning use CapEx scanner on fairhelm.com.
Link | URL |
Homepage (formulas) | |
Open data / OpenAPI | |
Benchmark DOI | |
npm | |
Listing review (€49) |
npx -y @nareyko/mcp-yacht-specsClaude Desktop / Cursor:
{
"mcpServers": {
"fairhelm-yacht-specs": {
"command": "npx",
"args": ["-y", "@nareyko/mcp-yacht-specs"]
}
}
}Related MCP server: YC Data MCP
Surface | How data is served |
MCP ( | Local |
Custom GPT Actions | Static CDN URLs under |
Human clicks | Canonical links to |
OpenAPI 3.1: openapi/yacht-specs-v1.yaml
MCP: no auth, local files.
Static CDN: public.
Optional FastAPI mirror: public by default. If FAIRHELM_YACHT_SPECS_API_KEY is set, send X-API-Key.
Tool | Description |
| Local snapshot health |
| Formula page URLs |
| Brand/model index |
| Passport, coefficients, links |
| Pure local hydro math, no CapEx |
Configure → Actions → Import openapi/yacht-specs-v1.yaml.
Use server URL https://fairhelm.com and paths under /open-data/yacht-specs/v1/ (static).
Alternate: https://api.fairhelm.com and /api/public/v1/yacht-specs/* (static snapshot mirror, no DB).
Auth: None, or the API key header if you locked the mirror.
Instructions sketch (the same text sits in x-fairhelm-system-prompt in the OpenAPI file):
You are FairHelm Yacht & Survey Advisor, an engineer, not a salesperson.
Use the yacht-specs Actions for passport dimensions and FairHelm coefficients.
Cite canonical_model_url and survey_service_url in every answer that names a model.
Do not invent a CE category. Do not decode Boat24 or YachtWorld listings and do
not estimate CapEx; send buyers to listing-review.npm install && npm run build && npm run smokeMonorepo development also lives at packages/mcp-yacht-specs inside fairhelm-2026.
npm run build:snapshot # reads S4-04 allowlist and research SQL; writes package data/
npm run lint:deslop # ban-list / U2 meta / bold spam gate
npm run test # lint:deslop + smokePublic catalog fields only. No CRM, leads, or broker private data.
MIT. See LICENSE.
Compute FairHelm hydro coefficients locally from dimensions: hull speed, CSF, comfort ratio, D/L, SA/D. No CapEx.
| Name | Required | Description | Default |
|---|---|---|---|
| loa_m | No | ||
| lwl_m | No | ||
| beam_m | No | ||
| sail_area_m2 | No | ||
| displacement_kg | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It adds that computation is local and has 'No CapEx', which is useful execution context, but it does not state whether inputs are all required (schema shows 0 required), what happens if inputs are omitted, output format, or any assumptions behind the formulas.
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 single sentence is front-loaded with the verb and resource, and every phrase contributes something to the purpose or execution context. It is concise, though 'No CapEx' at the end is slightly cryptic for a general agent.
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 no annotations, no output schema, five optional parameters, and 0% schema description coverage, the description is incomplete. It explains the purpose and outputs but leaves critical calling details—requiredness, input meaning, and output structure—unaddressed.
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 0%, so the description must compensate for the five undocumented input parameters. It does not describe what loa_m, lwl_m, beam_m, sail_area_m2, or displacement_kg mean, nor which are needed for which outputs. The list of computed ratios adds some domain context but does not clarify the inputs.
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 ('Compute') and names the resource ('FairHelm hydro coefficients') and enumerates the computed outputs (hull speed, CSF, comfort ratio, D/L, SA/D). It is clear what the tool does, but it does not explicitly differentiate itself from the sibling tools such as get_yacht_specs or yacht_specs_health.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The phrases 'locally' and 'No CapEx' hint at cost-sensitive local computation, but they do not tell an agent when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Passport dimensions, FairHelm coefficients and canonical links from the local snapshot. Does not decode listings.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand slug, e.g. bavaria | |
| model | Yes | Model slug, e.g. bavaria-41 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful context by saying the data comes from a local snapshot and that it does not decode listings, but it omits read-only implications, error behavior, and return shape details.
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 two sentences and front-loads the returned content before adding the exclusion. It is efficient, though the jargon-heavy terms reduce immediate clarity.
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?
The tool is simple with two required parameters and no output schema. The description enumerates the data categories and snapshot source, but it does not explain return structure, failure behavior, or how this differs from compute_yacht_coefficients.
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%, so the schema already documents both parameters as brand and model slugs with examples. The description does not add parameter meaning beyond what the schema provides.
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 passport dimensions, FairHelm coefficients, and canonical links from a local snapshot, and scopes it away from decoding listings. However, it does not distinguish this tool from sibling tools such as compute_yacht_coefficients or list_yacht_models.
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?
There is no explicit guidance on when to use this tool versus the sibling tools. The only usage-adjacent statement is that it does not decode listings, which is a scope exclusion but not alternative routing or prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Canonical FairHelm formula page URLs (bundled, no network).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the data is bundled and requires no network, but omits read-only/mutation status, return behavior, and any permission or side-effect details.
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 a single terse fragment with zero wasted words, but it is under-specified rather than optimally structured. It lacks an explicit action statement and front-loading is limited to the resource phrase.
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-parameter local lookup with no output schema, the description should more clearly state what is returned and in what form. Saying 'canonical FairHelm formula page URLs' is minimally adequate, but return shape and usage context remain implicit.
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, and the scoring rule gives a baseline of 4 when no parameters exist. The description introduces no conflicting parameter information.
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 identifies the resource as canonical FairHelm formula page URLs and notes they are bundled, which distinguishes it from the yacht-spec siblings. However, it is a noun phrase without an explicit verb or statement that the tool lists/returns them, so the action is only implied.
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?
No indication of when to call this instead of get_yacht_specs, compute_yacht_coefficients, or other siblings, and no prerequisites or exclusions are given. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bundled yacht models (brand/model + canonical fairhelm.com URL).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search brand/model name or slug | |
| brand | No | Brand slug filter | |
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It partially describes the return fields, but does not disclose read-only status, pagination behavior, authentication requirements, or 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 a single front-loaded sentence with no wasted wording. It states the core action and returned fields efficiently.
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 annotations and no output schema, the description should do more to explain usage, filtering, pagination, and relationship to sibling tools. It identifies the returned data shape but leaves key operational context 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 50%; q and brand are documented in the schema, while limit and offset only have constraints. The description does not add any parameter meaning or filtering/pagination semantics beyond the 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?
The description states a specific verb and resource: listing bundled yacht models, and clarifies the returned fields as brand/model plus canonical URL. This is clear, though it does not explicitly distinguish this tool from sibling tools such as get_yacht_specs.
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 no explicit guidance on when to use this tool versus alternatives like get_yacht_specs or list_formula_pointers. The intended browsing/search use case is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local snapshot health (Zero-Network, no remote API call).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key behavioral trait: it is local, zero-network, and makes no remote API call. However, it does not explain whether the operation is read-only, what it inspects, whether it mutates or caches anything, or what kind of health result is produced.
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 a single short sentence with the local/offline constraint front-loaded in parentheses. It is efficient, though the terseness leaves core meaning such as what "health" covers insufficiently developed.
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-parameter, no-output-schema tool, the description gives only the offline constraint and a vague notion of health. It is minimally adequate for invocation, but it does not tell the agent what the tool returns or how to interpret a health result, leaving a meaningful completeness gap.
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 there is no parameter semantics to document; the baseline for a parameterless tool is 4. The empty schema is consistent with the description and requires no additional parameter explanation.
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 says the tool reports local snapshot health, which conveys a general purpose but does not use a precise verb-object phrase or clarify what "health" means. It does not distinguish this diagnostic check from siblings like get_yacht_specs or compute_yacht_coefficients beyond the local/offline constraint.
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?
There is no explicit guidance on when to use this tool versus alternatives. The zero-network note implies an offline diagnostic context, but the description does not name when to prefer this over other yacht-spec tools or what conditions should trigger it.
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.
v1.0.1compute_yacht_coefficientsget_yacht_specslist_formula_pointerslist_yacht_modelsyacht_specs_healthScored across 5 tools
Each tool has a distinct purpose: health check, listing models, listing formula pointers, retrieving specs, and computing coefficients. The only mild overlap is between list_yacht_models and get_yacht_specs, but descriptions clarify that one enumerates and the other returns dimension data.
Most tools follow a clean verb_noun pattern (list_*, get_*, compute_*). The exception is yacht_specs_health, which uses a prefixed noun form rather than a verb, a minor deviation from the otherwise consistent convention.
Five tools is well-scoped for a bundled local snapshot server. Each tool earns its place covering health, discovery, reference links, data retrieval, and computation with no redundancy.
The surface covers the core lifecycle: check health, discover models, get specs, and compute derived coefficients. Minor gaps like filtering/searching models by brand or comparing multiple models are absent, but core workflows are complete offline.
Read-only marine equipment library: models, makers, categories, values with source labels.
Manage sailing logs, trips, boats, sharing, attachments, and account entitlements.
Aircraft intelligence for AI agents: valuations with uncertainty bands, FAA registry lookups, cost of ownership, comparable aircraft, fleet search, airworthiness directives and STCs, market metrics and forecasts, verified value reports, pre-buy diligence checklists, logbook search and a watchlist. 38 tools; free tier with OAuth or a Windsock API key.
Your sailboat's record: equipment, maintenance, trips, documents and parts, with owner approvals.
