Cover Signal — Jevan NFL Picks

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious boundary information beyond that: private sources and unrecorded narrative reasoning are explicitly NOT returned, which tells the agent the data scope it cannot expect.

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, no filler, with the audience/scope constraint front-loaded before the returned fields and the exclusion clause. It is tight, though the 'Active members:' prefix is slightly cryptic without explanation.

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 usefully enumerates what a caller gets back and what is withheld, which is the right compensation for a read-only, single-required-parameter tool. It lacks any note on auth/plan requirements beyond 'active members' and no notes on result sizing, so it is solid but not exhaustive.

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 75%: week, season, and market carry inline descriptions with defaults and enum meaning, while pick_id has no schema description. The description adds no parameter-level detail (e.g., candidate IDs come from sibling tools), so this sits at the baseline for high schema coverage.

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 gives a specific verb ('retrieve') and enumerates the resource contents (confidence, spread, total, selected-side price, winning condition, grading context) for a published pick, so an agent knows exactly what it returns. It does not, however, distinguish itself from close siblings like get_pick_record, leaving the agent to infer the boundary.

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?

'Active members:' scopes the audience and the phrase 'published pick' scopes the target, which is a mild contextual cue. But there is no explicit when-to-use versus get_pick_record or get_member_weekly_picks, and no statement of prerequisites or when this tool should be avoided.

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, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: this is a member-gated published board with fixed content rather than generated output, and it tells the agent what is included (exact spreads, recorded odds, confidence). Return format details remain absent.

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, front-loaded sentences that lead with the audience gate and the resource, then the contents, then the exclusion. The middle clause about spreads/odds/confidence is informative rather than filler, and nothing is redundant.

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 correctly compensates by summarizing returned content (spreads, odds, confidence), and annotations cover the safety profile. Member-gating and read-only behavior are both addressed; only edge cases like empty boards or unpublished weeks go unmentioned.

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%, with each of the three parameters documenting its meaning and default, so the baseline is 3. The description echoes the market dimension ('ATS, moneyline, and Over/Under') but adds no syntax or format detail beyond 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?

States a specific verb and resource — retrieve the full published ATS, moneyline, and Over/Under board — plus a negative scope statement ('Does not generate fresh predictions'). Gating is signaled by 'Active members,' which implicitly separates it from get_weekly_free_picks, but that sibling is never named, so the 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?

Gives clear context for use ('Active members... to discuss with your AI') and an explicit exclusion ('Does not generate fresh predictions'), so the agent knows this is a retrieval-only tool for analytical discussion. It falls short of 5 because it never names the free or record-lookup alternatives it overlaps with.

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, and destructiveHint=false, so the safety profile is covered. The description adds that the resource is public and includes 'current data limitations', which is useful scoping context, but it says nothing about size, caching freshness, or whether content is versioned.

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 with no filler. Every listed item (methodology, feedback learning, grading rules, limitations) is distinct and informative.

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 carries the burden of conveying return content — and it does by naming the four sections an agent will receive. For a parameterless read-only docs tool this is largely complete, with only minor gaps around format and length.

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 clarify beyond what the empty schema already shows. Baseline 4 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 (read) and resource (the methodology), and enumerates the content covered: outcome-feedback learning, grading rules, and data limitations. That clearly distinguishes it from the pick-listing siblings, though it never names 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?

Usage is implied rather than stated: an agent can infer this is the reference doc to consult for how picks are graded. There is no explicit when-to-use, when-not-to-use, or routing guidance relative to sibling 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 the safety profile is covered. The description still adds real substance beyond that: it enumerates the returned record types (separate market records, original-price moneyline/totals ROI, settled picks) and, importantly, discloses the privacy boundary that unsettled member selections are withheld.

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 dense sentences with the output inventory front-loaded and the privacy caveat placed last, which is the right ordering. Every clause carries content, though the long comma-list of return types is slightly hard to parse on one pass.

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 usefully enumerates what comes back (per-market records, ROI, settled and free selections) and states the exclusion rule, which is close to what an agent needs. The unexplained season range and lack of sibling routing are the remaining gaps for a read-only tool.

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

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

Schema coverage is 67% with the description restating the market dimension (ATS/moneyline/Over-Under) and the free-pick notion that maps to free_only, so it adds only marginal meaning over the schema. The season parameter has no description in either the schema or the prose, leaving one parameter fully undocumented.

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 ('Read') and resource (Jevan's published ATS/moneyline/Over-Under records, ROI, settled and free selections), so the agent knows exactly what is returned. It does not, however, contrast itself with nearby siblings such as get_weekly_free_picks or get_member_weekly_picks, which overlap on the 'free selections' surface.

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 choose this tool over the four sibling tools, even though get_weekly_free_picks clearly overlaps with the free_only parameter and 'free selections' output. The only boundary given is a privacy rule about unsettled member selections, which is a scope note 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the description only needs to add context. It does: the agent learns the response carries provisional-or-final status, revision history, timestamps, and source URLs, which is meaningful behavioral detail about the data's volatility and provenance.

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, front-loaded with the core action and resource; the second sentence is short and additive. The first sentence is long and list-heavy, but every listed field earns its place by describing the payload.

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-required-param, read-only retrieval tool with no output schema, the description covers what comes back (picks, status, revision history, URLs) and how to narrow results. The main omission is routing versus sibling pick tools, which is a usage gap rather than a completeness 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 100%, so week/season defaults and the market enum are already fully documented in the schema. The description's 'filter by market' adds nothing beyond that. Baseline 3 is appropriate when structured data does the heavy lifting.

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?

Specific verb (retrieve) plus resource (weekly free ATS/moneyline/Over-Under picks) and a full inventory of the payload (spreads/prices, provisional vs final status, revision history, timestamps, source URLs). The 'free picks' qualifier functionally distinguishes it from the sibling get_member_weekly_picks without needing to name it.

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 only usage cue is 'Filter by market if desired,' which restates the schema default rather than telling the agent when this tool is the right choice. There is no mention of when to prefer it over get_member_weekly_picks, get_member_pick_context, or get_pick_record, and no exclusions.

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