game_workflow

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

No annotations are provided, so the description carries the full behavioral burden. It discloses a few traits (retry via resume rather than a new plan, review_images returns actual images), but says nothing about permissions, side effects, whether plans are persisted, or the cost/mutation profile of a gateway that can invoke any action. For a tool with this much latent power, that is a serious gap.

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 text is a run-on block with sentences broken mid-clause by line wraps ('a saved plan containing\nrecipe/custom/source/template/interactive items'), and mixes workflow instructions with feature notes without front-loading the core purpose. Several sentences do not earn their place against the ambiguity they leave.

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 gateway with no annotations, no output schema, zero schema description coverage, and a free-form 'values' parameter, the description omits the essentials: how actions are discovered, how the 'values' payload maps to the routed tool, and what a response looks like. Given the complexity of routing to ~50 sibling tools, it is under-specified.

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 0% and there are four parameters (query, action, values, operation). The description only obliquely hints at 'action' ('exact action name') and 'operation' ('search/describe'), and never explains 'query' or the free-form 'values' object, which is the payload that drives every routed call. It does not compensate for the coverage gap.

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 identifies this as a single entry point for game-development tasks and a gateway that exposes 'existing tools ... by their exact action name,' which hints at routing behavior. But 'One entry for a game-development task' does not state a concrete verb+resource, and it never clarifies what the tool itself does versus what the sibling tools do. It is only partially distinguishable from the many specific siblings listed.

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?

It gives some sequencing advice ('Start with context and find_assets/find_designs, then produce a saved plan...', 'Retry with resume, not a new plan') and tells the agent to 'Search/describe only the capability needed.' However, it never says when to call game_workflow instead of the concrete siblings (e.g. build_asset, compose_scene, resume_workflow), and it references tools (find_assets, find_designs, review_images) that do not appear in the sibling list, leaving the routing decision ambiguous.

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