motion_projects

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

No annotations are provided, so the description carries the burden of disclosing behavioral traits. It only restates the operation enum from the schema without elaborating on side effects, prerequisite permissions, return values, or behavioral differences across operations. This adds minimal value beyond the schema.

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 a single, well-structured sentence that is easy to parse and front-loads the tool's purpose. It is appropriately concise, though this brevity comes at the cost of substance.

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?

This is a multi-operation tool with seven parameters and no output schema, yet the description provides only a high-level overview. It fails to explain the purpose of each operation, when to use them, or what the return value looks like, making it incomplete for an agent to select and invoke correctly.

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?

Schema coverage is 100% with detailed descriptions for each parameter, including operation-specific requirements (e.g., 'required for create'). The description provides no additional parameter semantics, so the baseline score of 3 applies.

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 identifies the tool as managing Motion projects and enumerates the three supported operations (create, list, get). This distinguishes it from sibling tools focused on tasks, users, etc., though the verb 'Manage' is somewhat generic.

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 'Manage Motion projects' provides an implied usage context, indicating this tool is for project operations. However, there is no explicit when-to-use guidance or mention of alternatives (e.g., motion_tasks for tasks), making it adequate but not explicit.

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