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

With no annotations, the description takes the full burden: it discloses GET semantics, nullability, JSON string wire types, no continuation-paging, array limits, truncation reporting, and refusal of oversized records. This is a comprehensive behavioral profile.

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?

Purpose is front-loaded, and each subsequent sentence conveys a distinct behavioral or limitation fact. Some boilerplate lines (e.g., 'required inputs reflect tool policy') could be trimmed, but the structure is largely efficient.

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 one-parameter read-only tool with no output schema, this description covers request type, paging behavior, row/size limits, truncation, and nullability—enough to call correctly. It does not detail error structures, but that is not mandatory without an output schema.

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 the description adds little about 'username' beyond 'explicit' or the vague 'required inputs reflect tool policy'. The phrase about 'other declared filters' is misleading given additionalProperties=false in the supplied schema.

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 verb+resource ('Read the existing battle queue records') scoped to a username, and explicitly excludes join/submit actions, distinguishing it from any write-flavored siblings.

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 clearly says this does NOT join a queue or submit a team, but it never names alternative battle tools (e.g., battle_status) or gives a decision rule for when to use this tool instead.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses error behavior for unknown IDs, refusal of oversized results, no auto-fetching of continuation pages, local row/size limits with truncation reporting, and preservation of wire types. This is exceptional transparency for a tool.

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 but information-dense, with the purpose front-loaded. However, there is redundancy ('Oversized results are refused without dropping rounds or player data' vs later 'Oversized records are refused without partial fields') and a vague sentence about 'Required inputs reflect tool policy' that could be tightened.

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 a single parameter and no output schema, the description covers many operational details (error strings, size limits, wire types, no pagination) that an agent needs. It hints at response contents (details, settings, rewards) but could be more explicit about the overall response structure, though the absence of an output schema makes that less critical.

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. It does: it defines the ID as a 'queue transaction ID' and clarifies that either the captured opponent queue ID or the original works. This adds meaning beyond the bare string schema, though it could be more explicit about format.

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: 'Read a battle result by explicit queue transaction ID.' It clearly distinguishes the tool from battle_queue and battle_status by focusing on results and the input type. The added note about captured opponent queue IDs further clarifies scope.

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 reading battle results by queue ID) but does not explicitly compare with alternatives like battle_status or tournament_battles. It provides no exclusions or conditions for when to use this tool over siblings, leaving selection partly to inference.

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

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

With no annotations provided, the description carries full behavioral burden and does so impressively. It discloses the single logical GET request, no auto-pagination, HTTP 200 error body for unknown IDs, array limits, truncation reporting, and refusal of oversized records—all beyond what the schema could convey.

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, and every major claim supports correct invocation or interpretation. It is denser than necessary in places—especially the policy/requirements and 'other filters' phrasing—but compression would risk losing nuance.

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 tool with one parameter, no annotations, and no output schema, the description is exceptionally complete: it explains the ID source, the return shape, the error behavior, pagination behavior, and data limits. An agent can confidently invoke and interpret the tool from this description alone.

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% and the sole parameter 'id' is serviced by the description: it is an explicit queue transaction ID obtained from battle_queue. However, the boilerplate about 'other declared filters being forwarded as supplied' fits poorly with the schema's additionalProperties: false, so the parameter semantics are strong but slightly clouded by a mismatched generic statement.

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 'Read battle status by explicit queue transaction ID', giving a specific verb, resource, and selection mechanism. It further clarifies the ID comes from the sibling battle_queue tool and that team and settings are returned, which usefully distinguishes it from battle_result and other battle-related siblings.

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 tool states 'Obtain an ID from battle_queue', which implies the intended sequence and gives context for when to call it. It does not explicitly name alternatives such as battle_result or state when not to use it, so there are no clear exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it is exceptionally thorough: it covers caching behavior, absence of pagination, timeout and retry policy, memory/occupancy guards, projection semantics, null-vs-missing distinctions, and exact response shape. It also explains consequences like unresolved plot references remaining null and cached pages being replaced per username.

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 a single massive paragraph with no front-loaded summary; the core operation appears only after several sentences about plot references and caching. It contains extensive operational memory measurements, RSS ceilings, fixture details, and GC internals that are far beyond what an agent needs to select or invoke the tool, making it inappropriately sized and poorly structured.

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 no annotations and no output schema, the description must fully define inputs, outputs, and edge behavior, and it does: it states the response is exactly {player, cards[]}, enumerates every emitted card field, explains unknown-definition treatment, filter semantics, cache invalidation, timeout behavior, and pagination absence. Nothing needed to call the tool correctly is missing, even if the information is harder to find than it should be.

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, and it does for most parameters: cursor is a zero-based offset, limit defaults to 100 with max 100, staked enum values are defined, color/sub_type matching rules are specified, and min_land_base_pp has detailed null semantics. A few parameters like foil, edition, and card_set are only listed as 'local filters' without elaborating their exact accepted values or matching behavior.

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 eventually identifies the operation as 'Stream the projected collection returned by GET /cards/collection/{username}' and lists the returned card fields and available filters, so an agent can infer this is a card-collection query tool. However, the purpose is buried mid-paragraph behind implementation details like include_plot_references and logical GET counts, and no explicit sibling differentiation is given.

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?

There is no explicit when-to-use guidance, prerequisites, or named alternatives among the many sibling tools. The statement 'This is not complete holdings discovery' hints at a scope limit, and the edition-19 note about land_lineup_estimate gives parameter-level advice, but the description never tells an agent when to choose cards_collection over cards_find, cards_get_details, or other card tools.

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

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

No annotations were provided, so the description carries the full burden of behavioral disclosure. It thoroughly discloses input format constraints, error behavior ('repeated and bracketed parameters return an unable-to-parse error'), output fields ('player, uid, card_detail_id, xp, gold, edition, card_set, collection_power, market and rental fields'), and limits ('100-row and 256 KB limits'). It also clarifies semantic nuances: 'player is current-owner attribution, not donor provenance.' This is far beyond typical descriptions, though it doesn't mention auth requirements or rate limits, which are minor given the detail provided.

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 quite long but dense with essential information. It is front-loaded with the primary purpose and input format, followed by constraints and output fields. However, some sentences are wordy and could be tightened; for instance, the phrase 'real 2-ID and 3-ID requests returned exactly the requested UIDs in order' is a test result, not a specification, and could be a separate note. Still, every sentence adds value for correct usage, though the length may dilute impact.

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 tool's moderate complexity (one parameter, no output schema) and the complete absence of annotations, the description covers everything necessary for correct invocation: input format, error cases, output fields, semantics of the player field, and server limits. No output schema exists, so the explicit field list is crucial and provided. The description is fully sufficient for an agent to call this tool correctly and interpret the response.

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?

The schema has only one parameter 'ids' with just minLength: 1 and no description (schema description coverage 0%). The description compensates fully by explaining the expected format: 'a comma-separated string of full per-instance card UIDs' and explicitly listing invalid encodings. This gives the agent the exact meaning of the parameter beyond the schema. It does not specify a maximum length or example, but the format is clear enough for correct invocation.

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 exactly what the tool does: 'Look up per-instance card records through GET /cards/find.' It specifies the resource (card records) and the endpoint, and distinguishes itself from definition routes ('BCX is therefore promised for this per-instance route only; it is not a claim about definition routes'). It also implies a lookup, contrasting with many sibling market/land/player tools, making its purpose unmistakable.

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 explicitly tells the agent how to supply ids: 'one comma-separated string of full per-instance card UIDs' and states what is not valid: 'Repeated ids=, ids[]= and JSON-array encodings are not valid.' This is a clear usage guideline that prevents common errors. It also qualifies the scope ('per-instance route only') and explains the result is bounded by limits, giving context for when to use it. It does not explicitly name an alternative, but the distinction from definition routes and the presence of sibling cards_get_details etc. implies exclusion.

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

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

With no annotations, the description carries the full burden and exceeds it. It discloses the server's size-based refusal (1.17 MB upstream vs. 256 KB bound), that this refusal is this server's choice rather than an upstream rule, 24-hour caching, provenance reporting, and the absence of ownership fields. This is rich, honest 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 long but every sentence earns its place: the core action is front-loaded, then each subsequent sentence adds essential behavioral or data details. There is no fluff, repetition, or vague filler.

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?

Despite having no annotations and no output schema, the description is complete enough to call the tool correctly: it explains the required filter, enumerates the returned fields, describes caching and provenance behavior, and warns about the refusal condition. Nothing critical is missing for an agent to make an informed call.

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?

