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

With no annotations, the description carries the full burden of behavioral disclosure. It explains what happens on a new-game call (receiving sessionId, crew, capital, target list) and on a state re-read. However, it does not disclose important side effects such as whether starting a new game abandons an existing game, whether repeated calls without a session_id create multiple games, or any rate or resource limits. The strategy tip adds context but not behavioral transparency.

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 well organized into context, invocation modes, a rules link, and a strategy tip. The essential instructions are clearly stated and the flow is logical. It is slightly longer than strictly necessary due to the introductory game context and strategy tip, but all content is relevant and no filler wastes the agent's attention.

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 simple single-parameter tool with no annotations and no output schema, the description covers the required invocation details and summarizes the new-game response contents. It lacks a detailed description of what a 'current state' re-read returns and does not mention edge cases like starting over or error handling, but the full rules link and explicit call modes make it reasonably complete.

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 schema has a single optional session_id with 0% description coverage, so the description is the only source of parameter semantics. It fully explains the parameter: omitting it starts a new game, passing it re-reads the state. This completely compensates for the schema gap and leaves no ambiguity about how to use the parameter.

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 resource and actions: it starts a new Syndicate game when called without a session_id and re-reads the current state when called with one. The verbs 'start' and 're-read' are specific, and the game resource is unambiguously described. It does not explicitly differentiate from sibling tools, so it falls short of a 5.

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 provides explicit invocation conditions: 'Call with NO session_id to start a new game' and 'Call with your session_id to re-read the current state any time.' This gives clear context for both modes. It does not, however, exclude sibling tools or state when not to use this tool, leaving that implicit.

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