Aura

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds value by characterizing the payload (team totals and per-player stat lines), but says nothing about behavior on an invalid or unplayed gameId, and no output schema exists to fill that gap.

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?

One sentence, front-loaded with the resource and immediately followed by its contents. Nothing is wasted and nothing important is buried.

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 strong annotations, the description covers purpose and return content adequately; the absence of an output schema is partly offset by the 'team totals and every player's stat line' summary. Minor gaps remain around error behavior and result granularity, but nothing blocks correct 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?

With a single parameter at 100% schema coverage, the schema already documents gameId and even points to aura_list_games and aura_live_games as sources. The description adds no further parameter meaning, so the baseline 3 applies.

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 resource (full box score for one game) and enumerates its contents: team totals plus every player's stat line. This lets an agent distinguish it from play-level siblings like aura_game_plays or frame-level aura_game_frame, though it never names those alternatives 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?

Usage is only implied: call it when you have a gameId and want the full statistical summary. There is no statement of when to prefer aura_get_game or aura_game_plays instead, and no prerequisites or exclusions are given.

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 declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds the concrete side effect (an email is sent to the user), the plan transition, and the resulting 50,000 requests/month quota — none of which the annotations convey. It stops short of stating whether codes expire or what happens if the email is wrong/unreachable.

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 short sentences: effect first, prerequisite second, hand-off third. No filler, and the ordering matches how an agent should actually act.

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 one required parameter, full schema coverage, no output schema, and a clear two-step flow, an agent has enough to call it correctly. Minor gaps remain around return value and code validity window, but nothing blocking.

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 100%, so the single email parameter is already documented; the description still adds a real behavioral constraint beyond the schema ('Ask the user for their email first; never guess it'), which meaningfully changes how the agent sources the 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?

States a specific verb and resource ('Emails the user a 6-digit code') plus the outcome ('moves this connection from the trial to the free plan'). It explicitly hands off the follow-up step to the sibling aura_verify_email, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit prerequisite ('Ask the user for their email first; never guess it') and an explicit next action ('Then ask them for the code and call aura_verify_email'). The alternative and the condition that selects it are named directly.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds that the answer includes measured completeness and freshness, which prevents treating ``covered/not covered'' as a bare boolean and is a useful behavioral nuance. It does not describe the shape of the response, but with no output schema and a very simple read, that is a modest gap.

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 cover what it returns and when to call it, with the result content front-loaded. There is no filler, repetition, or restating of the tool name.

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-argument, read-only discovery tool with full annotation coverage, the description gives enough to call confidently. Since no output schema exists, a brief hint about the return shape — for example, a list versus a nested breakdown — would have closed the only remaining 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?

The tool takes no parameters, so the baseline of 4 applies; there is nothing a description could add about argument semantics here.

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 the exact resource it enumerates — sports, seasons and data products currently available in Aura — plus the quality dimensions (completeness, freshness). That is clearly distinguishable from every sibling, which all fetch concrete entities or games. It is a noun phrase rather than an explicit verb+object, which keeps it 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?

"Call when unsure whether Aura has a given sport, season, or product" states an explicit trigger condition for the call. No when-not-to-use or named alternative is given, but for a discovery tool whose only alternative is guessing, that omission is minor.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds a useful hint that a freshness/staleness field is returned, but says nothing about failure modes for non-live games or data latency beyond that term.

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?

One compact sentence with the resource up front and the returned fields enumerated after the colon; no filler. The colon list is dense but readable.

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, the description does the work of naming the return fields (score, situation, latest play, freshness), which is exactly what an agent needs. Only gap is the lack of guidance about non-live games and error behavior.

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 100% and the gameId description already routes to aura_list_games/aura_live_games as the id source. The description adds no further meaning to the single parameter, so the baseline of 3 applies.

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 resource (current game state) and enumerates the contents: score, situation, latest play, freshness. An agent can distinguish it from the heavier aura_boxscore or aura_game_plays by the explicit field list, though no sibling is named.

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?