The input schema provides only `type` with `minLength: 1` and no description (0% coverage). The description fully compensates by explaining that `type` is a real upstream filter, illustrating with concrete row counts (107 vs 1101), and making clear that providing `type` is necessary in practice to avoid the size-based refusal.

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: 'List the card-definition rows returned by GET /cards/get_details.' It further distinguishes itself from siblings by explicitly stating it 'does not add per-instance ownership data,' clarifying what this tool is and is not among the many card-related endpoints.

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 clear operational guidance: provide `type` to make a filtered call because an unfiltered call is refused due to size. It also implies when not to use it by noting the route carries no BCX, donor, or account-attribution fields and adds no ownership data. However, it never names a specific alternative tool, so it stops short of 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that numeric ids silently return [], that donor and BCX fields are absent, that from_player/to_player are attribution fields rather than donor provenance, and that results are bounded by 100-row and 256 KB limits and not cached. This goes well beyond a basic read/list description.

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 dense but every sentence earns its place: purpose, id caveat, response fields, attribution nuance, endpoint semantics, and limits/caching. It front-loads the core operation before diving into caveats, and there is no filler or tautology.

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 tool with no output schema and no annotations, the description covers the operation, id semantics, response record fields, field interpretation, response size limits, and caching behavior. It is nearly complete, but the lack of guidance for `limit` and `transfer_types` leaves a small practical gap for an agent constructing a full request.

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 for undocumented parameters. It strongly clarifies the critical `id` parameter: 'id is a card UID, not a card_detail_id.' However, it does not explain the semantics or allowed formats of `limit` or `transfer_types`, leaving two of three parameters under-specified.

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: 'List the transfer records returned by GET /cards/history for one per-instance card UID.' It also explicitly contrasts itself with 'a card-definition lookup or an enumeration of history for a numeric card_detail_id,' which clearly differentiates it from sibling tools like cards_get_details and cards_collection.

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 clear when-not guidance: 'This route is a per-instance event lookup, not a card-definition lookup or an enumeration of history for a numeric card_detail_id.' It also warns that numeric ids 'silently returned []' versus real UIDs, which guides correct input selection. However, it does not explicitly name an alternative tool to use when the user needs card-definition lookup or numeric history enumeration.

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

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 that the response is a bare object with card_detail_id and text, that omitting the parameter yields an empty body, that the response has no BCX or attribution fields, that responses are cached for 24 hours, that provenance is reported, and that the tool returns the object unchanged without deriving attributes. This is comprehensive behavioral disclosure.

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 concise and front-loaded, leading with the main purpose and then adding important behavioral details. Each sentence provides distinct information: endpoint, response shape, parameter requirement, caching, provenance, and non-derivation. It is not overly verbose and avoids repeating schema information. Slightly longer than necessary but efficient.

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 simple tool with a single integer parameter and no output schema, this description is exceptionally complete. It covers the response structure, the required parameter behavior, caching behavior, provenance reporting, and clarifies that no additional derived attributes are included. An agent has all the information needed to call this tool correctly and interpret the response.

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. It states that card_detail_id is required and that omitting it returns an empty body, which adds behavioral context. However, it does not explain what the id represents or how it relates to other card identifiers across the API. While the field name is self-explanatory, the description adds minimal semantic value beyond the schema's basic integer type.

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 clearly states the tool's function: it gets the lore object for a given card_detail_id via a specific endpoint. It distinguishes itself from siblings by focusing on lore specifically, which is unique among the many list/sibling tools. The verb 'Get' and resource 'lore object' are specific and 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 implies when to use this tool (when you need a card's lore) but does not explicitly state alternatives or when not to use it. It mentions that it does not derive card attributes, which hints that other tools might be needed for that, but it does not name any sibling tool or provide explicit routing guidance. This is adequate but not explicit.

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

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

With no annotations, the description fully carries the burden, and it does so richly: it reveals the measured six-object array shape, the set names, the exact fields and types, the absence of BCX/donor/account fields, the 24-hour caching, provenance behavior, and that rows are returned unchanged. This goes well beyond a generic list description.

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 densely informative but not bloated; every sentence provides distinct value: the endpoint, the response shape, the excluded fields, the cache behavior, and the unchanged-return guarantee. The core purpose is front-loaded.

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 parameterless list endpoint with no output schema, the description is complete enough for an agent to call it correctly and interpret results. It covers what data is returned, what is absent, and how caching/provenance behave. Nothing critical is missing.

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?

The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, a score of 4 is appropriate, and the description compensates by detailing the output structure instead.

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 names a specific verb ('List') and resource ('pack metadata rows returned by GET /cards/pack_data_wax'), and then distinguishes the data from per-card or per-owner data. This makes the tool's purpose unmistakable and differentiates it from siblings like cards_get_details or cards_collection.

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 provides useful context by stating that this is WAX-bridge mint/burn metadata and not per-card or per-owner data, implying when it should be selected. However, it does not explicitly name alternative tools or state when-not-to-use it, leaving some inference to the agent.

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

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

With no annotations, the description carries the burden, and it does so well by disclosing that responses are cached for 24 hours, provenance includes the route and original fetch time, and rows are returned unchanged with no computed fields. It also gives concrete response-shape details such as a bare array and field names, which is meaningful behavioral context beyond a generic list description.

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 and then adds supporting behavioral details. The byte count and 'measured public response' phrasing are slightly more specific than necessary, but no sentence is filler and the structure is logical.

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 zero-parameter, no-output-schema metadata tool, the description is complete: it states the source route, the response shape and fields, caching behavior, provenance reporting, and what the tool does not do. Nothing essential for selecting or invoking this tool is missing.

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?

The tool has zero parameters, so the baseline is 4. The description compensates further by documenting the exact fields returned, which is the only semantic information an agent would need for this no-input 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 opens with a specific verb and resource: 'List the skin rows returned by GET /cards/skins.' It further clarifies scope by naming the exact fields in each row and explicitly noting that no BCX, donor, or account-attribution field is present, which helps distinguish it from player- or account-level tools.

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?

Usage context is implied rather than explicit: it is a raw metadata list, and the statement that it 'does not calculate availability or prices' signals when not to use it. However, it does not name alternatives or state a concrete condition for choosing this tool over siblings such as player_skins or cards_find.

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

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 extensively. It discloses error behavior for missing trx_id, the exact response fields, the fact that data and result are JSON-encoded strings returned without double-parsing, the semantic caveat that player is transaction attribution rather than donor provenance, the absence of BCX/donor fields, and the non-cached behavior. This is outstanding behavioral disclosure.

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 longer than average but every sentence carries useful operational information: endpoint mapping, failure mode, response shape, encoding quirk, field semantics, and caching behavior. It is front-loaded with its purpose. It could be slightly tighter by trimming the empirically-listed response fields, but given the lack of an output schema, the detail is justified.

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 tool with no annotations and no output schema, the description is remarkably complete: it covers required input, typical failure, response structure, data types, field semantics, absent fields, and caching. The main gap is the unclear semantics of the two optional parameters in the presence of a valid trx_id, and what happens for an invalid or non-existent trx_id.

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. It clearly explains that trx_id must be a real trx_id and is required, and it documents that username and card_detail_id alone are insufficient. However, it does not explain what username and card_detail_id do when combined with trx_id, nor their intended roles as optional parameters. This is partial compensation, leaving meaningful gaps.

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 clear verb and resource: 'Look up the transaction object returned by GET /cards/trx_lookup for a real trx_id.' It precisely identifies the tool's operation. It does not explicitly name or contrast a sibling tool like transaction_lookup, so it stops short of full sibling differentiation, but the 'single-transaction event lookup' wording helps separate it from cached metadata endpoints.

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 strong usage context: a real trx_id is required, and bare calls or calls with only username/card_detail_id fail with an HTTP-200 application error. It also states the route is a single-transaction event lookup and not cached as static metadata, implying when this tool is appropriate. However, it never names an alternative tool or explicitly says 'use X instead', so the when-not-to-use guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden and is exceptionally transparent: one logical GET, no continuation pages, no card metadata fan-out, no purchases/layout changes, oversized objects refused as a whole, array limits with truncation reporting, and no partial fields on refusal. It also notes preservation of original fields and relative asset paths.

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 main purpose is front-loaded, but the description is padded with redundancy: 'Oversized objects are refused as a whole' and 'Oversized records are refused without partial fields' say nearly the same thing, and 'One GET' appears twice. The 'observed slug selected three pages and 27 card slots' example is unexplained and adds noise, while the filter-forwarding note conflicts with a schema that has additionalProperties=false.

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 simple read with two string parameters and no output schema, the description covers the operational envelope well: request type, continuation behavior, size limits, refusal behavior, and field preservation. It lacks a concrete return-shape description and precise parameter semantics, but the behavioral coverage is strong enough for safe invocation.

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. It only restates 'by player and binder reference,' leaving the meaning, format, and valid values of player and binderRef unspecified. The generic sentence about required inputs and declared filters adds no concrete parameter guidance and does not match the actual two-parameter schema.

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: 'Read one public collector binder by player and binder reference.' This clearly identifies the tool's core action and distinguishes it from bulk or fan-out endpoints, though it does not explicitly name sibling tools.

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 implies usage context by stating this is a single GET with no auto-fetching, no fan-out, and no purchases or layout changes. However, it never explicitly states when to prefer this tool over alternatives such as collector_stickers or collector_config, nor when not to use it.

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

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

With no annotations provided, the description carries the full burden and goes well beyond a simple read statement. It discloses that the operation performs no purchase/claim, makes one logical GET request, does not auto-fetch continuation pages, refuses oversized configuration as a whole, and reports truncation for array responses limited to 100 rows and 256 KiB. This is extensive behavioral disclosure.

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 purpose and contains important behavioral caveats, but for a zero-parameter tool it is noticeably verbose. Sentences about 'required inputs' and 'other declared filters' are generic boilerplate that add little value here, and the 15 KiB note is of marginal usefulness. Some trimming or tightening would improve the structure.

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?

