Skip to main content
Glama
Sign In

Shootika

by com.shootika
OverviewDiscussionsAdmin

List scenes

list_scenes
Read-only

Lists the store's scenes, 24 per page, each with its id, kind, model, style, pose, status and a preview image. An on_model scene is a model in a style and pose; a lifestyle scene is a placement scene, the product alone in a style (model null, pose Placement). Use it to find a ready scene id for a shoot: pass kind lifestyle for a product whose shoot_routes include placement. Filter by kind, model_id, style, pose or status. The result carries page, page_size and total; when more pages exist, call again with page + 1.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_scenes"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoon_model (the default) for a model in a style and pose; lifestyle for the placement scenes, the product alone in a style, for a product whose shoot_routes include placement. No model_id is needed for lifestyle.
pageNoPage number, starting at 1. Omit for the first page.
poseNoOnly scenes in this pose (a name from a model's poses, such as Front).
styleNoOnly scenes in this style (key from list_styles).
statusNoOnly scenes in this state. Shoots need a ready scene.
model_idNoOnly scenes cast with this model (id from list_models).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "on_model (the default) for a model in a style and pose; lifestyle for the placement scenes, the product alone in a style, for a product whose shoot_routes include placement. No model_id is needed for lifestyle.",
+  "enum": [
+    "on_model",
+    "lifestyle"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the safety profile (readOnly, non-destructive, closed world); the description adds the behavior an agent actually needs: 24 items per page, the page/page_size/total result envelope, and the 'call again with page + 1' continuation rule. With no output schema, that return-shape disclosure is substantial added context, not repetition.

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?

Three sentences, front-loaded with the resource and pagination before the scene-type definitions and routing advice. It is efficient overall, though the on_model/lifestyle definitions partially duplicate what the kind enum description already says.

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?

For a read-only list tool with no output schema, the description covers result fields, page size, the pagination continuation rule, and how to pick the right kind — everything needed to call it correctly and iterate over results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter descriptions already document kind defaults, pose sources, and style keys. The description mostly restates that in prose ('Filter by kind, model_id, style, pose or status') and repeats the kind semantics nearly verbatim, adding no format or edge-case detail beyond 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 ('Lists the store's scenes') and immediately scopes it with page size, returned fields, and the two scene kinds. An agent can distinguish it from list_models, list_styles and list_shoots without opening any sibling schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear selection rule: 'Use it to find a ready scene id for a shoot: pass kind lifestyle for a product whose shoot_routes include placement,' and 'Shoots need a ready scene.' It never names the sibling to use instead (e.g. list_shoots or get_shoot) for cases this tool doesn't cover, so it stops short of explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Shootika 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