'At this moment' implies live/in-progress usage, but the description never says when to pick this over aura_get_game, aura_boxscore, or aura_game_plays, nor what happens for a scheduled or finished game.

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, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description adds real context beyond that: results are priced on both sides per source, include live result and settlement, and player_prop payloads can be large — a useful cost warning for an agent planning calls.

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, zero filler. The core capability is front-loaded, and the narrowing advice follows immediately, so an agent reading only the first clause already knows what the tool returns.

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, the description carries the burden of describing the return: per-source two-sided pricing plus live result and settlement is a fair sketch of the shape. It stops short of saying how sources are keyed or how large an unfiltered player_prop result typically is, but for a read-only lookup with four annotations this is close to 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 80%, so the baseline is 3. The description goes beyond the schema by explaining the intent behind marketType (shrinking the result set) and the combination rule for playerId/definitionId under player_prop, which the schema lists but does not motivate.

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+resource (current odds for one game) and enumerates the market types returned: moneyline, spread, total, player props, plus live result and settlement. An agent can distinguish it from game-data siblings like aura_game_frame or aura_boxscore, though it never names aura_odds_timeline, the closest neighbor, so the differentiation is incomplete.

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 second sentence gives operational guidance — pass marketType to keep results small, and add playerId or definitionId when querying player_prop — but this is about narrowing output, not about when to choose this tool over aura_odds_timeline or aura_get_game. Usage is implied rather than stated, and there are no 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is fully covered. The description adds the useful ordering guarantee and pagination mechanic, but says nothing about output shape, page limits, or error 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?

Two short sentences with no waste; the core purpose is front-loaded and the pagination instruction follows immediately.

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, paginated list tool whose annotations and full-coverage schema carry most of the burden, the description covers ordering and pagination adequately. Only a brief note on sibling differentiation would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented, including the meaning of cursor and gameId. The description's mention of page.nextCursor largely repeats what the schema provides, so the baseline of 3 applies.

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 the resource (play-by-play for one game) and its ordering, which is a clear purpose. However, it doesn't distinguish this tool from per-game siblings like aura_game_frame or aura_boxscore, so an agent must infer the difference.

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 pagination instruction ('Pass page.nextCursor to continue') gives concrete usage for repeat calls, but there is no guidance on when to choose this over aura_game_frame or other per-game 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety behavior is covered. The description adds the shape of the returned record (teams, start time, status, period, score) but says nothing about missing/unknown-id behavior or freshness of live data.

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?

One short sentence, front-loaded with the lookup key and followed by the returned field list. No filler, no repetition of the title.

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 with no output schema, enumerating the returned fields covers the main gap an agent would otherwise face. Only the not-found/error path is left unaddressed, which is a minor 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?

Schema description coverage is 100% and the single parameter's description already explains provenance (aura_list_games or aura_live_games). The description's mention of 'Aura game id' adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 (implicitly 'get') and resource ('One game by Aura game id') plus the payload it returns, which clearly separates it from the list-style siblings. It does not name any sibling, so differentiation is inferential rather than 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?

Usage is only implied: you must already have an Aura game id. The fact that the id comes from aura_list_games or aura_live_games appears in the schema, not the description, so the description itself gives 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is lighter. It adds genuine value by enumerating the returned fields (name, position, status, current team, headshot), which substitutes for the absent output schema. It does not say what happens for an unknown id, which keeps it short of a 5.

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?

One short, front-loaded clause with zero filler; the identifier requirement and the returned fields both appear immediately. The verbless fragment is efficient if slightly telegraphic.

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 full annotation coverage and no output schema, the description supplies the needed pieces: identity key, cardinality, and the field set returned. Only edge-case behavior for an invalid or missing id is absent.

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 100% and the single parameter already documents 'Aura player id'. The description restates the same concept ('by Aura player id') without adding format, source, or example values, so baseline 3 applies.

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 resource and cardinality ('One player by Aura player id') plus the fields returned, which implicitly contrasts with the list-style sibling aura_list_players. It never names that sibling explicitly, so the differentiation is inferred rather than stated.

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 is only implied: 'by Aura player id' signals a single-record lookup requiring a known id, which hints that discovery should go through aura_list_players first. There is no explicit when-to-use, no prerequisite about obtaining the id, and no named alternative.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no note on error behavior for an unknown team id or what a successful lookup yields.

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?

It is a single short fragment with no filler, so there is no bloat, but the terseness comes at the cost of under-specification rather than efficiency. Nothing is front-loaded beyond the bare noun phrase.

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 complete schema coverage and full annotations, very little prose is required — but with no output schema, the description should at least indicate what a team record contains or how a missing id behaves. Those gaps are unaddressed.

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 100%, and the teamId description already tells the agent to obtain the id from aura_list_teams. The description's "by Aura team id" merely restates the schema, so the baseline 3 applies.

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 phrase "One team by Aura team id" identifies the resource (a single team) and implicitly distinguishes it from the list variant aura_list_teams by emphasizing "one." However, it is a sentence fragment with no verb, and the distinction from aura_get_team_roster is left entirely to inference.

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, no mention of prerequisites, and no named alternative. The only routing hint lives in the schema's parameter description ("from aura_list_teams"), not in the tool description itself.

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, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description contributes the return-field inventory (ids, positions, jersey numbers, height, weight, headshots), which is genuine added context given there is no output schema. It says nothing about roster currency (active vs. injured vs. historical) or ordering.

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?

One compact sentence with no filler, and the resource is front-loaded before the field list. It is a sentence fragment without a verb, but 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?

For a one-parameter read tool the description is largely adequate, and the field enumeration substitutes for the missing output schema. However, it omits whether the roster reflects the current season, includes inactive/IR players, or how large rosters typically are — details an agent would need to interpret results 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 100% and the single teamId parameter is documented with its source (aura_list_teams), so the schema does the heavy lifting. The description adds no further meaning about the identifier, so the baseline 3 applies.

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 the specific resource (a team's roster) and enumerates the fields returned, which lets an agent distinguish it from aura_get_team (team metadata) and aura_list_players (league-wide players). It is a noun phrase rather than a verb+resource statement, and it never explicitly contrasts itself with those 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?

There is no statement of when to use this tool, no prerequisites, and no mention of alternatives such as aura_list_players or aura_get_team. The only routing hint lives in the schema's teamId description ('Aura team id from aura_list_teams'), not in the tool description itself.

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 readOnly/idempotent/non-destructive, so the safety bar is low; the description adds genuinely useful behavior beyond that — the US Pacific league-date default and the id-passthrough contract to downstream tools. It does not mention pagination behavior, though the cursor param hints at it.

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 tight sentences with zero filler, front-loading what is returned before the default behavior and the cross-tool handoff. Every clause carries information an agent needs.

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 no-output-schema list tool, it states the returned shape and the id contract, which is the critical missing piece. Only pagination expectations and the relationship to aura_live_games are unaddressed, which are minor for a filtered list.

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 67%, and the description compensates where it matters: the date default is restated with the timezone nuance ('US Pacific league date'), and team/sport/status filters are described in prose. cursor and pageSize semantics are left entirely to the schema, but those are already documented there.

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+resource ('Games for one day') and immediately enumerates the returned fields (teams, start time, status, score). This clearly separates it from game-detail siblings like aura_get_game or aura_boxscore.

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?

Gives explicit operating guidance: omit date for today, use filters for sport/status/team, and pass returned ids to aura_game_markets for odds. It doesn't explicitly contrast with aura_live_games, which is a near-neighbor for in-progress scores, so it falls short of a full when/when-not statement.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile needs no restating. The description adds only 'a page at a time,' which signals pagination but does not explain page size, how to advance, or when results end. No auth or rate-limit context is given.

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, zero waste, with the scope and pagination model front-loaded and the alternative trailing. Every clause earns 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 simple two-parameter list tool the routing information is adequate, and annotations cover safety. But with no output schema, the return shape is undocumented beyond the cursor's implied page.next reference — an agent cannot tell what a 'player profile' contains or how large a page is.

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 50%: 'cursor' is documented in the schema as 'page.next from the previous call,' while 'sport' carries only a self-explanatory enum. The description adds nothing about either parameter, so the schema does the work. Baseline 3 is appropriate at this coverage level.

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 the resource ('player profiles'), the scope ('a whole sport'), and the delivery model ('a page at a time') in one line, then explicitly names the sibling it is not (aura_get_team_roster). An agent can distinguish this from aura_list_teams, aura_get_player, and aura_get_team_roster without opening any schema.

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?

Gives an explicit alternative with its selecting condition: 'For one team use aura_get_team_roster.' That routes the team-scoped case cleanly. It does not address the single-player case (aura_get_player) or say when to avoid listing an entire sport, so it stops short of full when/when-not coverage.

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 annotations already declare this is a safe, idempotent, closed-world read, so the description doesn't need to argue safety. It adds value by enumerating the returned fields, which matters because there is no output schema, but it says nothing about ordering, pagination, or whether the result set covers all seasons of the sport.

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?

A single, front-loaded sentence fragment with no filler; the resource and the returned fields are both stated immediately. It is appropriately sized for a one-parameter lookup tool.

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 trivial one-param lookup this is close to sufficient, and listing return fields compensates for the missing output schema. It still lacks any note on result size, ordering, or whether the data is season-agnostic, which an agent calling this repeatedly would want to know.

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 is one parameter with 0% schema description coverage, but the schema enforces a closed enum of seven leagues, so the valid inputs are self-documenting. The description only implies the parameter via 'in a sport' and adds no semantics about whether the sport value determines the set of conferences/divisions returned.

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 resource and scope: every team in a given sport, plus the fields returned (ids, names, abbreviations, colors, conference, division). This clearly distinguishes it from the singular aura_get_team and the roster-oriented aura_get_team_roster without naming them. The verb ('list') is only implied by the noun phrase, keeping it from 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?

Usage is implied by 'every team in a sport' — the agent can infer this is the enumeration/lookup tool and that a sport must be supplied. However, there is no explicit when-to-use guidance, no mention of when to prefer aura_get_team for a single team, and no stated prerequisites.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value annotations do not: it discloses what comes back (score plus period or inning) and that results span all sports, which is what an agent needs to trust the payload shape. It does not mention result volume or pagination.

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?

A single sentence that front-loads scope ('every game in progress right now') and then the return content. No 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?

With no output schema and no parameters, the description needs to sketch the return shape, which it does at a high level (score, period/inning). A brief note on ordering or result volume would close the remaining gap, but nothing essential for calling the 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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a param-free tool applies.

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 resource and scope: every in-progress game, all sports. The phrase 'in progress right now' implicitly separates it from sibling list tools like aura_list_games or aura_get_game, but no sibling is named 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?

Usage is implied by the phrase 'right now' - a live-scores lookup - but there is no explicit statement of when to use this versus aura_list_games, aura_get_game, or aura_game_frame, and no 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the two-step discovery behavior around definitionId, which is useful, but says nothing about pagination, result size, or how sparse/dense the series can be.

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 short sentences, zero filler, with the data-shape statement first and the operational instruction second. Nothing could be removed without losing 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 read-only, five-parameter series tool with no output schema, the description covers what is returned (metric time series, with examples) and how to discover available series. Remaining gaps around pagination behavior and entity scoping are minor, so it is close to 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 60% and the description only elaborates on definitionId, which the schema already labels as 'Series id from a call without it'. The optional entityId ('Team or player id') and the limit/cursor pagination pair receive no clarification in the description, so it adds marginal meaning over the 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 names a concrete resource ('time series of in-game metrics for one game') and illustrates it with real examples (win probability, score margin, player lines), so an agent knows the shape of the data. It does not differentiate itself from similar-sounding siblings such as aura_boxscore, aura_game_frame or aura_game_plays, so it falls 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 second sentence gives an explicit workflow rule: call without definitionId first to enumerate available series. That is genuinely actionable guidance beyond 'use this tool for metrics'. It stops short of 5 because it offers no when-not guidance or comparison to the closely related frame/boxscore/plays 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?

The annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false). The description itself offers no additional behavioral context beyond the inherent nature of historical, read-only data.

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 brief and effective. It front-loads the function and provides a helpful, targeted example of its use case in a single concise 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?

