Skip to main content
Glama

shoot_day_plan

Idempotent

Turn up to 12 planned videos into realistic shoot days: bundled by place, split evenly (max 3 shoots, 8 h), with set-up, breaks, lunch, timed schedule, equipment list, checklist and optional .ics files. Returns: JSON with language, rules, summary, days, warnings, coverage. PAID: 0.03 USDC per call (USDC on eip155:8453, x402 v2). Requires an x402-capable MCP client that attaches the payment in _meta["x402/payment"] (e.g. createx402MCPClient from @x402/mcp). Without a payment this tool returns a "payment required" result and charges nothing. NOTE: Rule-based, German labels, no AI model. Do not send names or other personal data: only video titles, place labels and equipment. Results are kept 30 days like all results. Nothing is written to a calendar; calendar files are text you import yourself.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "shoots": "<shoots>"
    },
    "name": "shoot_day_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
shootsYes
languageNode (default) or ende
first_dateNoOptional YYYY-MM-DD of the first shoot day; adds calendar files. Further days follow every second day.
start_timeNo09:00
break_minutesNo
lunch_minutesNo
max_day_minutesNo
max_shoots_per_dayNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / shoots / items / properties / equipment / items / pattern
      Previous value: -"^[^\\u0000-\\u001f\\u007f]+$"New value: +"^[^\\x00-\\x1f\\x7f]+$"
    • changedInput schema / properties / shoots / items / properties / location / pattern
      Previous value: -"^[^\\u0000-\\u001f\\u007f]+$"New value: +"^[^\\x00-\\x1f\\x7f]+$"
    • changedInput schema / properties / shoots / items / properties / title / pattern
      Previous value: -"^[^\\u0000-\\u001f\\u007f]+$"New value: +"^[^\\x00-\\x1f\\x7f]+$"
  2. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
      +  "default": "de",
      +  "description": "de (default) or en",
      +  "enum": [
      +    "de",
      +    "en"
      +  ],
      +  "type": "string"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: discloses the 0.03 USDC per-call price, the payment channel (eip155:8453, x402 v2), the unpaid-call behavior, the 30-day result retention, that results are rule-based German labels with no AI model, and that no calendar is written. The openWorldHint/idempotentHint annotations alone would not tell an agent any of this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the capability in the first clause, then payment, then the privacy/behavioral notes in descending importance. Dense but every block earns its place; nothing is padded or restated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 names the return shape (JSON with language, rules, summary, days, warnings, coverage) and covers cost, retention and privacy for a complex 8-parameter tool. The day/warning object structures are not characterized, which is the only real gap.

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?

With only 25% schema description coverage, the description compensates by naming the effect of several parameters: 12-video cap, grouping by place, max 3 shoots per day, 8h day, breaks and lunch, and first_date adding .ics files. start_time, language and the recipe/media_type interplay remain undocumented in prose, so it is strong but not complete.

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 transformation (planned videos → realistic shoot days) with the concrete mechanics: bundling by place, even split, max 3 shoots per 8h day. Outputs are enumerated (set-up, breaks, lunch, schedule, equipment list, checklist, optional .ics), so an agent can distinguish it from video_project_plan or shoot_location_check without opening the 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 clear preconditions: needs an x402-capable MCP client that attaches payment in _meta["x402/payment"], otherwise returns 'payment required' and charges nothing; and explicitly forbids sending names or personal data, narrowing inputs to titles, place labels and equipment. It does not name a sibling it is preferred over, so it stops short of full when/when-not routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources