delegations_outgoing

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses no auto-paging, no currency conversion or card-delegation inference, local row and byte limits, truncation reporting, and refusal of oversized records without partial fields. This is far more behavioral context than most tool descriptions provide.

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 front-loaded with the core purpose, but it becomes verbose and redundant. 'One bounded GET; no automatic paging' and 'Makes one logical GET request Does not auto-fetch continuation pages' say the same thing twice, and the odd 'Two pages of two matched the first four records' sentence adds confusion rather than value.

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 many operational expectations: paging behavior, size limits, truncation, and preservation of data types. However, it omits paging mechanics (how to use offset/limit to traverse results) and leaves the meaning of sort/order ambiguous, which an agent would need for correct invocation of this five-parameter tool.

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 0%, so the description must compensate, but it only meaningfully clarifies 'player' and 'limit'. Sort, order, and offset are left uninterpreted; 'sort effectiveness is unmeasured' and 'other declared filters are forwarded as supplied' do not explain their semantics or expected formats. This is a significant gap for a five-parameter tool.

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 uses a specific verb ('Read'), names the exact resource ('outgoing SPSP delegation records'), and clarifies the directionality: 'each returned player is a recipient of the explicitly requested player.' This clearly distinguishes it from sibling tools like delegations_incoming without needing to open their schemas.

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 intended use is implied by the purpose statement: call this when you need outgoing delegation records for a given player. However, it does not explicitly state when not to use it or name alternative tools such as delegations_incoming, so guidance is present but not fully developed.

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