Skip to main content
Glama
Sign In

Glushkov Modelling MCP

by com.glushkov-modelling
OverviewDiscussionsAdmin

List gallery photos

list_gallery_photos

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.

Input Schema

NameRequiredDescriptionDefault
tagNoOptional 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').
limitNoMaximum number of photos to return. Default: 50. Maximum: 100.
matchNoHow 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
offsetNoNumber of matching photos to skip before returning the current page. Use nextOffset from a previous response to retrieve the next page.
projectNoOptional model project slug to filter photos, for example 'le-requin'. When omitted, returns photos from all gallery projects.
tagFacetNoOptional 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / match
      Added 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"
+}
    • addedInput schema / properties / tag / anyOf
      Added value: +[
+  {
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "items": {
+      "minLength": 1,
+      "type": "string"
+    },
+    "maxItems": 20,
+    "minItems": 1,
+    "type": "array"
+  }
+]
    • changedInput schema / properties / tag / description
      Previous 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')."
    • removedInput schema / properties / tag / type
      Removed value: -"string"
    • addedInput schema / properties / tagFacet
      Added 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"
+}
  2. Changed4 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of photos in the response."New value: +"Maximum number of photos to return. Default: 50. Maximum: 100."
    • changedInput schema / properties / offset / description
      Previous 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."
    • changedInput schema / properties / project / description
      Previous 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."
    • changedInput schema / properties / tag / description
      Previous 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."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Glushkov Modelling MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources