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 10 tools
The tool set is mostly distinct, with clear separation between model catalog access, status, details, tutorial browsing, taxonomy, and content search. Some potential confusion exists between get_tutorials and get_tutorial_by_title or between search_content and search_tutorial_content, but the descriptions carefully cross-reference each other to mitigate ambiguity.
All tools follow a consistent verb_noun snake_case pattern: get_ for single-item retrieval, list_ for collection browsing, and search_ for discovery. Plural nouns for list operations and singular nouns for detail operations make the naming predictable and readable.
Ten tools is well-scoped for a read-only server covering model builds, gallery photos, tutorials, taxonomy, and search. Each tool has a distinct retrieval purpose, and none feels redundant or unnecessary for the stated domain.
The surface is quite complete for a read-only domain: model catalog browsing, details, status, slug resolution, gallery photos, tutorial taxonomy, tutorial retrieval, and both metadata and full-text search are all covered. The only minor gap is that gallery photos are browseable but not included in search_content, so cross-domain discovery skips gallery content.
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, section tags, and image metadata. Use this tool to browse gallery photos or filter them by model project and gallery section. Use get_build_details when the user needs vessel background, technical notes, or build-log content for the related model. Known section tags are: overall, hull, deck, rigging, details. Results are ordered 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. If project does not identify a gallery project, returns a not-found result.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional gallery section filter. Matches the manifest section field exactly. Known values: overall, hull, deck, rigging, details. | |
| limit | No | Maximum number of photos to return. Default: 50. Maximum: 100. | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses read-only status, pagination behavior (nextOffset, hasMore), response fields, ordering by gallery order, and edge cases (empty array, not-found result). This is more than enough for an agent to understand what happens when invoking the 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 longer than average but well-structured: read-only declaration, main return value, usage, sibling routing, tags, ordering, response fields, pagination, and edge cases. Each sentence serves a purpose, though a slight tightening of the pagination wording could improve it.
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 read-only list tool with four parameters, no output schema, and no annotations, the description provides comprehensive context: output shape, pagination controls, ordering, filter values, and failure/empty behavior. Nothing critical appears missing for an agent to invoke it 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 coverage is 100%, so the baseline is 3. The description adds meaningful value on top of the schema: it enumerates known tag values, gives an example project slug ('le-requin'), explains offset semantics in terms of nextOffset from a previous response, and clarifies behavior for unmatched or invalid project filters.
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 begins with 'Read-only. Returns a paginated list of gallery photo summaries' – a specific verb and resource, followed by the exact fields returned (captions, URLs, references, tags, metadata). It also explicitly contrasts itself with get_build_details, so an agent can identify unique purpose without ambiguity.
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 states directly when to use this tool ('browse gallery photos or filter them by model project and gallery section') and when to use a sibling instead ('Use get_build_details when the user needs vessel background, technical notes, or build-log content'). It also provides known section tags that act as filter guidance.
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 tutorial categories, tags, and difficulty levels currently used by educational articles, together with the number of tutorials assigned to each value. Tags include ACF metadata: facet (component | technique | material | context), status (active | deprecated), and publicFilter (whether the tag is shown in UI filters). Use includeDeprecated=true to include deprecated tags for audit purposes (excluded by default). Use groupByFacet=true to receive tags grouped by their facet type instead of a flat list. Use this tool before calling get_tutorials with tag, category, or level filters when the exact available value is unknown. Use get_tutorials to retrieve tutorials matching selected taxonomy values. This tool returns taxonomy metadata, not tutorial articles. Values are ordered by tutorial count in descending order. If no tutorials are available, returns empty categories, tags, and levels arrays.
| Name | Required | Description | Default |
|---|---|---|---|
| groupByFacet | No | When true, returns tags grouped by facet type (component, technique, material, context, unclassified) instead of a flat sorted list. | |
| includeDeprecated | No | When true, includes tags with status='deprecated' in the result. Default: false (only active tags are returned). |
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 discloses read-only behavior, default exclusions (deprecated tags excluded by default), ordering (by tutorial count descending), and empty-result behavior. It also explains the meaning of tag metadata (facet, status, publicFilter). This is strong behavioral disclosure, though it doesn't mention pagination or rate limits, which are less relevant for a taxonomy list.
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 detailed but every sentence earns its place: it covers scope, metadata semantics, parameter behavior, usage context, and edge cases. It is front-loaded with the read-only nature and core return value. Slightly long, but not bloated given the complexity of the taxonomy metadata.
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 read-only list tool with two optional boolean parameters and no output schema, the description is complete. It explains what is returned, how values are ordered, what the tag metadata means, how parameters affect output, and what happens when no tutorials exist. An agent has everything needed to call it 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%, so the schema already documents both parameters. The description adds context by explaining the purpose of includeDeprecated ('for audit purposes') and groupByFacet ('grouped by their facet type'), but it doesn't add significant new meaning beyond the schema. 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 ('Returns') and resource ('tutorial categories, tags, and difficulty levels'), and explicitly distinguishes itself from get_tutorials ('This tool returns taxonomy metadata, not tutorial articles'). It also names sibling tools and clarifies scope, so an agent can tell it apart from get_tutorials and search_tutorial_content 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 says when to use this tool: 'Use this tool before calling get_tutorials with tag, category, or level filters when the exact available value is unknown.' It also names the alternative (get_tutorials) and what it does instead. This is clear, actionable 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. 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.
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.