Despite having no output schema and no annotations, the description is nearly complete for an agent to invoke the tool correctly. It specifies what data will be returned, how to treat asset paths and nullable URLs, how to handle oversized responses, and what request behavior to expect. Nothing critical appears missing.

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?

The tool has zero parameters and 100% schema coverage, so the schema fully defines the input surface. The description adds general notes about required inputs and forwarded filters, but these are broad and not tied to any actual parameter. Per the zero-parameter baseline, a 4 is appropriate.

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: 'Read the complete public collector configuration,' followed by the concrete categories contained (page/slot limits, claim availability, shop metadata, featured accounts, cosmetic definitions). This clearly distinguishes the tool from its collector-related siblings like collector_binder, collector_stickers, and collector_player.

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 clear context for when the tool is appropriate: retrieving full public collector configuration and related metadata. It also clarifies a key boundary by stating that reading shop or claim metadata 'performs no purchase or claim.' However, it does not explicitly name alternative tools or state when-not-to-use this one relative to siblings.

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

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

With no annotations present, the description carries the full behavioral burden and does a thorough job: it covers one-GET semantics, refusal of oversized objects, no continuation-page fetching, row and byte caps, truncation reporting, and the non-guarantee of filter effectiveness. This is substantial behavior disclosure beyond the bare schema.

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 dense but efficient, starting with the core purpose and then adding behaviorally important constraints without filler or repetition. Each sentence contributes meaningful information.

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 one-parameter read tool with no output schema or annotations, the description is unusually complete: it covers limits, truncation, refusal behavior, and no auto-fetching. It could be slightly more complete by naming the return shape or not-found behavior, but it is not a significant gap.

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, but it does not explain what 'player' means beyond the schema's generic string type. It does add useful policy context around required inputs, but the single parameter's semantics are left mostly to inference from the tool name.

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: 'Read one player collector overview with binder summaries,' which is unambiguous and frames the tool's scope. It also distinguishes it from broader or mutation-style siblings by explicitly ruling out 'card metadata fan-out, purchases or layout changes.'

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 context by stating this is a single GET with no pagination, no purchases, no layout changes, and it cautions about forwarded filters. It does not name an alternative tool or explicitly say 'use X instead,' so it stops short of fully explicit 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses that it makes one GET request, does not fan out to card metadata, does not auto-fetch continuation pages, preserves original fields and relative asset paths, limits lists to 100 rows and 256 KiB, reports truncation in text and metadata, and refuses oversized records without partial fields. This is exemplary transparency for a read tool.

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 dense but every sentence earns its place, covering scope, behavior, limits, and error handling. It is front-loaded with the core purpose and then details constraints. It is longer than strictly necessary, but given the lack of annotations and the need to disclose behavioral traits, the length is justified. A 4 reflects that it is well-structured but not maximally concise.

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 tool has only one parameter, no output schema, and no annotations, the description is remarkably complete. It tells the agent what the tool does, what it does not do, its limits, truncation behavior, and refusal behavior. There is no output schema to explain return values, but the description mentions the observed four rows and metadata, which is sufficient context for a single-parameter read tool. Nothing critical is missing.

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 for the single required parameter 'player'. It does so by stating the tool reads the sticker-list route 'for one player', which clarifies that 'player' identifies the player whose list is read. It also notes that required inputs reflect tool policy and measured upstream requirements, adding context beyond the schema. However, it doesn't specify the exact format or constraints of the player identifier beyond the schema's minLength 1, so a 4 is appropriate rather than a 5.

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 clearly states the tool reads the full sticker-list route for one player, with a specific verb ('Read'), resource ('sticker-list route'), and scope ('for one player'). It distinguishes itself from siblings like collector_stickers_tradeable and collector_player by noting it is the full list route with ownership/trade/list flags and cosmetic metadata. However, it doesn't explicitly name a sibling alternative, so it falls just short of a 5.

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 provides clear context on when to use this tool: to read a player's sticker list, and it notes the route does not promise complete holdings and does not auto-fetch continuation pages, implying it is for a single bounded page. It does not explicitly name alternative tools for fetching more pages or complete holdings, so it lacks explicit exclusions, but the guidance is strong enough for an agent to select it appropriately.

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

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

With no annotations present, the description carries the full burder and delivers a strong behavioral profile: read-only semantics, one bounded GET, no auto-paging, 100-row/256 KiB limits, truncation reporting, and refusal of oversized records without partial fields. It clearly discloses that nothing is listed, transferred, or purchased.

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 purpose sentence is front-loaded, but much of the description repeats itself: paging/request limits appear twice and the size cap (100 rows / 256 KiB) is stated in multiple. The 'Two public featured accounts...' example and awkward phrasing ('data list are locally limited') add clutter without earning their place.

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 one simple parameter, no annotations, and no output schema, the description covers the essential operational context: safety, size limits, pagination, truncation behavior, oversized-record refusal, and the caveat about forwarded filters. It stops short of describing the exact returned data structure, so it is not fully complete, but it is more than sufficient for a single-parameter read 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?

