syndicate_move

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

With no annotations provided, the description carries the full burden of behavioral transparency. It discloses key behaviors: advancing the day, resolving events, returning new state, the one-order-per-crew-member limit, and the effect of an empty orders list. It does not mention potential side effects such as turn consumption or failure modes, but covers the primary behavioral aspects.

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 concise overall but contains slight redundancy: the orders structure and the empty orders behavior are each mentioned twice. It could be tightened into a more structured format, but it remains readable and directly to the point without unnecessary filler.

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?

The description covers the input format, action types, the special empty-orders case, and the source for targetId. It gives a high-level expectation of the output ('events + new state'). It does not detail error handling or additional constraints, but for a game move tool the provided context is adequate for an agent to use it 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?

The description fully explains both parameters. For 'orders', it specifies the list structure (agentId, targetId, actionType) and enumerates all valid actionType values. For 'targetId', it directs the user to obtain valid values from syndicate_state lists. 'session_id' is implied as the game session identifier. The schema itself has no descriptions, so this textual coverage is comprehensive.

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 the tool's specific function: submitting one day of orders to the Syndicate game and receiving the resolved day with events and new state. It uses a specific verb ('Submit') and distinguishes the resource ('one day of orders'). While it doesn't explicitly contrast sibling tools, the purpose is unambiguous and self-contained.

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 description explains what the tool does but does not explicitly state when to use it versus alternatives like syndicate_state or syndicate_leaderboard. It implies usage (for submitting orders) and covers edge cases like empty orders (passing the day), but lacks direct when-to-use or when-not-to-use guidance relative to sibling tools.

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