MCP connector for ship modelling and scale modeling: explore detailed ship model builds, historical sailing ships, build logs, tutorials, galleries, and research content.
Scored across 13 tools
Every tool targets a distinct resource and action, and descriptions explicitly state when to use a sibling instead (e.g. calculate_rope_diameter vs find_rope_threads, get_build_details vs get_project_status, search_content vs search_tutorial_content). Even the closest pairs (search_content / search_tutorial_content, list_builds / list_model_slugs) are separated by explicit scope statements (metadata vs full body, browse vs slug lookup).
All 13 tools follow a strict snake_case verb_noun pattern using a small, predictable verb set (calculate_, find_, get_, list_, search_). Minor qualifying suffixes like get_tutorial_by_title remain readable and consistent within the convention.
13 read-only tools spread across four coherent sub-domains (rope math, model builds, tutorials, gallery/taxonomy), each earning its place with no redundant duplicates. The size sits comfortably in the ideal 3-15 range with no filler tools.
Model builds, tutorials, and rope calculations each have browse/detail/filter/search coverage, forming a coherent read-only surface. The main gap is gallery: only list_gallery_photos exists, with no single-photo detail retrieval, though the list returns rich metadata that largely compensates.
Read-only. Calculates the estimated diameter of a three-strand rope from a thread's linear density and the number of threads per strand. Use this tool when the user asks how thick a rope made from a given thread will be, or what diameter a custom dTex produces. Provide basis 'catalog' with threadId for a catalog thread, or basis 'dtex' with a value between 80 and 6000 for a custom thread. threadsPerStrand is 1 to 5; because all ropes have three strands, 2 corresponds to the 2 × 3 construction. Diameters are model estimates, not measured values. The response includes the diameter in millimetres, the construction label, the resolved dTex, and API, algorithm and catalog versions. Use find_rope_threads when the user wants threads for a target diameter instead.
| Name | Required | Description | Default |
|---|---|---|---|
| dtex | No | Custom linear density in dTex, from 80 to 6000 inclusive. Required when basis is 'dtex'. | |
| basis | Yes | Source of the linear density. Use 'catalog' for a thread from the catalog, or 'dtex' for a custom value. | |
| threadId | No | Catalog thread id, for example 'tera-40'. Required when basis is 'catalog'. Use find_rope_threads to see which thread ids match a target diameter. | |
| threadsPerStrand | Yes | Threads per strand: 1 to 5. All ropes have three strands, so 2 means the 2 × 3 construction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares the tool read-only, warns that diameters are model estimates rather than measurements, and lists the returned fields including diameter, construction label, resolved dTex, and version metadata. The only minor gap is that it does not describe error behavior for invalid basis/threadId combinations.
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 read-only status and purpose, then moves through usage, input conditions, caveats, and response contents in a logical order. It is slightly longer than necessary because it repeats parameter ranges already covered by the schema, but no sentence is seriously wasteful.
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 computational tool with no annotations and no output schema, the description explains the return payload, the estimate caveat, and the valid input combinations. An agent has enough information to invoke it correctly without needing to infer missing 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 description coverage is 100%, so the schema already documents all four parameters, including conditional requirements and ranges. The description reinforces the basis/threadId/dtex conditions and explains that threadsPerStrand 2 means the 2 × 3 construction, but these details are also present in the schema, so it adds little beyond structured data.
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 and resource: it calculates the estimated diameter of a three-strand rope from thread linear density and threads per strand. It clearly distinguishes the tool from the sibling find_rope_threads, which solves the inverse problem.
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 explicitly states when to use the tool: when the user asks how thick a rope will be or what diameter a custom dTex produces. It also states when to use the alternative: find_rope_threads when the user wants threads for a target diameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Finds catalog thread constructions whose estimated rope diameter is within ±15% of a target diameter. Use this tool when the user asks which threads to use for a rope of a given thickness. It checks 1, 2 and 3 threads per strand for every selected thread. Omit threadIds to search the whole active catalog, or pass thread ids to narrow the search. Results are sorted by absolute deviation from the target, then dTex, then threads per strand, with a deterministic tie-break. The response includes every match with its diameter and deviation percent, the tolerance, and the catalog version. An empty results array means no construction fits the ±15% tolerance; it is a successful answer, not an error. Use calculate_rope_diameter to get the diameter for one specific thread.
| Name | Required | Description | Default |
|---|---|---|---|
| threadIds | No | Optional list of catalog thread ids to check, for example ['tera-40', 'tera-30']. Omit to check the whole active catalog. | |
| targetDiameterMm | Yes | Target rope diameter in millimetres, greater than zero. Matches within ±15% of this value are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden and does so: 'Read-only' is stated up front, the ±15% tolerance and deterministic sort order are disclosed, and it explicitly says an empty results array is a successful answer rather than an error. It does not discuss permissions or response size limits, keeping it 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?
Front-loads read-only status, then purpose, then usage, then return behavior. Every sentence adds a fact the agent cannot get from the schema, and the alternative is placed at the end where it reads as a routing hint.
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?
No output schema exists, yet the description enumerates the response contents (matches, diameter, deviation percent, tolerance, catalog version) and interprets the empty-array case. For a two-parameter read tool this leaves no meaningful 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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics: omitting threadIds scopes to the whole active catalog, and each selected thread is evaluated at 1, 2 and 3 threads per strand. That clarifies what the id list actually controls, which the schema alone does not.
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?
Opens with a specific verb and resource ('Finds catalog thread constructions') plus the exact matching rule (±15% of a target diameter). It is clearly distinguishable from calculate_rope_diameter, which is named as the single-thread alternative.
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?
States the triggering user question ('which threads to use for a rope of a given thickness') and offers the sibling alternative for the single-thread case. It also gives explicit branching on the optional param: omit threadIds for the whole catalog, pass ids to narrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns detailed information for one sailing-ship model, including vessel background, technical notes, and build-log parts. Use list_builds to browse or filter the model catalog, and use list_model_slugs when a model slug must be identified from a name or metadata. Use this tool when details for one known model are needed; do not use it for catalog browsing. Without partNumber or partSlug, returns model metadata and a summary list of build-log parts. Set partNumber or partSlug to retrieve one build-log part with complete, untruncated content. If both are provided, partSlug takes precedence. Returns a not-found result if the model or requested build-log part does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| partSlug | No | Optional stable slug of one build-log part. Takes precedence over partNumber and returns that part's complete content. | |
| buildName | Yes | Human-readable model name. Use list_builds to browse models or list_model_slugs to identify a model before requesting details. | |
| partNumber | No | Optional build-log part number. Use this to retrieve one part when its part slug is not known. If partSlug is also provided, partSlug takes precedence. If neither partNumber nor partSlug is provided, returns model details and summaries of all build-log parts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it starts with 'Read-only', explains the differential output with and without partNumber/partSlug, states that partSlug takes precedence when both are given, and notes that a not-found result is returned for missing models or parts. This covers the key side effects and conditional behavior an agent needs to anticipate.
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 five sentences with no filler; every sentence contributes either core function, usage routing, parameter behavior, or error handling. The lead sentence immediately conveys read-only status and main purpose, making it scannable.
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 tool with only 3 parameters, no output schema, and no annotations, the description covers all necessary decision points: when to use it, how to identify the build name, how to fetch a specific part, what the default return looks like, and error behavior. Nothing essential is missing for correct invocation.
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 baseline is 3, but the description adds meaningful combination semantics beyond the schema: it clarifies what happens when neither partNumber nor partSlug is provided, explicitly states precedence rules when both are present, and ties buildName to the browsing/identification flow. This elevates it above the baseline.
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 states a specific verb and resource: 'Returns detailed information for one sailing-ship model' and lists included content areas. It clearly separates this from sibling tools by specifying 'for one known model' and 'do not use it for catalog browsing', so an agent can distinguish it from list_builds and list_model_slugs.
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 names alternatives: 'Use list_builds to browse or filter the model catalog' and 'use list_model_slugs when a model slug must be identified from a name or metadata'. It states the condition for using this tool ('when details for one known model are needed') and gives an exclusion ('do not use it for catalog browsing').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns the current build status for one sailing-ship model, including its display status, normalized status slug, and completion date when available. Use this tool when the user asks specifically for the status of one known model. Use list_builds to browse, compare, or filter multiple models. Use get_build_details for vessel background, technical notes, and build-log parts. Returns a not-found result if no model matches the provided name.
| Name | Required | Description | Default |
|---|---|---|---|
| buildName | Yes | Human-readable model name, for example 'Le Requin' or 'Bounty'. Use list_builds to browse models or list_model_slugs when the exact model name is unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It opens with 'Read-only,' which covers the safety profile, and discloses edge-case behavior with 'Returns a not-found result if no model matches the provided name.' It also notes that completion date is included only 'when available,' providing useful conditional behavior.
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, with the core purpose in the first sentence. Every subsequent sentence adds distinct value: what is returned, when to use it, which alternatives to use instead, and not-found behavior. No filler or repetition.
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 one-parameter read-only lookup with no output schema, the description is complete. It covers the expected output fields, the not-found case, and proper routing to sibling tools for different user intents.
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 buildName parameter is already well documented with examples and guidance to use list_builds or list_model_slugs when the name is unknown. The tool description itself adds little beyond that, so the schema carries the semantic weight, putting this at the baseline.
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 a specific action ('Returns') and resource ('current build status for one sailing-ship model'), and lists the exact output fields. It also names sibling tools get_build_details and list_builds, so an agent can distinguish this tool without reading their schemas.
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 explicitly states when to use this tool: 'when the user asks specifically for the status of one known model.' It also gives clear alternatives: list_builds for browsing/comparing/filtering multiple models and get_build_details for background, technical notes, and build-log parts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Finds one educational tutorial by its human-readable title and returns its content and metadata. Use this tool when the user knows an article title but does not know its slug. Use get_tutorials to browse or filter tutorials, or to retrieve one tutorial when its slug is known. Use search_tutorial_content when the user knows only a term, technique, material, tool, or instruction that may occur inside a tutorial. The tool prefers an exact case-insensitive title match and otherwise uses a case-insensitive partial title match. Returns a not-found result if no tutorial matches the provided title.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Human-readable tutorial title. Matching is case-insensitive: an exact title match is preferred, followed by a partial title match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It declares the operation is read-only, describes the matching strategy ('exact case-insensitive title match' then 'partial title match'), and states the not-found behavior. This is unusually complete for a tool with no annotation support.
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?
Every sentence earns its place: the read-only nature is front-loaded, the purpose is clear, alternatives are routed, and the matching behavior is precise. Despite being longer than a one-liner, it is tightly structured with no 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?
For a single-parameter lookup tool with no output schema, the description fully enables correct invocation and interpretation. It covers when to use it, how matching works, what it returns, and what happens when no match is found. Nothing essential 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%, so the schema already documents the title parameter and its case-insensitive semantics. The tool description reinforces this but does not add meaning substantially beyond what the input schema already provides, which aligns with the baseline for high coverage.
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 ('Finds'), a clear resource ('educational tutorial by its human-readable title'), and the return value ('content and metadata'). It is immediately distinguishable from sibling tools like get_tutorials and search_tutorial_content because the description names the exact lookup-by-title behavior.
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?
Explicitly states when to use this tool: when the user knows an article title but not its slug. It also names the alternatives and their conditions: get_tutorials for browsing/filtering or slug-known retrieval, and search_tutorial_content for searching inside tutorial content. No ambiguity remains about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns educational tutorials from the site, optionally filtered by tag, category, tagFacet, or difficulty level. Use this tool to browse tutorials and filter them by taxonomy. When a slug is provided, it returns the content and metadata for one tutorial. Use get_tutorial_by_title when the user knows an article title but not its slug. Use search_tutorial_content when the user knows only a term, technique, material, tool, or instruction that may occur inside a tutorial. Use list_tutorial_taxonomy when the exact available category, tag, or difficulty-level value is unknown. Without a slug, returns tutorial summaries and metadata. Each tag object includes name, slug, and facet (component | technique | material | context | null). If no tutorials match the filters, returns an empty tutorials array. If a provided slug does not exist, returns a not-found result.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional filter for tutorial tags. Preferred format: slug (lowercase, hyphen-separated), e.g. 'standing-rigging', 'wood-bending', 'double-planking'. Display names are also accepted (e.g. 'Standing Rigging'). Matching is case-insensitive and partial — 'rigging' matches both 'standing-rigging' and 'running-rigging'. Applies only when slug is omitted. | |
| slug | No | Optional stable tutorial slug. When provided, returns the complete content and metadata for one tutorial. When omitted, returns a filtered list of tutorial summaries. | |
| level | No | Optional filter for tutorial difficulty level. Uses an exact match, for example 'beginner'. Applies only when slug is omitted. | |
| category | No | Optional filter for tutorial categories. Uses a case-insensitive partial match against category names. Applies only when slug is omitted. | |
| tagFacet | No | Optional filter for tutorial tags by facet type. component — structural parts of the model (Hull, Deck, Masts…); technique — build methods (Caulking, Wood Bending, Blackening…); material — materials used (Wood, Brass, Thread…); context — themes or use-case labels (Standing Rigging, Running Rigging…). Can be combined with the tag filter. Applies only when slug is omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that the tool is read-only, returns summaries without a slug, returns full content with a slug, includes behavior for no matches (empty array) and non-existent slugs (not-found result). This is substantial behavioral context, though it could go further (e.g., pagination, rate 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 comprehensive yet structured: it starts with a clear statement of purpose, lists filters, explains parameter interactions, and provides routing guidance. Every sentence adds value, and the key behavioral distinction (with/without slug) is front-loaded. Despite its length, it is efficient for a tool with 5 parameters and multiple sibling alternatives.
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 tool's complexity (5 optional parameters, multiple filtering modes, sibling alternatives) and lack of annotations and output schema, the description covers all essential aspects: what it returns, filter behavior, edge cases (empty results, not-found), and routing to alternatives. It is complete for an agent to invoke correctly without needing additional documentation.
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 schema already provides detailed descriptions for each parameter, including format hints like 'slug (lowercase, hyphen-separated)' and match behavior. The description does not add much beyond what the schema provides, so a baseline 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 clearly states the tool's purpose: 'Returns educational tutorials from the site' and explains filtering options. It distinguishes itself from siblings by naming specific alternatives and their use cases, such as get_tutorial_by_title and search_tutorial_content. This provides clear differentiation.
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 says when to use this tool versus alternatives: 'Use get_tutorial_by_title when the user knows an article title but not its slug. Use search_tutorial_content when the user knows only a term... Use list_tutorial_taxonomy when the exact available category, tag, or difficulty-level value is unknown.' This is excellent routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns a list of sailing-ship model summaries with title, slug, scale, manufacturer, build status, and site URL. Use this tool to browse the model catalog, compare models, filter by build status, or discover a model before requesting details. Use get_project_status only for the current progress of one known model. Use get_build_details for vessel background, technical notes, or build-log content. Results follow the site's model order and are limited to the requested limit. The response includes total for the number of returned models and totalAvailable for the number of models matching the filter before the limit is applied. If no models match the filter, returns an empty builds array.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of model summaries to return. Default: 50. Maximum: 100. | |
| status | No | Filter by build status. If omitted, models with all statuses are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and meets it. It discloses that the operation is 'Read-only,' explains result ordering ('follow the site's model order'), describes the limit behavior, defines response fields (total and totalAvailable), and states the empty-result case. This is comprehensive behavioral disclosure for a read-only list tool.
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 ('Read-only. Returns a list...') and every sentence carries information: usage guidance, sibling differentiation, ordering, limit semantics, response fields, and empty behavior. It is slightly verbose compared to the tightest possible version, but each sentence 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 list tool with two fully documented optional parameters and no output schema, the description covers everything an agent needs: what is returned, field names, filtering, limit semantics, count fields, empty behavior, and when to use alternatives. Nothing material 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%, so the schema already fully documents both parameters (limit with default/max/min, status with enum and omission behavior). The description adds minor context by mentioning 'filter by build status' and 'limited to the requested limit,' but does not need to compensate for any schema gaps. Baseline 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 ('Returns a list of sailing-ship model summaries') and enumerates the exact fields included. It explicitly distinguishes the tool from siblings by naming get_project_status and get_build_details and stating what each of those is for, so an agent can tell them apart without opening schemas.
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 gives usage scenarios: 'browse the model catalog, compare models, filter by build status, or discover a model before requesting details.' It also provides clear exclusion guidance: 'Use get_project_status only for the current progress of one known model' and 'Use get_build_details for vessel background, technical notes, or build-log content.' This fully routes the agent to the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns a paginated list of gallery photo summaries with captions, image URLs, model project references, taxonomy tags, and image metadata. Use this tool to browse gallery photos or filter them by model project, taxonomy tags, and tag facet. Use get_build_details when the user needs vessel background, technical notes, or build-log content for the related model. Photos share one taxonomy with tutorials; call list_tutorial_taxonomy (appliesTo='gallery') to get the allowed tag slugs, names, and facets. Each photo's section field is an ARRAY of tag slugs (legacy single-string sections are normalized to a one-element array); tagDetails gives name and facet for each tag; legacySection keeps the pre-taxonomy section label when present. Filters: tag accepts a string (legacy) or an array of slugs; match='any' (default) returns photos with at least one listed tag, match='all' returns photos with every listed tag; tagFacet (component | technique | material | context | view) keeps photos with at least one tag of that facet; tag and tagFacet combine with AND. Results are ordered by project and then by each project's gallery order. The response includes total matching photos, returned count, limit, offset, nextOffset, and hasMore. Use nextOffset from a response with hasMore=true to retrieve the next page. If no photos match a valid filter, returns an empty photos array; unknown tag values are listed in unknownTags. If project does not identify a gallery project, returns a not-found result.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional filter by photo taxonomy tags. Accepts a single tag string (legacy format, still supported) or an array of tags. A string is equivalent to a one-element array: tag='hull' and tag=['hull'] return the same photos. Values are taxonomy slugs such as 'hull', 'standing-rigging', 'side-view', 'close-up'; display names from the taxonomy (e.g. 'Standing Rigging') are also accepted, case-insensitive. Matching is exact by slug (no partial matching). How several values combine is controlled by match. Get the allowed values from list_tutorial_taxonomy (tags with 'gallery' in appliesTo, or appliesTo='gallery'). | |
| limit | No | Maximum number of photos to return. Default: 50. Maximum: 100. | |
| match | No | How multiple tag values combine. 'any' (default) — a photo matches if it has at least one of the tags (OR). 'all' — a photo matches only if it has every listed tag (AND). Has no effect when tag has a single value. | any |
| offset | No | Number of matching photos to skip before returning the current page. Use nextOffset from a previous response to retrieve the next page. | |
| project | No | Optional model project slug to filter photos, for example 'le-requin'. When omitted, returns photos from all gallery projects. | |
| tagFacet | No | Optional filter by tag facet: keeps photos that have at least one active tag of this facet. component — model parts (Hull, Deck, Masts…); technique — build methods (Planking, Caulking…); material — materials (Wood, Brass…); context — themes (Standing Rigging, Running Rigging…); view — camera viewpoint (Overall View, Side View, Close-up…). When combined with tag, both conditions must hold (AND). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so: it declares read-only, describes ordering ('by project and then by each project's gallery order'), pagination mechanics (nextOffset/hasMore), and error behaviors (empty array with unknownTags, not-found result). It also discloses data-shape quirks like array-normalized section and legacySection.
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-loads the read-only flag and core purpose, then layers filters, taxonomy notes, and pagination. Most sentences earn their place, though the density is high and a few details (section/legacySection normalization) could be trimmed without losing routing value.
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 output schema, the description compensates fully: it enumerates response fields (total, returned count, limit, offset, nextOffset, hasMore), ordering, and edge-case returns, so an agent can consume results and paginate without additional documentation.
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 the baseline is 3, but the description adds cross-parameter meaning the schema omits: 'tag and tagFacet combine with AND', the tag/match interaction, and the legacy-string vs array equivalence for section/tag. This goes beyond restating 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?
States a specific verb and resource ('Returns a paginated list of gallery photo summaries') and enumerates the return fields. It explicitly distinguishes itself from siblings by naming get_build_details and list_tutorial_taxonomy and describing when each applies instead.
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?
Explicitly says 'Use this tool to browse gallery photos or filter them by model project, taxonomy tags, and tag facet', then routes the agent to get_build_details for vessel background and list_tutorial_taxonomy for tag slugs. When-to-use and alternatives are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Finds valid sailing-ship model slugs by full or partial model name, build status, manufacturer, or scale. Use this tool when another tool requires a model slug and the user provides only a human-readable model name or identifying metadata. Use list_builds when the user wants to browse or compare the model catalog. Returns matching model titles, slugs, URLs, and minimal identification metadata. When name matches more than one model, ambiguous is true and results contains all matching candidates. If no models match the criteria, returns an empty results array.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full or partial model name to search for. Matching is case-insensitive and checks both the model title and slug. If omitted, all models are considered. | |
| scale | No | Filter by exact model scale, for example '1:64'. | |
| status | No | Filter by build status. If omitted, models with all statuses are considered. | |
| manufacturer | No | Filter by kit manufacturer using a case-insensitive partial match. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. It clearly states the tool is read-only, describes the returned fields, explains the 'ambiguous' flag behavior, and specifies the empty-results case. It omits minor details like pagination or result limits, but the core behavior is well disclosed.
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 'Read-only' and the core purpose, then moves into usage guidance and output behavior. Each sentence serves a distinct function with no wasteful 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?
With no output schema and no annotations, the description covers purpose, usage, output contents, disambiguation behavior, and the no-match case. This is sufficient for an agent to invoke the tool correctly in the common slug-resolution workflow.
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 input schema already fully documents all four parameters. The description adds little beyond restating the filter dimensions, which is acceptable but does not elevate above the baseline.
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: 'Finds valid sailing-ship model slugs' by several clear criteria. It also distinguishes itself from list_builds, so an agent can tell which tool to use without inspecting other definitions.
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 says when to use this tool: when another tool requires a model slug and the user provides a human-readable name or metadata. It also names the alternative list_builds for browsing/comparing the catalog, making the routing decision unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns the full active rope thread catalog ordered from thin to thick, each with its id, brand, number, linear density in dTex, sort order and a human-readable label. Use this tool to discover thread ids before calling calculate_rope_diameter, or when the user asks which threads are available. Threads disabled or unpublished in the CMS are not included. The response also carries the catalog version and the moment the catalog was read. Use find_rope_threads when the user needs threads for a specific target diameter instead of the whole catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and does well: it declares the operation read-only, states that disabled/unpublished threads are excluded, and discloses freshness metadata (catalog version plus read timestamp). It stops short of covering failure modes or what an empty catalog would look like, so it is strong but not exhaustive.
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 tight sentences: operation and return contents first, then when to use it, then the sibling fallback. Every sentence adds routing or return-shape information with no padding.
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?
There is no output schema, yet the description compensates by enumerating the returned fields and the envelope (catalog version, read time). For a zero-parameter read tool, an agent has everything needed to call it and interpret the result.
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 the baseline is 4; the description correctly makes no parameter claims and instead spends its words on the return shape, which is the right allocation of effort here.
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 ('Returns the full active rope thread catalog'), specifies ordering (thin to thick) and enumerates the returned fields (id, brand, number, dTex, sort order, label). It also names the sibling it is not, so an agent can distinguish it from find_rope_threads at a glance.
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 two concrete use cases (discover thread ids before calculate_rope_diameter, or answering 'which threads are available') and an explicit exclusion routing the agent to find_rope_threads when a target diameter is involved. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Returns the shared taxonomy dictionary used by both tutorials and gallery photos, plus tutorial categories and difficulty levels with tutorial counts. Tags come from the TutorialTags taxonomy (ACF Tutorial Tag Settings) with status='active' and are listed only when assigned to at least one tutorial or at least one gallery photo. Each tag has slug, name, facet (component | technique | material | context | view | unclassified), status, publicFilter (shown in tutorial UI filters), count (number of tutorials), photoCount (number of gallery photos), and appliesTo — an array with 'tutorials', 'gallery', or both, computed from actual assignments (cached up to 60 minutes). Use tags with 'tutorials' in appliesTo as values for get_tutorials tag/tagFacet filters, and tags with 'gallery' in appliesTo as values for list_gallery_photos tag/tagFacet filters. Use appliesTo='tutorials' or appliesTo='gallery' to return only tags used in that area. Use includeDeprecated=true to also include non-active (deprecated or hidden) tags for audit purposes. Use groupByFacet=true to receive tags grouped by facet instead of a flat list. Tags are ordered by tutorial count, then photo count, descending; categories and levels by tutorial count. This tool returns taxonomy metadata, not tutorial articles or photos. If nothing is available, returns empty categories, tags, and levels arrays.
| Name | Required | Description | Default |
|---|---|---|---|
| appliesTo | No | Optional filter: 'tutorials' returns only tags assigned to at least one tutorial, 'gallery' only tags assigned to at least one gallery photo. When omitted, returns tags used in either area. | |
| groupByFacet | No | When true, returns tags grouped by facet (component, technique, material, context, view, unclassified) instead of a flat sorted list. | |
| includeDeprecated | No | When true, also includes tags whose status is not 'active' (deprecated or hidden), if they are assigned to tutorials or photos. Default: false (only active tags are returned). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so: it declares 'Read-only', discloses the 60-minute cache, the active-status default and what includeDeprecated changes, ordering rules, and the empty-arrays fallback. These are behavioral traits the schema does not express.
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 read-only signal and the core return shape, and every sentence carries information an agent needs. It is dense and long, but not padded; a small trim of enumerated field lists would tighten it further.
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 output schema, the description enumerates the returned fields (slug, name, facet, status, publicFilter, count, photoCount, appliesTo) and the facet enum values, plus categories/levels ordering and the empty-result case, so an agent can consume the response without guessing.
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 the baseline is 3; the description nonetheless adds value beyond the schema by framing appliesTo values as filter inputs for other tools and explaining includeDeprecated as an audit use case rather than just a boolean flag.
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 ('Returns the shared taxonomy dictionary... plus tutorial categories and difficulty levels') and explicitly excludes what it is not ('returns taxonomy metadata, not tutorial articles or photos'), which cleanly separates it from siblings like get_tutorials and list_gallery_photos.
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 routing: tags with 'tutorials' in appliesTo feed get_tutorials tag/tagFacet filters, tags with 'gallery' feed list_gallery_photos filters, and it names when to use appliesTo, includeDeprecated (audit purposes), and groupByFacet. When-to-use and cross-tool alternatives are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Searches build-log metadata and tutorial metadata by keyword. Build-log matches use model title, model slug, historical year, part title, and excerpt. Tutorial matches use tutorial title and short description only. Use this tool for broad content discovery when the relevant model or tutorial is not yet known. Use search_tutorial_content when the requested term, technique, material, tool, or instruction may occur inside the complete body text of a tutorial. Use get_build_details or get_tutorials to retrieve details after identifying a relevant result. Every query term must match across the searchable fields of a result. Returns separate buildLogResults and tutorialResults arrays, each limited to the requested limit. If no content matches, both result arrays are empty.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return for each result type. Default: 20. Maximum: 50. | |
| query | Yes | Search terms for broad discovery across build-log metadata and tutorial metadata. Every term must match across the searchable fields of one result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is read-only, explains that every query term must match across searchable fields, and fully describes return behavior: two separate arrays, each limited to the requested limit, and empty arrays when there are no matches.
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 every sentence serves a purpose: it front-loads the read-only nature and core purpose, explains matching semantics, distinguishes from sibling tools, and specifies return behavior. Nothing is redundant or irrelevant.
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?
Even without an output schema, the description tells the agent what the return shape will be (buildLogResults and tutorialResults arrays), how results are limited, and what happens in the no-match case. Combined with the routing guidance and parameter semantics, this is complete enough for correct invocation.
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 input schema already documents both parameters with clear descriptions and defaults, so the baseline is 3. The description adds meaningful semantic detail beyond the schema by enumerating exactly which fields are searched for build-log matches versus tutorial matches, and by clarifying that query terms must all match within a result.
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 a specific action and resource: 'Searches build-log metadata and tutorial metadata by keyword.' It also differentiates itself from search_tutorial_content by specifying that this tool searches metadata only, not full tutorial body text.
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 usage guidance: use for broad content discovery when the relevant model or tutorial is not yet known, use search_tutorial_content for full-text body matching, and use get_build_details or get_tutorials for follow-up details. This fully explains when to choose this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only. Searches educational tutorials by full article body text, title, summary, and tags. Use this tool when the user asks about a term, technique, material, tool, or instruction that may occur inside a tutorial. Use search_content for broad discovery across build-log metadata and tutorial metadata when full tutorial body text is not required. Use get_tutorials to browse tutorials or retrieve the content and metadata for a tutorial after identifying a relevant result. Returns matching tutorial summaries with matchedFields and a relevant excerpt. matchedFields may include: title, teaser, content, tags. Results are limited to the requested limit. If no tutorial content matches, returns an empty results array.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching tutorials to return. Default: 20. Maximum: 50. | |
| query | Yes | Search terms for educational tutorial title, summary, tags, and full article content. Every query term is evaluated by the tutorial text-matching logic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It opens with 'Read-only' to signal non-mutating behavior, describes the return format (tutorial summaries with matchedFields and an excerpt), lists possible matchedFields values, and states the edge case of an empty results array. This is thorough disclosure for a search tool, covering behavior, output shape, and failure mode.
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 well-structured with a front-loaded purpose, clear usage guidance, and a compact return-format section. It is somewhat lengthy but every sentence serves a purpose, and the information density is high. A slight trim could make it tighter, but it is not bloated.
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 tool's complexity (search with multiple siblings), the description covers all necessary aspects: what it searches, when to use it versus alternatives, what it returns, how results are limited, and the empty-result case. No output schema exists, but the description adequately explains the return shape, making it complete for an agent to call 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 description coverage is 100% for both parameters, and the schema already explains query as searching across title, summary, tags, and full article content, and limit as a maximum count. The description adds marginal detail (e.g., 'Every query term is evaluated by the tutorial text-matching logic') but largely repeats schema semantics, so a 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?
States a specific verb ('Searches'), a clear resource ('educational tutorials'), and the precise search scope ('full article body text, title, summary, and tags'). It also differentiates itself from siblings by explicitly naming search_content and get_tutorials with their distinct roles, leaving no ambiguity about what this tool does.
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?
Provides explicit when-to-use guidance ('Use this tool when the user asks about a term, technique, material, tool, or instruction that may occur inside a tutorial') and contrasts it with alternatives ('Use search_content for broad discovery...' and 'Use get_tutorials to browse...'). This makes the decision tree clear and actionable for an agent.
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.
calculate_rope_diameter2 fields changedInput schema / properties / threadsPerStrand / descriptionPrevious value: -"Threads per strand: 1, 2 or 3. All ropes have three strands, so 2 means the 2 × 3 construction."New value: +"Threads per strand: 1 to 5. All ropes have three strands, so 2 means the 2 × 3 construction."Input schema / properties / threadsPerStrand / maximumPrevious value: -3New value: +5calculate_rope_diameterfind_rope_threadslist_rope_threadslist_gallery_photos5 fields changedInput schema / properties / matchAdded value: +{
+ "default": "any",
+ "description": "How multiple tag values combine. 'any' (default) — a photo matches if it has at least one of the tags (OR). 'all' — a photo matches only if it has every listed tag (AND). Has no effect when tag has a single value.",
+ "enum": [
+ "any",
+ "all"
+ ],
+ "type": "string"
+}Input schema / properties / tag / anyOfAdded value: +[
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ }
+]Input schema / properties / tag / descriptionPrevious value: -"Optional gallery section filter. Matches the manifest section field exactly. Known values: overall, hull, deck, rigging, details."New value: +"Optional filter by photo taxonomy tags. Accepts a single tag string (legacy format, still supported) or an array of tags. A string is equivalent to a one-element array: tag='hull' and tag=['hull'] return the same photos. Values are taxonomy slugs such as 'hull', 'standing-rigging', 'side-view', 'close-up'; display names from the taxonomy (e.g. 'Standing Rigging') are also accepted, case-insensitive. Matching is exact by slug (no partial matching). How several values combine is controlled by match. Get the allowed values from list_tutorial_taxonomy (tags with 'gallery' in appliesTo, or appliesTo='gallery')."Input schema / properties / tag / typeRemoved value: -"string"Input schema / properties / tagFacetAdded value: +{
+ "description": "Optional filter by tag facet: keeps photos that have at least one active tag of this facet. component — model parts (Hull, Deck, Masts…); technique — build methods (Planking, Caulking…); material — materials (Wood, Brass…); context — themes (Standing Rigging, Running Rigging…); view — camera viewpoint (Overall View, Side View, Close-up…). When combined with tag, both conditions must hold (AND).",
+ "enum": [
+ "component",
+ "technique",
+ "material",
+ "context",
+ "view"
+ ],
+ "type": "string"
+}list_tutorial_taxonomy3 fields changedInput schema / properties / appliesToAdded value: +{
+ "description": "Optional filter: 'tutorials' returns only tags assigned to at least one tutorial, 'gallery' only tags assigned to at least one gallery photo. When omitted, returns tags used in either area.",
+ "enum": [
+ "tutorials",
+ "gallery"
+ ],
+ "type": "string"
+}Input schema / properties / groupByFacet / descriptionPrevious value: -"When true, returns tags grouped by facet type (component, technique, material, context, unclassified) instead of a flat sorted list."New value: +"When true, returns tags grouped by facet (component, technique, material, context, view, unclassified) instead of a flat sorted list."Input schema / properties / includeDeprecated / descriptionPrevious value: -"When true, includes tags with status='deprecated' in the result. Default: false (only active tags are returned)."New value: +"When true, also includes tags whose status is not 'active' (deprecated or hidden), if they are assigned to tutorials or photos. Default: false (only active tags are returned)."get_tutorials2 fields changedInput schema / properties / tag / descriptionPrevious value: -"Optional filter for tutorial tags. Uses a case-insensitive partial match against tag names. Applies only when slug is omitted."New value: +"Optional filter for tutorial tags. Preferred format: slug (lowercase, hyphen-separated), e.g. 'standing-rigging', 'wood-bending', 'double-planking'. Display names are also accepted (e.g. 'Standing Rigging'). Matching is case-insensitive and partial — 'rigging' matches both 'standing-rigging' and 'running-rigging'. Applies only when slug is omitted."Input schema / properties / tagFacetAdded value: +{
+ "description": "Optional filter for tutorial tags by facet type. component — structural parts of the model (Hull, Deck, Masts…); technique — build methods (Caulking, Wood Bending, Blackening…); material — materials used (Wood, Brass, Thread…); context — themes or use-case labels (Standing Rigging, Running Rigging…). Can be combined with the tag filter. Applies only when slug is omitted.",
+ "enum": [
+ "component",
+ "technique",
+ "material",
+ "context"
+ ],
+ "type": "string"
+}list_tutorial_taxonomy3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / groupByFacetAdded value: +{
+ "default": false,
+ "description": "When true, returns tags grouped by facet type (component, technique, material, context, unclassified) instead of a flat sorted list.",
+ "type": "boolean"
+}Input schema / properties / includeDeprecatedAdded value: +{
+ "default": false,
+ "description": "When true, includes tags with status='deprecated' in the result. Default: false (only active tags are returned).",
+ "type": "boolean"
+}search_tutorial_content1 field changedInput schema / properties / query / descriptionPrevious value: -"Search terms for educational tutorial title, summary, and full article content. Every query term is evaluated by the tutorial text-matching logic."New value: +"Search terms for educational tutorial title, summary, tags, and full article content. Every query term is evaluated by the tutorial text-matching logic."get_build_details3 fields changedInput schema / properties / buildName / descriptionPrevious value: -"Name of the build (model) for which detailed information is required."New value: +"Human-readable model name. Use list_builds to browse models or list_model_slugs to identify a model before requesting details."Input schema / properties / partNumber / descriptionPrevious value: -"Optional: the number of a specific build log part. If specified alongside partSlug, partSlug takes precedence. If neither is specified, a list of all parts is returned."New value: +"Optional build-log part number. Use this to retrieve one part when its part slug is not known. If partSlug is also provided, partSlug takes precedence. If neither partNumber nor partSlug is provided, returns model details and summaries of all build-log parts."Input schema / properties / partSlug / descriptionPrevious value: -"Optional: slug of a specific part of the build log (takes precedence over partNumber)."New value: +"Optional stable slug of one build-log part. Takes precedence over partNumber and returns that part's complete content."get_project_status1 field changedInput schema / properties / buildName / descriptionPrevious value: -"Model name (for example, 'Le Requin', 'Bounty')."New value: +"Human-readable model name, for example 'Le Requin' or 'Bounty'. Use list_builds to browse models or list_model_slugs when the exact model name is unknown."get_tutorial_by_title1 field changedInput schema / properties / title / descriptionPrevious value: -"Title of the educational article (full or partial, case-insensitive). Searches for an exact title match first, followed by a partial match."New value: +"Human-readable tutorial title. Matching is case-insensitive: an exact title match is preferred, followed by a partial title match."get_tutorials4 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter the list of articles by category (partial match of the category name)."New value: +"Optional filter for tutorial categories. Uses a case-insensitive partial match against category names. Applies only when slug is omitted."Input schema / properties / level / descriptionPrevious value: -"Article list filter by difficulty level (exact match, e.g., 'beginner')."New value: +"Optional filter for tutorial difficulty level. Uses an exact match, for example 'beginner'. Applies only when slug is omitted."Input schema / properties / slug / descriptionPrevious value: -"The slug of a specific educational article. If not specified, a list of all articles is returned."New value: +"Optional stable tutorial slug. When provided, returns the complete content and metadata for one tutorial. When omitted, returns a filtered list of tutorial summaries."Input schema / properties / tag / descriptionPrevious value: -"Article list filter by tag (partial tag name match, case-insensitive)."New value: +"Optional filter for tutorial tags. Uses a case-insensitive partial match against tag names. Applies only when slug is omitted."list_builds2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of builds in the response."New value: +"Maximum number of model summaries to return. Default: 50. Maximum: 100."Input schema / properties / status / descriptionPrevious value: -"Filter by build status. If not specified, all are returned."New value: +"Filter by build status. If omitted, models with all statuses are returned."list_gallery_photos4 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of photos in the response."New value: +"Maximum number of photos to return. Default: 50. Maximum: 100."Input schema / properties / offset / descriptionPrevious value: -"Number of matching photos to skip before returning the current page."New value: +"Number of matching photos to skip before returning the current page. Use nextOffset from a previous response to retrieve the next page."Input schema / properties / project / descriptionPrevious value: -"The building slug used for filtering, e.g., 'le-requin'. If not specified, photos for all buildings are shown."New value: +"Optional model project slug to filter photos, for example 'le-requin'. When omitted, returns photos from all gallery projects."Input schema / properties / tag / descriptionPrevious value: -"Category for photos taken inside the structure (the \"section\" field in the gallery manifest). Known values: overall, hull, deck, rigging, details."New value: +"Optional gallery section filter. Matches the manifest section field exactly. Known values: overall, hull, deck, rigging, details."list_model_slugs4 fields changedInput schema / properties / manufacturer / descriptionPrevious value: -"Filter by kit manufacturer (partial match, case-insensitive)."New value: +"Filter by kit manufacturer using a case-insensitive partial match."Input schema / properties / name / descriptionPrevious value: -"Full or partial name of the building to search for slug. Search is case insensitive and looks for an occurrence both in the name and in the slug itself. If not specified, all models are returned."New value: +"Full or partial model name to search for. Matching is case-insensitive and checks both the model title and slug. If omitted, all models are considered."Input schema / properties / scale / descriptionPrevious value: -"Filter by model scale (exact match, e.g., '1:64')."New value: +"Filter by exact model scale, for example '1:64'."Input schema / properties / status / descriptionPrevious value: -"Filter by build status."New value: +"Filter by build status. If omitted, models with all statuses are considered."search_content2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Максимальное количество результатов (на каждую категорию)."New value: +"Maximum number of results to return for each result type. Default: 20. Maximum: 50."Input schema / properties / query / descriptionPrevious value: -"Search query for full-text search across build logs and articles."New value: +"Search terms for broad discovery across build-log metadata and tutorial metadata. Every term must match across the searchable fields of one result."search_tutorial_content2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Maximum number of results."New value: +"Maximum number of matching tutorials to return. Default: 20. Maximum: 50."Input schema / properties / query / descriptionPrevious value: -"Search query for full-text search within educational article content."New value: +"Search terms for educational tutorial title, summary, and full article content. Every query term is evaluated by the tutorial text-matching logic."get_build_detailsget_project_statusget_tutorial_by_titleget_tutorialslist_buildslist_gallery_photoslist_model_slugslist_tutorial_taxonomysearch_contentsearch_tutorial_contentAn MCP connector for Adobe After Effects. Real, editable layers and keyframes, not scripts.
One connector for 15,000+ MCP servers plus your team's private MCPs, from any AI client.
See what an MCP connector can do for your business, get a scenario map, book a consultation.
Add one secure layer between your agents and this server.
