delegations_incoming

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

With no annotations, the description carries full burden and does so extensively: it discloses paging limitations ('no automatic paging', 'one bounded GET'), data size limits (100 rows, 256 KiB), truncation reporting, refusal of oversized records, and explicit statements about no currency conversion or card-delegation inference. This is rich behavioral 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 verbose and repetitive. Statements like 'One bounded GET; no automatic paging' and 'Makes one logical GET request Does not auto-fetch continuation pages' are redundant. The text is a wall of loosely connected clauses with punctuation issues, lacking clear structure and front-loading.

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?

The description covers behavioral limits thoroughly but leaves gaps: it does not explain parameter semantics or describe the return format (no output schema). While it hints at fields (amount strings, rental fields, nullable dates), it does not provide enough for an agent to confidently construct a correct call without additional inference.

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 compensate. However, it does not explain individual parameters like player, limit, sort, order, or offset. It only generically mentions 'required inputs reflect tool policy' and 'other declared filters are forwarded as supplied' without specifying which parameters are filters or their meanings.

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 states a specific action: 'Read incoming SPSP delegation records' and clarifies that each returned player is a delegator to the requested player. This distinguishes it from siblings like delegations_outgoing and delegation_to_target, which are clearly different directions or targets.

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 implies usage for incoming delegations but does not explicitly name alternatives or conditions for when to use this tool versus delegations_outgoing or delegation_to_target. It mentions matching 'corresponding outgoing and pairwise reads' but gives no clear when-to-use guidance.

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