FleetQ

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

Annotations are empty, so description carries full disclosure burden. It mentions 'continuous & one-shot' but doesn't explain their behavioral differences, lifecycle states, or side effects (e.g., what happens to running executions when pausing, whether archive is reversible, what trigger_run returns). No mention of permissions, rate limits, or asynchronous behavior.

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?

Single dense sentence parenthetically listing all actions. While not verbose, the structure impedes readability—it is a wall of text without breaks, bulleted lists, or logical grouping (CRUD vs lifecycle vs scheduling vs runs). Every word serves a purpose, but the presentation could be better structured for an AI parsing context.

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?

Given 16 parameters (including nested schedule objects), complex entity relationships (projects reference workflows/crews), and no output schema, the description is inadequate. It omits the project lifecycle flow, the relationship between projects and runs, scheduling mechanics, and expected return values. The 'required' array in schema appears incorrect (listing mutually exclusive params as jointly required), which the description fails to clarify.

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 enjoys 100% description coverage, establishing a baseline. The description attempts to add value by mapping actions to their typical parameters (e.g., 'create (name, type, workflow_id)'), which helps clarify the polymorphic interface. However, it uses inaccurate shorthand ('name' instead of actual param 'title'; 'cron' instead of 'cron_expression'), potentially misleading the agent about valid JSON keys.

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?

Clearly states 'Manage projects (continuous & one-shot)' and enumerates 14 specific actions (list, get, create, update, activate, pause, resume, restart, trigger_run, archive, schedule, schedule_nlp, run_list, run_get). Verb and resource are specific. However, it fails to differentiate what constitutes a 'project' versus sibling entities like 'workflow' or 'crew' (which appear as parameters), leaving conceptual ambiguity.

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?

Lists available actions but provides no guidance on when to use this tool versus workflow_manage, crew_manage, or agent_advanced. No mention of prerequisites (e.g., needing an active workflow before creating a project), action sequencing, or state transitions. The description is purely a capability list without strategic usage context.

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