Skip to main content
Glama

prepare_video_batch

Prepares batches of 1–50 videos with destinations and comments without sending them, returning body text and job IDs for later posting.

Instructions

動画・投稿先・コメントを1〜50件まとめて準備する。送信せず、各本文とjob_idsを返す。

Input Schema

NameRequiredDescriptionDefault
videosYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations flag readOnlyHint=false and idempotentHint=false, and the description adds the critical behavioral facts annotations cannot convey: nothing is transmitted and the call returns each rendered body plus job_ids. That materially tells the agent this is a non-side-effecting-in-the-world preparation step whose output must be carried forward. It still omits what happens on partial validation failure across the batch.

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?

Two sentences, no filler, and the most decision-relevant fact (batch of 1–50, does not send) is front-loaded. Nothing could be removed without losing information.

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 an output schema present, the description is not obligated to detail return values, and it still summarizes them (bodies and job_ids). Combined with the batch limit, an agent has enough to call it correctly; only error/partial-failure behavior and the follow-up send step are left unstated.

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?

The schema itself documents each nested field (video_path as absolute MP4 path, collection_id, optional comment), so the description needn't repeat them. What the description adds beyond the schema is the 1–50 item bound on the videos array, which appears nowhere in the schema's constraints — a genuinely valuable addition for the sole parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (まとめて準備する / prepare in batch) and its resource (videos, destinations, comments), plus the batch size range 1–50. This clearly separates it from the single-item prepare_video and from the sending tools, though it never names those siblings explicitly.

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

Usage Guidelines3/5

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

"送信せず" (does not send) implies the two-step prepare-then-send flow and rules this tool out as the sender, which is useful implied guidance. However, it never says to use send_prepared_videos/send_prepared_videos next, nor when to prefer prepare_video over the batch variant, so the agent must infer the sequencing.

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