While the annotations are comprehensive, the description lacks completeness regarding the temporal boundaries of the data (e.g., how far back the observations go) and parameter intent, which is a noticeable gap given the low schema coverage signal.

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 only 50% schema description coverage, the description fails to add meaningful semantic value. It relies entirely on the schema to define the parameters and doesn't clarify the importance of specific parameters like marketType in filtering the timeline.

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 is highly specific, defining the resource as a timeline of odds movement and the data as timestamped observations. It functions as a clear verbal specification of the API's function.

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 a clear use case ('how has the line moved'), but it does not offer guidance on when this tool should be used relative to the broader suite of aura tools (e.g., when to use this over a simple market snapshot).

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 openWorldHint=true and readOnlyHint=false, and the description is consistent with that: it explains that payment happens outside the agent in a browser and that the connection is upgraded as a consequence. That consequence-of-payment detail is genuinely beyond the annotations, though it doesn't cover failure cases, link expiry, or what state the connection is in before payment.

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 short sentences, front-loaded with what is returned, then the agent's action, then the prerequisite. No repetition of name or title and every clause carries information the agent needs.

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?

No output schema exists, and the description correctly tells the agent that the return value is a URL to hand off rather than data to interpret. What is missing is post-conditions in more detail, such as how to confirm the upgrade succeeded or what the link's validity window is.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Schema is empty with additionalProperties=false, matching the description's claim that nothing needs to be supplied.

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 and resource ('Returns a checkout link for Aura Pro') plus the concrete commercial terms ($20/month, 500,000 requests). This is unmistakably distinct from every sibling, which are all read-only data retrieval 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?

Gives a real precondition ('Needs a verified email first') and an explicit handoff instruction ('Give the link to the user'), which frames this as a human-in-the-loop escalation. It stops short of naming the sibling tools that satisfy the precondition (aura_verify_email / aura_claim_email), leaving that routing 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?

Annotations declare a non-read-only, non-idempotent, open-world call, and the description usefully adds the concrete side effect the annotations cannot: the connection is moved onto the free plan with a 50,000 requests/month quota. Missing is failure behavior (invalid/expired code) and whether the operation can be repeated safely.

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?

One sentence, front-loaded with the verb and resource, with the quota consequence attached rather than buried. No filler or 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 one-parameter mutation with no output schema, the description covers what happens on success but not the workflow context an agent needs: ordering relative to aura_claim_email, behavior on an invalid code, and what the tool returns or whether the plan change is reversible.

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 100% and the single parameter is already documented as "The 6-digit code the user received." The description restates the 6-digit, emailed nature of the code without adding format, validation, or sourcing detail beyond the schema, so the baseline 3 applies.

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 and resource ("Checks the 6-digit code from the user's email") plus the resulting state change (free plan, 50,000 requests/month). It is clearly distinct from aura_upgrade by naming the free tier, but it never explains its relationship to aura_claim_email, which is the likely prerequisite step.

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 is only implied: an agent can infer this is the step after the user receives a code, and that it enrolls the connection on the free plan. No explicit when-not guidance, no mention that aura_upgrade is the alternative for a paid tier, and no stated prerequisite that an email must be claimed first.

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