flux_host

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

With no annotations, the description carries the burden. It usefully discloses the waiting behavior, which is a key behavioral trait. However, it does not clarify whether the call blocks indefinitely, what happens on timeout, what is returned, or whether hosting requires authentication, leaving meaningful gaps.

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?

A single, front-loaded sentence conveys the core purpose and key behavior with zero filler. Every word earns its place.

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 one-parameter tool with no output schema or annotations, the description gives the essential purpose and wait behavior. However, the lack of information about return values, timeout behavior, or how to proceed after an opponent is found leaves the tool only partially complete for an agent.

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 description coverage is 100%: board_size is documented as '5, 7 or 9 (default 7)'. The description adds only a redundant default-size mention and no additional meaning, so it meets the baseline without exceeding it.

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 a specific action ('Host'), a resource ('new open room'), and the expected outcome ('wait for an opponent'), with a board-size default. It strongly differentiates from siblings like flux_join and flux_rooms.

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 phrasing 'Host a new open room' implies this is for creating a new match rather than joining an existing one, and the sibling list confirms alternatives exist. However, it does not explicitly say 'use flux_join to join' or state when not to use this tool, so it stops short of full guidance.

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