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

Annotations already state readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: parameter-dependent result scoping, specific quest IDs like gates-pr and fireplace-pr with posted-price payment semantics for accepted PRs, and the human merge boundary. It does not discuss pagination, return shape, or rate limits, but it provides solid operational context.

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 compact and front-loads the resource scope before parameter behavior and delivery instructions. Every fragment carries information, but the telegraphic style and cryptic closing phrase 'Labor pricing, never a reading' reduce readability.

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?

Given the obscure tool name, no title, two parameters with zero schema descriptions, and no output schema, the description does substantial work: it explains the board's purpose, parameter-driven scoping, specific bounty/payment cases, and how to submit work. It still leaves the returned bounty/game object structure and some workflow edge cases unstated, so it is strong but not fully 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: quest_id absent means all bounties plus games, game narrows with an example ('gates'), and quest_id present means one bounty. It does not spell out whether game and quest_id can be combined or the exact quest_id format, so it stops short of full parameter semantics.

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 the resource as the board of paid work/bounties on the store's games and explains the two retrieval modes. It is specific enough to distinguish this from a submission action by directing delivery to play(action='munus.submit'). However, the obscure tool name 'munus' and metaphorical opening mean the core 'list bounties' purpose is implied rather than stated with a direct verb.

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 clear usage rules for the two parameters: no quest_id returns every bounty plus games, game narrows the set, and quest_id returns one bounty. It also points to the next step for delivery via play(action='munus.submit') and says to call unsigned first for the text to sign. It lacks explicit when-not-to-use guidance or comparison to sibling listing tools.

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