video_project_plan

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

The description adds substantial context beyond the annotations: it explains that the plan is rule-based, calculated on the server from built-in rules and data, stateless, not AI-based, and does not write to any calendar. It also discloses privacy constraints about sending roles, areas, and company town only, and clarifies that reel durations are suggestions that can be overridden.

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 mostly front-loaded, with the core purpose and outputs stated first before operational notes. Some repetition exists between the 'LOCAL' note and the 'Rule-based' note, but the information is relevant and not padded.

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 complex 21-parameter planning tool with no output schema, the description does a good job listing return fields and behavioral constraints. However, it leaves important parameter meanings and alternative-tool guidance unaddressed, so an agent would still need to infer much of the invocation logic from the schema.

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?

With 21 parameters and only 19% schema description coverage, the description compensates only partially by mentioning goal, trade, town, shoot window, reels, roles/areas, language, and overridable durations. Many parameters such as holiday_region, review_rounds, client_feedback_days, lunch_minutes, latitude, longitude, and reel_count_min/max receive no semantic explanation in either the schema or the description.

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 that this tool produces a complete video project plan, naming concrete outputs such as reel ideas, a shoot day, call sheet, sun times, and post-production to delivery. It is specific and goes beyond the tool name, though it does not explicitly differentiate itself from siblings like shoot_day_plan or content_month_plan.

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 phrase 'One video job in one call' implies a full-project planning use case, but the description never states when to choose this tool over alternatives such as shoot_day_plan. It also gives privacy constraints but no explicit when-not-to-use guidance or sibling routing.

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