The schema coverage is 0% and the only parameter, 'player', has no schema description. The description hints that 'player' identifies the subject ('one player's'), but never states the expected format (account name, ID, etc.) or how it maps to upstream requirements. The phrase 'Required inputs reflect tool policy...' adds no usable semantic detail.

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 and resource ('Read one player's tradeable collector stickers') and adds delimiting scope with 'This is not the for-sale route and does not list, transfer or buy anything.' This clearly distinguishes the tool from market/listing siblings even without naming them explicitly.

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?

There is a negative scoping statement ('not the for-sale route'), but no explicit 'use this when...' guidance or named alternatives like collector_stickers. The description implies usage based on the tool name rather than telling an agent when to choose it over its closest siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an unusually thorough job: it states the operation is a read ('Read'), that no prizes are claimed, that num_prizes is not recomputed, that it makes one logical GET request, that it does not auto-fetch continuation pages, that filters are forwarded as supplied without implied effectiveness, that results are locally limited to 100 rows and 256 KiB, that truncation is reported, and that oversized records are refused without partial fields. This is rich behavioral context beyond what any schema could convey.

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 dense but well-organized: it front-loads the core purpose, then covers behavioral constraints, then limits. Every sentence adds information. It is longer than ideal, but the density of useful behavioral detail justifies the length. The structure is logical: purpose → behavior → limits.

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 tool's complexity (6 parameters, no output schema, no annotations), the description covers a lot: read semantics, id vs conflict behavior, pagination, filtering caveats, size limits, and truncation reporting. It doesn't describe the return format or the exact meaning of all parameters, but for a read-only lookup tool with this much behavioral disclosure, it is nearly complete. The main gap is parameter semantics for 'lore', 'mode', and 'order_by'.

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 for the schema's lack of parameter documentation. The description explains the semantic difference between 'id' and 'conflict' (id returns only distribution; conflict also returns conflict metadata) and mentions 'Other declared filters are forwarded as supplied.' However, it doesn't explain the meaning of 'lore', 'mode', 'order_by', or 'player' beyond the obvious, and it doesn't clarify which parameters are mutually exclusive or how they combine. The description adds some value but leaves several parameters semantically under-documented.

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 verb and resource: 'Read a player's recorded airdrop distribution for an explicit id or conflict.' It distinguishes the two lookup modes (id vs conflict) and notes that conflict returns metadata while id does not. It doesn't explicitly name a sibling alternative, but the distinction between id and conflict modes is clear enough to differentiate from other conflict_* tools.

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 clear context on when to use the tool: for reading a player's recorded airdrop distribution by id or conflict. It also states what the tool does NOT do ('No prizes are claimed; num_prizes is not recomputed') and that it does not auto-fetch continuation pages. It doesn't explicitly name alternatives, but the behavioral constraints provide practical usage guidance.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses max_group_size sampling behavior, warns against equating UID counts with eligible cards, explains local bounding, single GET request behavior, forwarding of filters, 100-row/256 KiB limits, truncation reporting, and refusal of oversized records. This exceeds the minimum and gives an agent realistic expectations.

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 a clear purpose sentence, but then becomes dense with multiple caveats and technical limitations. It is not wasteful, but it is verbose and may overwhelm an agent scanning quickly. The structure is logical (purpose → behavioral details) but could be tightened.

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 read tool with no annotations and no output schema, the description covers many critical aspects: request semantics, pagination, size limits, error handling, and filter behavior. It hints at output fields (qty, total_cards) but does not fully describe the response structure. Given the complexity, it is quite complete but lacks explicit output format details.

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?

Given 0% schema description coverage, the description compensates by explaining max_group_size's effect ('1 or 2 limited the UID sample') and clarifies the username is explicit. It also mentions 'Other declared filters' forwarded as supplied, though the schema only has two properties. This adds value beyond the schema, though it could be more explicit about value ranges.

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 verb ('Read') and resource ('eligible card groups') for an explicit username, which is distinct enough from siblings like conflict_players or conflict_leaderboard. However, it does not explicitly name a sibling or contrast its scope, so it misses a point for direct differentiation.

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 provides no guidance on when to use this tool versus alternatives. It only implies usage for a username but does not mention conditions, exclusions, or superior alternatives. An agent cannot tell whether this is the right tool for a given query beyond the obvious resource match.

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

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

With no annotations, the description fully shoulders the burden and does so excellently. It discloses that the upstream returns 200 rows, the server truncates to a bounded leading portion, totals and prizes are retained, pagination is not functional, only one GET is made, filters are forwarded without effectiveness guarantees, the list is limited to 100 rows/256 KiB, truncation is reported, and oversized records are refused without partial fields. This is exceptionally transparent about behavior, limits, and failure modes.

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 thorough yet efficient. It leads with purpose, then systematically covers upstream behavior, request characteristics, filter semantics, local limits, truncation handling, and refusal behavior. Every sentence adds distinct value with no filler or redundancy. The logical flow makes it easy to scan.

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 simple one-parameter tool with no output schema, the description is nearly complete. It explains what the response contains (totals and prize metadata, truncation reported), key constraints (100 rows, 256 KiB, single request), and failure behavior (refusal of oversized records). It does not detail the exact output schema, but that is not required. Minor omission: it doesn't describe error formats for non-oversized failures, but overall it is sufficient.

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% and there is only one parameter (id). The description adds only 'by id', which is minimal and somewhat tautological given the tool name. It does not explain what kind of id this is (e.g., a leaderboard id, season id) or where to obtain it. The sentence 'Required inputs reflect tool policy as well as measured upstream requirements' does not clarify semantics. This is adequate but leaves a clear gap about the id's meaning and provenance.

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 ('Read') plus a precise resource ('conflict leaderboard, totals and prize metadata by id'). It clearly distinguishes this from other conflict_* tools by focusing on leaderboard data keyed by id, and the phrase 'by id' sets it apart from list-style endpoints. It is unambiguous about what the tool does.

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 behavioral context (no pagination, single GET, bounded response) but does not provide any guidance on when to use this tool over sibling conflict endpoints like conflict_players or conflict_player_rank. It never names alternatives or exclusion criteria, leaving the agent to infer from the name alone. This is a clear gap.

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

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

No annotations are provided, so the description carries the full burden. It discloses that rank and contribution values retain string types, that it makes one logical GET without auto-fetching continuation pages, applies local array limits (100 rows, 256 KiB) with truncation reporting, and refuses oversized records. These are substantial behavioral details beyond the schema, though some statements appear generic (e.g., 'Array responses' may not apply to this single-object tool).

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 first sentence is concise and front-loads the purpose. However, subsequent sentences include generic caveats like 'Other declared filters are forwarded as supplied' and 'Array responses are locally limited...' that seem boilerplate and may not apply given additionalProperties:false and a single-player response. This adds noise and reduces overall conciseness.

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 simple read tool with two simple string parameters, the description covers the purpose, hints at response content (rank and contribution), and details pagination and size limits. It does not describe the exact response structure, but no output schema exists, so the description can only go so far. It adequately covers operational concerns, despite some generic statements.

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. It only says 'by id and username', naming the parameters without explaining their meaning, format, or examples. The phrase 'Required inputs reflect tool policy as well as measured upstream requirements' is vague and does not clarify parameter semantics, leaving the agent to infer from names alone.

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?

States 'Read one player's conflict ranking by id and username' – a specific verb, resource, and parameters. It explicitly distinguishes itself from the upstream leaderboard_with_player by noting the response contains only player, not the whole leaderboard, which differentiates it from a similarly named sibling.

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 does not explicitly state when to use this tool instead of alternatives. It mentions the upstream name and the single-player scope, implying use for individual rankings, but does not name sibling tools like conflict_leaderboard or provide a decision rule. The note about forwarded filters is behavioral, not usage guidance.

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

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 a relatively good job: it discloses that the tool makes one logical GET request, does not auto-fetch continuations, limits results to 100 rows and 256 KiB, reports truncation, and refuses oversized records without partial fields. The phrase 'Both aliases selected the captured current conflict' is unclear and slightly undermines transparency, but overall the behavioral disclosure is strong.

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 purpose is front-loaded and the constraints are dense, but the description is repetitive: sentences about forwarded filters without implied effectiveness are stated twice. Sentence 2 is also confusing. It is structured enough to be parseable, but several words could be cut without losing meaning.

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 no output schema, no annotations, and zero schema parameter descriptions, the description is incomplete. It covers limits and forwarding behavior well, but it does not describe expected return structure, how to choose between id/conflict/player, or what each filter does. An agent would likely need to resolve significant ambiguity before invoking the tool correctly.

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 needed to explain the nine parameters, but it does not. It vaguely refers to 'id or conflict selector' and 'mode/filter inputs', but never explains player, uids, order_by, non_zero_rp, airdrop_data, lore, or how the required player parameter should be formatted. This leaves the agent without enough information to construct a correct call.

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 clear purpose: read a player's conflict reward-point record and reward_point_threshold. This distinguishes it from broader conflict tools like conflict_leaderboard or conflict_status. However, it does not explicitly differentiate from the similarly named conflict_player_rank sibling, so full disambiguation is left to the agent.

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?

There is no explicit guidance about when to use this tool versus alternatives. The description focuses on internal behavior and forwarding caveats rather than when to select conflict_players over conflict_player_rank or conflict_leaderboard. Any usage context is only implied by the word 'Read' and the resource name.

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

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

With no annotations, the full burden falls on the description. It discloses several key behaviors: response shape depends on selector, wire values are preserved including nullable prize settings, it makes one logical GET with no auto-pagination, array responses are limited to 100 rows/256 KiB with truncation reported, and oversized records are refused. This is exceptional disclosure and goes far beyond a generic read.

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 dense and covers multiple caveats in a compact form. It front-loads the core read statement and then adds necessary behavioral constraints. While it is longer than average, every sentence adds value; minor redundancy like 'tool policy as well as measured upstream requirements' could be tightened.

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?

There is no output schema, so the description needs to explain return behavior. It explains the response-shape dependency on id, preservation of wire values, and output limits/reporting. It does not enumerate the actual fields of a conflict season, but for selecting and invoking the endpoint the description provides enough operational 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 has no parameter descriptions (0% coverage), so the description must compensate. It explains id's role as a selector, but 'lore' is not explicitly described, only grouped into 'Other declared filters' with a warning that effectiveness is not guaranteed. Partial compensation, but the meaning of lore remains under-specified.

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 'Read conflict seasons,' using a specific verb and resource. This clearly identifies the operation and differentiates it from the many conflict_* siblings (e.g., conflict_status, conflict_leaderboard). The resource scope is explicit.

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?

Provides concrete selector guidance: without id you get 24 records, with an explicit id you get one object, so agents know how to choose id usage. It also cautions that declared filters may not actually constrain results and that continuation pages are not auto-fetched. No alternative tool is named, but the advice is clear enough for this endpoint's own usage.

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

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

With no annotations, the description carries the full burden, and it is unusually transparent: it declares one logical GET request, no auto-fetching of continuation pages, wagon limits of 100 rows and 256 KiB, truncation reporting, refusal of oversized records, and a caveat that declared filters may be forwarded without guaranteed effectiveness. This is genuinely useful 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 purpose is front-loaded and the content is dense rather than padded, but the middle section mixes flag behavior, pagination policy, filter caveats, and limit details into a single wall of text. It is compact enough, yet the lack of visual structure makes it harder to scan.

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 no annotations and no output schema, the description covers request behavior, limits, truncation, and oversized-record handling well. However, it omits the meaning of most filters and does not describe the shape of the returned sections, leaving meaningful gaps for a tool with 12 parameters.

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 needed to define all 12 string parameters, but it only clarifies three flags (only_config, only_wagons, exclude_wagons) plus a generic 'forwarded as supplied' caveat. Parameters such as lore, only_stats, only_conflict, and the remaining exclude_* flags are left to inference, which does not sufficiently 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 opening sentence identifies a specific operation ('Read') and enumerates the exact resource bundle: conflict configuration, current conflict, player statistics, and wagons for a username. It is clear what the tool returns, but it does not explicitly contrast it with related conflict_* siblings such as conflict_players or conflict_wagon.

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?

There is no guidance on when conflict_status should be chosen over conflict_wagon, conflict_players, or conflict_seasons. Statements like 'required inputs reflect tool policy' are policy notes, not usage conditions, and no alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden and discloses a great deal: no staking/removing, unknown-uid error semantics, one GET with no continuation-page auto-fetch, truncation limits of 100 rows and 256 KiB, and refusal of oversized records. This gives the agent a solid safety and output-contract model.

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 dense but front-loaded with the core read action, and every behavioral sentence adds information. The phrases about tool-policy requirements and forwarded filters are generic and slightly redundant against the one-property schema, keeping it from a 5.

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?

With no output schema, it explains the key return expectations: complete card list, original contribution values, truncation reporting, and error behavior. It does not describe the exact response object shape or status-code details, but for a one-parameter read tool the essentials are covered.

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?

The schema only says uid is a required string with no description, so the description adds meaning: 'explicit uid' and the unknown-uid error behavior imply that the value is the wagon identifier and must exist. It could go further with format or source guidance, but for a single required parameter this is sufficient.

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: 'Read one wagon by explicit uid,' and clarifies scope with 'complete card list and original contribution values.' This clearly distinguishes it from the many conflict_* sibling tools, which are lists, seasons, players, or rankings.

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 a clear triggering condition: use this when you have an explicit wagon uid, and it describes single-GET/no-pagination behavior. It does not, however, name a sibling alternative for cases like needing filtered or paginated wagon data, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden, and it excels. It discloses paging behavior (one bounded GET, no auto-paging), data preservation rules (amount strings, rental fields, nullable dates), absence of inference, measurement caveats (sort effectiveness unmeasured), local limits (100 rows, 256 KiB), truncation reporting, and refusal of oversized records without partial fields. This is exemplary transparency.

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 dense, with many hedging caveats like 'Paging is declared but not independently demonstrated' and 'Sort effectiveness is unmeasured'. While informative, it lacks conciseness; the key purpose is front-loaded, but the subsequent sentences are numerous and could be tightened. It reads more like a QA report than a tool description, reducing scannability.

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 tool has 5 parameters, no output schema, and no annotations, the description covers a wide range of operational concerns: paging behavior, size limits, truncation, refusal policy, filter forwarding, and data preservation. It is nearly complete, though it does not describe the response format in any detail (e.g., field names, structure) or the meaning of 'SPSP' for domain novices. Still, it addresses most practical invocation concerns comprehensively.

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 for parameter meaning. It only states that required inputs reflect tool policy and that filters are forwarded as supplied, but it does not explain the semantic role of sort, order, offset, or even the player/limit parameters beyond the schema's basic types. The note about size limits relates to limit but not its meaning or defaults. The description adds minimal semantic value beyond the schema, leaving agents to guess at valid sort/order values or offset behavior.

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 clear verb and resource: 'Read incoming SPSP delegation records', and immediately clarifies that each returned player is a delegator to the explicitly requested player. This distinguishes it from sibling tools like delegations_outgoing and delegation_to_target, which handle the opposite direction or specific targets. The purpose 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 offers some context about what the tool does not do (no currency conversion, no card-delegation inference) and hints at relationships with outgoing/pairwise reads, but it never explicitly states when to use this tool versus alternatives. It mentions 'Required inputs reflect tool policy' but gives no concrete selection criteria. There is no direct comparison to sibling tools or conditions for choosing this endpoint, so usage guidance is partial.

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

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

With no annotations, the description carries the behavioral burden and does it reasonably well: it discloses no currency conversion, no card-delegation inference, one bounded GET, no automatic paging, local row/size limits, truncation reporting, and refusal of oversized records. The value is slightly diluted by confusing repetition and the odd 'Two pages of two' clause, but the behavioral disclosures are substantive.

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 overlong and repetitive: paging is stated twice in different words, and 'Two pages of two matched the first four records' reads like stray implementation/test detail. Useful disclaimers are buried among vague policy language, so the structure is neither tight nor well front-loaded.

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 simple bounded read endpoint, it covers truncation, paging behavior, and absence of inference/conversion, which is valuable. However, with no output schema and 0% parameter description coverage, it leaves the return shape only weakly implied and does not define what each parameter actually controls.

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 needed to compensate, but it does not explain player, limit, offset, sort, or order semantics. Phrases like 'Required inputs reflect tool policy as well as measured upstream requirements' and 'Other declared filters are forwarded as supplied' are vague and not parameter-specific. The only concrete hint is the 100-row/256 KiB local limit, which loosely matches the limit maximum.

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 first sentence names a specific verb ('Read'), a specific resource ('outgoing SPSP delegation records'), and defines the directionality clearly: each returned player is a recipient of the requested player. This distinguishes it from incoming-delegation tools even without naming a sibling.

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?

Directionality is implied enough for an agent to infer when this tool applies, but the description never explicitly says 'use this for outgoing delegations' or points to alternatives like delegations_incoming or delegation_to_target. It provides no when-to-use or when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the 404-on-reversal behavior, the zero-amount object observation, preservation of fields, no currency conversion, no card-delegation inference, no automatic paging, array limits, truncation reporting, and refusal of oversized records. This is far more than a typical description provides.

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 purpose statement, but it is bloated and repetitive: 'One bounded GET; no automatic paging' is essentially restated as 'Makes one logical GET request and does not auto-fetch continuation pages.' Generic caveats about filters and sort effectiveness also appear for a tool with only two required parameters, so several sentences do not earn their place.

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 simple two-parameter GET with no output schema and no annotations, the description is unusually complete: it covers request semantics, directional constraints, edge cases, data-preservation behavior, paging, truncation, and hard failure modes. An agent has enough context to invoke the tool correctly and interpret unexpected results.

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, and it does by explaining that 'player' and 'target' form a directed delegation pair and that order matters ('reversing that pair returned HTTP 404'). It adds directional meaning the schema cannot convey, though it stops short of giving concrete value formats or examples.

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 first sentence names a specific verb ('Read'), a specific resource ('directed SPSP delegation'), and the exact scope ('from explicit player to explicit target'). This clearly differentiates the tool from list-style siblings like delegations_outgoing or delegations_incoming, which do not target one directed pair.

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 strong contextual guidance: this is for a directed player-to-target pair, and reversing the pair returns 404, so the agent knows both arguments and their order are essential. It does not explicitly name alternative tools or state when not to use it, but the directed-pair framing makes the intended use clear.

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

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

With no annotations, the description carries the full burden. It explicitly discloses the key behavioral trait: the tool is offline and makes no upstream request. This is a significant transparency point. It does not cover other behaviors (e.g., error handling, output format), but for a single-parameter description tool, this covers the main guarantee.

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?

Two sentences with no waste. The main action is front-loaded, and the offline note is placed second. Both sentences serve distinct purposes, making the description efficient and well-structured.

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 simple tool with one parameter and no output schema, the description is complete. It specifies the tool's scope (one endpoint), the content of the result (parameters, result contract, evidence dimensions, provenance), and its operational characteristic (offline). Nothing essential for an agent to call it correctly is missing.

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. It implies entryId refers to a catalogued endpoint but does not provide format, source, or validation details beyond the schema's minLength. The single parameter name is self-explanatory, but the description adds minimal semantic value.

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 clearly states the tool's purpose: to describe one catalogued endpoint, listing the exact aspects covered (parameters, result contract, evidence dimensions, provenance). It distinguishes itself from sibling tools like list_endpoints and data-fetching tools by focusing on metadata rather than data retrieval.

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 provides clear context that the tool is offline and makes no upstream request, implying it's safe and fast. However, it does not explicitly mention when to use this versus alternatives like list_endpoints or when not to use it. The offline note is a helpful usage signal but lacks explicit direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it discloses the uncached nature, the single GET request behavior, the lack of auto-pagination, the local 100-row/256 KiB array limit with truncation reporting, and refusal of oversized records. This is substantial behavioral context beyond what the empty schema provides.

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-loaded with the core purpose, then adds important behavioral caveats. Every sentence earns its place, though the phrasing around 'required inputs' and 'declared filters' is slightly abstract and could be clearer for an agent. It is not overly long and avoids redundancy.

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 zero-parameter, no-output-schema tool, the description covers the essential operational details: what it reads, how it behaves (single GET, no pagination), and its limits (100 rows, 256 KiB, truncation reporting, refusal of oversized records). It does not describe the exact response format, but with no output schema and a simple 'latest block number' purpose, the description is sufficiently complete for an agent to invoke it correctly.

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?

The tool has zero parameters, and the schema is empty with 100% coverage. The description adds context about 'required inputs reflect tool policy as well as measured upstream requirements' and that other declared filters are forwarded as supplied, which is meaningful for a no-parameter tool because it clarifies that any filters are not guaranteed to be effective. Since there are no params, the baseline is 4, and the description adds extra clarity about the policy-driven input behavior.

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 verb ('Read') and resource ('latest block number reported by the game API'), which clearly distinguishes it from the many sibling tools. It also adds a key differentiator: it is not cached by the settings cache, which helps an agent understand its unique role among the game data endpoints.

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 explains that it makes one logical GET request and does not auto-fetch continuation pages, giving clear context for when to use it (simple, single-page read). It does not explicitly name alternative tools or state when not to use it, but the scope is clear enough that an agent can infer it is for a quick, uncached block-number check rather than a paginated or cached query.

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

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

No annotations are provided, so the description carries full burden. It discloses pagination behavior (no auto-fetch), local limits (100 rows/256 KiB), truncation reporting, and refusal of oversized records. It also notes that filtering semantics are not fully established, which is honest about limitations. This is exemplary transparency.

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 dense but well-structured, front-loading the core purpose and then enumerating limitations. It is longer than ideal but each sentence adds value about behavior, limits, or semantics. No fluff; it is appropriately sized for the complexity.

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 tool is simple with 2 optional params and no output schema. The description covers most operational details: pagination, limits, truncation, refusal. It does not describe the shape of the output or how maintenance windows are structured, but given the lack of output schema, some additional detail on return format would help. Still, it is reasonably 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 coverage is 0%, so the description must compensate. It mentions start_date and end_date are forwarded but does not describe format or requiredness beyond schema. It provides some context on date bounds being forwarded but not enough to fully document the parameters. Baseline for low coverage is higher, but description falls short of full compensation.

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 clearly states the tool reads maintenance windows and window_buffer_ms, which is a specific resource. However, it does not explicitly differentiate it from siblings like game_settings, which may also cover maintenance-related data. The purpose is clear but sibling differentiation is implicit.

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 provides explicit notes on behavior (no auto-pagination, limits, truncation reporting) and clarifies that filter effectiveness is not implied. It does not name alternative tools for when to use this instead, but the context of reading maintenance windows is clear enough for an agent to decide.

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

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

Even with no annotations, the description thoroughly discloses behavior: one-hour caching per exact query, no delta protocol, no auto-fetching, bounded cache, response size limits, truncation reporting, and refusal of oversized records. This goes well beyond what the schema or annotations provide and gives the agent concrete expectations.

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 and then packs in caveats about caching, delta behavior, limits, and truncation. It is dense but not bloated; each sentence conveys a distinct behavioral constraint. It could be tightened slightly, but the structure is logical and efficient.

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 simple read tool with two optional parameters and no output schema, the description is quite complete: it covers cache behavior, request semantics, response limits, and error handling for oversized records. It does not describe the shape of the settings body, but 'full settings body' gives a basic sense of the return value. The ambiguous 'Required inputs' sentence slightly weakens completeness.

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. It adds meaning for version and config_version by explaining they are not a delta protocol and that matching values still return the full settings body. However, it does not clarify valid formats, whether values are matched against current versions, or what happens when they are omitted.

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 clear verb and resource: 'Read current public settings from the API.' This distinguishes it from many player- or market-specific siblings, and the 'public settings' scope adds meaning. However, it does not explicitly differentiate it from other settings-like siblings such as purchase_settings or game_maintenance.

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 opening sentence implies the tool is for retrieving current public settings, giving clear context. But it does not state when to use this tool versus alternatives, nor does it mention any exclusions or sibling alternatives. With a large sibling list containing several similar settings-related tools, this guidance is only implicit.

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

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses that this is a public read, makes one logical GET, does not auto-fetch continuation pages, limits array responses, reports truncation, and refuses oversized records without partial fields. It also prevents over-interpretation by noting it is not a route-availability claim.

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 opening sentence is clear and front-loaded, and the health-read caveat is useful. However, 'Required inputs reflect tool policy as well as measured upstream requirements' and 'Other declared filters are forwarded as supplied' are generic statements that add little for a zero-parameter tool and could mislead an agent into expecting inputs that do not exist.

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 simple health endpoint with no parameters, the description is largely complete: it names the returned metadata, notes the single-request behavior, and documents truncation limits. A small gap is the absence of any detail about response status values or error behavior, but with no output schema this is not a major omission.

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?

The tool has zero parameters, so the baseline is 4 and no parameter documentation is needed. The description does add a note that required inputs reflect tool policy and upstream requirements, but since the schema is empty this is not critical. It neither confuses nor substantively improves parameter understanding.

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 verb and resource: 'Read the public VAPI health root'. It also clarifies that this reports status and application/version/environment metadata, and explicitly distinguishes this from a claim about game route availability. This clearly separates it from the many data-route siblings.

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 clear context that this is a health read and warns it is not a guarantee that all game routes are available. However, it does not explicitly say when to choose this tool over alternatives or name any sibling as the right choice for route-level status checks. Usage is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explicitly discloses single-GET behavior, no auto-pagination, local row and byte limits, truncation reporting, refusal of oversized records, decimal-string payout quantities, and incomplete-history caveats.

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 a clear purpose statement, but the later sentences are dense and partially redundant. 'Other tournament and date selectors remain forwarded but unverified' and 'Other declared filters are forwarded as supplied' convey nearly the same caveat, and 'Required inputs reflect tool policy' adds little concrete 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?

For a read-only tool with no annotations and no output schema, the description covers invocation behavior, filter reliability, limits, truncation, and refusal semantics. It does not describe the shape or fields of individual brawl records, but it provides enough operational context to call the endpoint correctly.

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 supply parameter meaning itself. It explains cycle as a single-row selector and start_cycle/end_cycle as inclusive endpoints, and it groups tournament/date filters as forwarded-but-unverified. guild_id is implied by 'explicit guild,' though date formats and per-parameter validation expectations are left vague.

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 clear verb and resource: 'Read brawl records for an explicit guild.' This states the tool's action and scope unambiguously. It does not explicitly differentiate from sibling tools like guild_brawl_sps_rewards, relying on the 'records' versus 'rewards' distinction to carry that weight.

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 provides no guidance on when to choose this tool over alternatives such as guild_brawl_sps_rewards or tournament_find_brawl. It explains how certain selectors behave and that some inputs are unverified, but this is filter semantics rather than usage routing.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose several important behaviors: it makes one logical GET request without auto-fetching continuation pages, locally limits results to 100 rows and 256 KiB with truncation reporting, and refuses oversized records. It also clarifies that filters are forwarded as supplied and their effectiveness is not guaranteed. However, the sentence 'Use the string 1 for include_total or include_cycles: true returned an empty object' is confusing and could mislead an agent about how to set boolean-like parameters, detracting from clarity.

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 poorly structured. It front-loads the purpose but immediately follows with a confusing, run-on note about parameter usage. Subsequent sentences jump between filtering semantics, request behavior, and output limits without clear organization. The length is not justified by clarity; it could be tightened significantly.

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 no annotations, no output schema, and five parameters, the description needs to be thorough. It does cover request behavior, pagination, limits, and filtering semantics, but it fails to explain the core parameter semantics (especially cycle, start_cycle, end_cycle) and never defines what 'sps_reward_records' is or what the response structure looks like. The description assumes domain knowledge that an agent may not have, leaving critical gaps.

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 by explaining the parameters. It only mentions include_total and include_cycles, and even then in a confusing way ('Use the string 1 for include_total or include_cycles: true returned an empty object'). It does not explain the meaning of cycle, start_cycle, or end_cycle, leaving most parameters undefined. The hint that 'Cycle records are bounded while a requested total is retained' gives some context but is insufficient.

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 clear verb and resource: 'Read global brawl SPS payout totals and/or cycle records.' It explicitly uses 'global' to distinguish from guild-specific sums, which helps separate it from siblings like guild_brawl_records. However, it does not explicitly name an alternative tool or state the exact differentiation, so it's clear but not perfectly disambiguated.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description mentions 'The total is global even when cycle narrows records; it is not a guild or selected-cycle sum,' which implies scope but does not say 'use this when you need global totals' or reference any sibling. It also does not describe any prerequisites or fallback conditions, so an agent has to infer the appropriate use case.

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

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

With no annotations, the description carries the full burden and succeeds: it discloses GET semantics, the absence of auto-fetching continuation pages, local array limits of 100 rows and 256 KiB, truncation reporting, refusal of oversized records, and that amounts/cumulative fields keep original units and wire values. This is unusually transparent.

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 first sentence is an excellent front-loaded purpose statement, and the caveats are dense but relevant. Some boilerplate ('Other declared filters are forwarded as supplied; their effectiveness is not implied by the schema') is vague given the schema has only two required fields, so it is not perfectly tight.

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 two-parameter read tool with no output schema, it covers purpose, parameter semantics, request behavior, pagination limitations, response limits, truncation, and oversized-record handling. It does not describe the exact response shape or field names, which is the main gap given the absence of an output schema.

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. It maps guild_id to the guild and type to the building type, supplies concrete valid type examples ('guild_hall and arena'), and explains that required inputs reflect upstream policy. It stops short of an exhaustive list of valid type values or ID formats.

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?

Opens with a specific verb+resource statement: 'Read contributions for a guild and explicit building type.' This clearly identifies both the action and the target, and 'contributions' distinguishes it from sibling guild tools such as guild_members or guild_brawl_records.

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?

Provides clear context that the tool is for reading guild contributions but requires an explicit building type. It also warns that it is not suitable for complete contribution history because pagination is not established, which functions as a usage exclusion. It does not name an alternative sibling, so it stops short of a 5.

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

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

With no annotations provided, the description carries full responsibility, and it delivers unusually rich behavioral detail: no continuation-page auto-fetch, JSON-encoded string wire types, local truncation limits, truncation reporting, and refusal of oversized records. It also clarifies that 'ext=true' does not imply response expansion, which is a valuable non-obvious behavior.

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 but front-loaded with the core purpose, followed by caveats that earn their place. The final sentences about truncation and oversized records are precise and useful. Some wording, such as 'Required inputs reflect tool policy as well as measured upstream requirements', is vaguer than ideal but not wasteful.

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 provides many behavioral details but omits essential parameter semantics for ext and username and does not describe the response shape beyond scattered wire-type and truncation notes. Since there is no output schema and no annotations, an agent cannot confidently construct all valid inputs or interpret the full response.

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. It explains that id is an explicit required ID and vaguely refers to 'other declared filters', but it does not define what ext values are valid or what username does. The ext warning is confusing rather than clarifying.

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 opening sentence, 'Read one guild by its explicit ID', identifies a specific verb, resource, and selection criterion. This clearly distinguishes guild_find from sibling list/search tools such as guild_list and guild_members.

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 phrase 'by its explicit ID' provides a clear context for when this tool should be used: when the caller already has a specific guild ID. It does not explicitly name alternatives or say when not to use it, but the ID-based selection criterion is enough to route an agent appropriately.

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

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

Without any annotations, the description carries the full burden and does so thoroughly: it discloses the transport limit motivation, exact results for matched/unmatched names, lack of pagination, one GET request, local row/byte limits, truncation reporting, and refusal of oversized records. This goes well beyond minimal disclosure.

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 repeats the same idea: 'Other declared filters are forwarded without assuming their effectiveness' appears twice in slightly different wording. Some sentences ('Required inputs reflect tool policy...') add little actionable information.

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?

Despite no output schema and no annotations, the description covers the operational essentials: required name, result cardinality, no continuation pages, local truncation at 100 rows/256 KiB, truncation reporting, and oversized-record handling. The remaining gap is per-parameter semantics and full return fields, which prevents a 5.

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. It clarifies that name must be explicit and that other declared filters are forwarded without guaranteed effectiveness, but it does not explain the semantics of sort_by, language, username, or membership_type. The parameter names are self-descriptive, but the agent gets no values or allowed options.

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 opening clause 'Search guilds by an explicit name filter' states a specific action and resource with a clear scope. It does not explicitly compare with sibling guild_find, but the emphasis on explicit name filtering differentiates the tool enough for selection.

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 explains when this tool is appropriate: a specific name is needed because unfiltered calls exceed the transport limit and unmatched names return no guilds. It cautions that non-name filters may not be effective, effectively telling the agent not to rely on them. It stops short of naming alternative tools, so it is not a 5.

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

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

With no annotations, the description carries the full burden and excels: it reveals no paging controls, one logical GET request, no auto-fetched continuation pages, 100-row/256 KiB local array limits, truncation reporting, refusal of oversized records, and non-inferred membership status. This is unusually thorough behavioral disclosure.

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 purpose is front-loaded and nearly every sentence contributes an operational constraint. It is dense and there is mild redundancy between the tested limit/offset finding and the 'does not auto-fetch continuation pages' sentence, but this does not significantly hurt 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?

For a tool with no output schema and no annotations, the description covers the required input, query semantics, paging absence, size limits, truncation, and oversized-record refusal. It does not describe the output row fields or the full set of allowed status values, leaving a minor gap in the contract.

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, and it does meaningfully. It gives status behavioral semantics (not inferred, example with active, forwarded as supplied) and treats guild_id as explicit and policy-required. It does not enumerate valid status values, but for two parameters the added guidance is substantial.

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?

Opens with a precise action/object pair: 'Read guild membership rows for an explicit guild_id.' This clearly states what the tool does and the required resource. It does not explicitly contrast with sibling tools such as guild_list or guild_contributions, so it misses the top score for differentiation.

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 phrase 'for an explicit guild_id' provides clear context for when this tool is appropriate, and the note that required inputs reflect tool policy/upstream requirements adds practical guidance. However, it never states when not to use this tool or names alternatives, leaving exclusion criteria unstated.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds substantial behavior beyond those: bounded window semantics, local custom_json_id filtering, next_start returned even on empty matches, no automatic pagination, and refusal of oversized results. This is rich, non-redundant behavioral disclosure.

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?

Four sentences, each carrying distinct information: scope, default, filter behavior, pagination behavior, limitation, and error behavior. The most important scoping detail is front-loaded and nothing is wasted.

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 read-only annotations and the detailed behavioral notes, an agent has most of what it needs to call this tool correctly. The missing explanation of operation_type and the absence of any output schema/return-shape note prevent a perfect score, but the core invocation and pagination contract are well covered.

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. It explains custom_json_id filtering semantics and implies limit/start windowing through 'bounded window' and 'next_start', but operation_type is not explained at all, and start's cursor behavior is only indirectly hinted at. Partial compensation with a clear remaining 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 states a specific verb ('Search') and a specific resource ('one bounded window of an explicit Hive account's authority-indexed history'). It further distinguishes itself by explicitly noting this is not complete incoming-recipient history, which helps separate it from sibling history tools.

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 clear context about the bounded window, the default of newest 100 records, and the lack of automatic pagination. It warns that oversized results are refused, and that this tool is not complete incoming-recipient history, but it does not name an alternative sibling for complete history, so it stays just short of explicit alternative routing.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it preserves every operation and signature, decodes custom JSON, counts gift-card items separately, and explicitly states it does not establish game processing or irreversibility. It also notes 'One read-only RPC', which is useful operational context. No contradiction with annotations.

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 three sentences, each earning its place: the first states the core action, the second adds key behavioral details, and the third clarifies limitations and RPC cost. It is front-loaded with the primary purpose and avoids redundancy with annotations.

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 single-parameter read-only tool with rich annotations, the description is nearly complete. It covers the main purpose, key behaviors, and a limitation. It does not describe the return format or output structure, but there is no output schema, and the description's mention of 'count recognized gift-card items separately' gives some hint of the response. The absence of explicit alternatives or error conditions is a minor gap, but overall the description is sufficient for an agent to select and invoke the tool correctly.

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. The description explains what the tool does with the transaction ID (reads full signed transaction, decodes custom JSON, counts gift-card items) but does not add specific parameter-level details beyond the schema's pattern. The single parameter trx_id is well-defined by the schema pattern, and the description implies its use. Baseline 3 is appropriate because the schema defines the parameter format clearly, and the description adds functional context but no additional 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 states a specific verb ('Read') and resource ('full signed Hive transaction by transaction ID'), and distinguishes itself from siblings like transaction_inspect and transaction_lookup by emphasizing preservation of every operation/signature and custom JSON decoding. It clearly identifies what the tool does and its scope.

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 when to use this tool: when a full signed transaction with all operations and signatures is needed, and when custom JSON/gift-card item counts are relevant. It does not explicitly name alternatives or exclusions, but the context signals and sibling list suggest transaction_inspect/transaction_lookup as related tools. It provides clear context but no explicit when-not-to-use guidance.

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

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

With zero annotations, the description carries the entire behavioral burden and does so thoroughly: it discloses coordinate verification, the 'unverified, not proof of absence' caveat, the possible extra internal GET with a hard two-request limit, 'successful responses include plot_reference', and includes all three identities and freshness.

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 dense and the key guidance is front-loaded, but there is redundancy between 'plot_reference with numeric ID, padded label and deed UID' and 'all three plot identities and resolution freshness'. Two overlapping sentences could be merged without losing 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?

Given no annotations and no output schema, the description provides everything an agent needs: accepted forms, uniqueness constraint, verification behavior, failure semantics, extra-request behavior, and response contents. For this medium-complexity tool, the definition is 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%, and the description compensates by giving meaning to both parameters: plot_id can be numeric or a padded/unpadded label, deed_uid accepts original UID spelling, and the 'supply exactly one' constraint clarifies the schema's all-optional structure.

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 verb-resource pair ('Get a public deed') and identifies two lookup paths: numeric plot_id and region-tract-plot display label. However, it also accepts deed_uid without distinguishing itself from the sibling land_deed_by_uid, which slightly blurs purpose and tool selection.

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 clearly says to supply exactly one plot_id or deed_uid and explains padded/unpadded label formats. It never mentions when to prefer alternatives like land_deed_by_uid or land_deeds_search, so the exclusion/alternative guidance is only implied, not explicit.

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

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It reveals the possible extra verification GET, the hard two-request limit, and the content of populated results, going well beyond a simple 'get by UID' statement.

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?

Three dense sentences with no filler. The core purpose is front-loaded, followed by parameter constraints and behavioral caveats, each earning its place.

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 single-record lookup with no output schema, the description gives enough invocation detail plus result-summary hints. It does not specify error cases or behavior when both parameters are supplied, though 'exactly one' partially addresses that.

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%, but the description compensates fully by explaining that plot_id accepts numeric or display-label forms, deed_uid accepts the original spelling, and exactly one must be supplied. This adds meaning the raw schema lacks.

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?

States a specific verb ('Get'), a precise resource ('public land-deed record'), and the lookup key ('one deed uid'). It also mentions accepted alternative identifiers, making the tool's scope readily distinguishable from sibling lookups.

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?

Clearly instructs the agent to supply exactly one of plot_id or deed_uid, which is critical usage context given the schema marks no parameters required. However, it does not explicitly name or differentiate from the sibling land_deed_by_plot, so the alternative-selection guidance is incomplete.

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

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

With no annotations, the description carries the full burden. It discloses the response shape ({status, data} with {count, uid} rows), the historical naming caveat, the observed null data for unrecognized accounts, and the fact that limit=2 and offset=5 had no effect in probes. This is substantial behavioral context beyond the schema. It doesn't cover every possible behavior (e.g., known account with no land), but it is transparent about what was observed.

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-loaded with the core purpose, then adds caveats and observed behavior. Every sentence adds information: the historical name caveat, response shape, null behavior, and query probe results. It is slightly dense but not bloated, and the structure is logical.

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 one required parameter, no output schema, and no annotations, the description covers the essential call semantics, response shape, and known edge cases. It doesn't explain return values in exhaustive detail, but it provides enough for an agent to call the tool and interpret the response. The main gap is not specifying the exact player identifier format, but overall it is reasonably complete for a simple one-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 description coverage is 0%, so the description must compensate. It explains that 'player' identifies the account and that the response contains per-region counts for that account. However, it doesn't add details about the player parameter format, whether it's a username or account name, or any constraints beyond minLength 1. The description adds some meaning but leaves the parameter semantics partially underspecified.

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 verb and resource: 'Return the per-region plot counts reported for one account.' It also clarifies the historical name and that the response contains region rows rather than individual land records, which distinguishes it from land_deed_by_plot and land_deed_by_uid. It doesn't explicitly name a sibling alternative, but the scope is clear enough to differentiate it from the many land-related siblings.

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: call it with one account to get per-region plot counts. It does not explicitly state when to use this tool versus alternatives like land_deeds_search or land_regions_counts, nor does it state exclusions. The context about unrecognized accounts and query probes gives some practical guidance, but no explicit when-to-use or when-not-to-use guidance is present.

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

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

With no annotations, the description carries the full burden, and it thoroughly discloses behavior: response shape, empty-result semantics, the all-or-nothing 256 KB limit, malformed-response conditions for undeclared changes, no sorting/ranking/comparison, and even a documented zero-value observation with its limits. This is exceptional transparency beyond what any schema could convey.

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 content is dense and front-loaded, but the description is not concise: an entire paging-probe paragraph is repeated verbatim, and several caveats are restated at the end. The lack of formatting or bullets makes the long list of behavioral edge cases harder to scan. Every sentence should earn its place, and the duplicated block does not.

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 no output schema and no annotations, the description is unusually complete: it explains the response envelope, how to join the three arrays by deed_uid, field-level type behavior, error/empty semantics, result limits, paging observations, and the server's non-transformational contract. An agent has enough context to invoke this tool and interpret its response correctly.

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 explain the parameters, and it does: player/tract_id/region_number are search filters, limit is pronounced as the value to shrink when responses are too large, offset is shown to not reach later rows, and orderBy=desc is documented as currently returning an empty array. Minor gaps remain because there is no systematic per-parameter definition, defaults, or clarification of how filters combine.

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 first sentence states a specific verb and resource ('Search public land deeds') and the supported filter dimensions ('by player or place (tract_id or region_number)'). It also clarifies that a bare search is refused, which prevents misuse. This distinguishes it from sibling deed tools by scope, even without naming them.

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 clear usage constraints: searches must be narrowed by player, tract_id, or region_number, and bare searches are refused. It also instructs to request a smaller limit when the 256 KB result limit is hit and to narrow the request rather than rely on offset paging. It does not explicitly compare against sibling tools such as land_deed_by_uid or land_deeds_owned, so it stops short of full alternative-routing guidance.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds substantial behavioral detail: alternatives are independent, invalid comparisons set isError while valid ones remain, bare UIDs cannot be resolved offline, edition-19 abilities use dated data, regional mode replaces only the target plot demand, and Runi behaves differently from normal workers. No contradiction with annotations.

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 dense and packed with unique, useful information; nearly every sentence adds value. However, it is a single long wall-of-text rather than a structured or front-loaded explanation, which makes it harder to scan quickly.

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 high complexity, zero schema coverage, and no output schema, this description is remarkably complete: it explains input requirements, regional mode specifics, output values, error behavior, exclusions, and caveats. Minor gaps remain around exact output structure and a few nested input fields, but nothing critical is missing.

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 carries the burden. It adds meaningful semantics for comparisons, workers, plot efficiency vs regional_power, land_dec_stake_needed, Runi, and item boosts. It does not spell out every parameter group (e.g., runi's required fields, title_boost/totem_boost exact structure, base_cap), so it is strong but not exhaustive.

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 verb and resource: it is an 'offline deterministic Land what-if for Grain/Wood/Stone/Iron worksites'. It also explains the comparison capability and explicitly distinguishes itself from land_lineup_snapshot, which is for live comparisons.

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 provides clear context: this is offline, deterministic, and does not perform HTTP, signing, or live staking validation. It names land_lineup_snapshot as the alternative for live comparisons and lists exclusions (Castles/Keeps, SPS, Research). However, it stops short of an explicit 'use this when / use that when' formulation.

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

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

The description goes far beyond the annotations with concrete operational details: 'At most ten logical GETs, including one bounded-memory full collection stream; no automatic pagination or per-card lookup loops,' plus limits like 'up to 200 owner deeds' and 'At most 100 matching cards; a larger selection is refused.' It also discloses non-atomicity ('Reads are not atomic') and that missing cards are not presented as ready to stake – all valuable behavioral context beyond the simple readOnlyHint flags.

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 dense but each sentence earns its place: purpose, input constraints, operational limits, data fetched, output condition, and safety guarantee. It is front-loaded with the primary purpose and uses precise, no-nonsense language. It is slightly longer than average but justified by the tool's multifaceted behavior.

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 complexity (5 parameters, no output schema, 0% schema coverage), the description is remarkably complete. It covers input selection rules, internal execution limits, what data is fetched, output shape ('estimator-ready baseline'), edge-case behavior (missing cards, non-atomic reads), and explicitly states that no stake changes occur. An agent would be well-equipped to call this tool without further 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?

With 0% schema description coverage, the description must compensate – and it does. It explains the interaction between plot_id/deed_uid ('Supply exactly one... or...'), differentiates candidate_uids vs candidate_card_detail_ids ('up to ten card detail IDs or twenty UIDs'), and adds semantic detail like 'current workers are always included.' It doesn't explicitly map 'player,' but that parameter is trivially self-explanatory.

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 verb and resource – 'Gather an explicit player's current Grain/Wood/Stone/Iron plot and selected candidate cards' – and explicitly ties it to the land_lineup_estimate sibling toolnovel. It also differentiates itself from stake-changing tools by noting 'No stake changes are performed,' making its role 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 clearly conveys its use as a preparatory step for land_lineup_estimate and imposes explicit input constraints ('Supply exactly one numeric/display plot_id or deed_uid,' 'Select up to ten card detail IDs or twenty UIDs'). It does not explicitly name alternatives or say when *not* to use it, but the reference to the estimator and the 'No stake changes' disambiguate it from stake-related siblings.

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

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

With no annotations, the description carries the full burden. It proactively discloses that the tool 'returns the rows unchanged and does not derive totals or pool membership,' and explains the observed pool/reward pattern. This is valuable beyond the tool's name and schema.

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 well-structured, starting with the primary action and then providing detail. A couple of sentences are somewhat verbose (e.g., the six-pool explanation), but each sentence adds meaningful context without redundancy.

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?

Despite having no output schema and no annotations, the description fully specifies what is returned: exact row count, field types, and behavioral guarantees. For a zero-parameter list tool, this is complete and sufficient for an agent to understand the result.

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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning. It does clarify the data types and row composition, which compensates for the absence of an output schema.

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 clearly states the verb 'List' and the resource: 'the 12 real (token, liquidity_pool_id) reward-total pairs' from GET /land/liquidity/allrewards. It is specific and distinct in content, though it does not explicitly compare against sibling tools.

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?

No guidance is given about when to use this tool versus alternatives. While the endpoint is unique among siblings, the description does not mention selection criteria, use cases, or exclusions, leaving the agent to infer usage from the name alone.

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

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

With no annotations provided, the description carries full disclosure burden. It thoroughly discloses return field omissions, type inconsistencies (strings vs numbers), error handling (data:null vs 400), and the server's pass-through behavior. No contradictions; every behavioral trait is explained.

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?

Every sentence earns its place: the purpose is front-loaded, behavioral nuances are grouped logically, and there is minimal redundancy. The description is detailed but efficient, fitting several critical facts into a compact paragraph.

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 tool with no annotations and no output schema, this description is remarkably complete. It covers the return shape, field types, error semantics, and upstream behavior, leaving little for an agent to infer. It also explains the difference from the list route, which is essential for correct selection.

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?

The single parameter 'id' is covered by the schema with type and minimum, and the description adds context about how different id validity states affect the response, effectively giving semantic meaning beyond the raw schema. Since schema coverage is 0%, this compensation is valuable.

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?

States a precise verb ('Get') and resource ('liquidity-pool object by id'), and explicitly distinguishes it from the list route by noting it returns a single object with a narrower field set. The route pattern is given, making the tool's purpose unambiguous and differentiated from siblings like land_liquidity_pools.

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?

Provides clear behavioral expectations for different id scenarios (real, unknown well-formed, malformed) and explains the resulting HTTP outcomes, which guides usage. However, it does not explicitly name alternative tools (e.g., land_liquidity_pool_by_symbol) or state when to prefer this over them, though the 'by id' nature is implicit.

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