Set arcade settings

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

Annotations do not carry much behavioral weight, so the description bears the burden — and it does well: it warns that changing scoreSort changes which run counts as a player's personal best, and that this must happen before play. It also clarifies that scoreLabel is display-only. It could add more about auth requirements or response behavior, but the core irreversible consequence is disclosed.

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 long enough to be useful but every sentence earns its place: what the tool does, which parameter matters, why the default matters, and why it lives where it does. The most important information is front-loaded in the first sentence.

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 three-parameter configuration tool with no output schema, the description covers purpose, parameter semantics, timing, and ownership sufficiently. It could mention what the caller should expect as a result or whether the call is idempotent, but those are minor gaps given the strong schema and narrative context.

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 coverage is already 100%, but the description adds real value beyond it: it identifies scoreSort as the critical parameter, explains asc/desc with concrete use cases like speedruns and stroke counts, and clarifies that scoreLabel is purely presentational. This transforms schema definitions into actionable decision guidance.

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 opens with a specific verb and resource: 'Configures the Arcade SDK leaderboard for a game you own.' It clearly distinguishes this from generic game configuration and from SDK-side behavior by noting it lives on the owner path. No sibling tool covers leaderboard settings, so the scope is unambiguous.

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 gives explicit guidance: set scoreSort once before anyone plays, and use this owner-path tool rather than the SDK so games cannot redefine leaderboard semantics mid-season. This clearly communicates when to invoke the tool and why the alternative location is intentionally excluded.

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