The White Report

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 genuine value by enumerating payload contents (facts, sources, call, full text), which tells an agent this is a heavy full-body response rather than a summary. It says nothing about error behavior for unknown slugs or response size, which matters for a full-text fetch.

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 with the key qualifier ('full') front-loaded and a compact parenthetical enumerating contents. No waste, though the parenthetical is doing param/return work rather than the main clause.

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, annotation-covered read tool with no output schema, the description gives enough to call it correctly and to predict roughly what comes back (full text plus structured facts and sources). Only the absence of any failure-mode or sibling-routing note keeps it below 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 100%: the single slug parameter is documented in the schema with a concrete example. The description adds no further meaning about slug format, derivability from URLs, or case sensitivity, so it sits at the baseline for a schema-complete 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?

States a specific resource and a specific retrieval mode: the 'full machine-readable article' as the 'JSON twin' of the rendered page. The word 'full' implicitly contrasts with the trimmed results of search_articles, but no sibling is named outright, so differentiation is left 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?

Usage is only implied: an agent can infer this is the fetch-by-slug step after discovering a slug elsewhere. There is no explicit when-to-use, no mention of search_articles as the discovery alternative, and no stated preconditions such as a missing or stale slug.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond them by enumerating the returned fields (headline, summary, dates, URLs), which matters because there is no output schema; it stops short of stating ordering guarantees or total-available counts.

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 most decision-relevant word ("Newest") is front-loaded. It is arguably over-compressed, since the field list consumes the space that could have carried usage guidance.

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 tool with rich annotations, the definition covers purpose, scope, and return shape. The only meaningful gaps are behavioral edge cases — ordering guarantee and empty-result behavior — which are minor given the tool's simplicity.

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% — the single `limit` parameter is fully documented with range (1-20) and default (5). The description adds no additional meaning about the parameter, 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 (White Report articles) with an explicit recency scope ("Newest") and names the payload fields returned. It implicitly distinguishes itself from search_articles by being recency-ordered rather than query-driven, but never names that sibling, 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 the word "Newest" — an agent can infer this is the browse-what's-recent tool versus search_articles for query-based retrieval, but there is no explicit when-to-use or when-not-to-use guidance and no mention of what happens when there are no new articles.

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 behavior. The description adds real value by disclosing that grade may be null while pending, which the annotations cannot convey. However, it says nothing about payload size, ordering, or pagination for a tool returning every call ever made, which is a meaningful gap for a full-history listing.

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 dense sentence that front-loads the scope ('Every dated public call') and then the returned fields. No filler, no restatement 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?

With no input parameters and no output schema, the description carries the burden of describing return values, and it does so adequately (call, grade date, grade with null-pending semantics). Minor gaps remain around result ordering and volume for an unbounded 'every call' listing.

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. The description correctly implies no filtering inputs are available.

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?

Names the resource (scoreboard) and enumerates its contents precisely: every dated public call, its grade date, and its grade. This differentiates it from siblings like get_article and search_articles by establishing it is the exhaustive record of graded calls. The retrieval verb is only implied by the name rather than stated in the description.

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 'Every dated public call' implies exhaustive scope, which contrasts with the filtered sibling search_articles, but no alternative is named and no when-to-use/when-not-to-use condition is stated. The agent must infer that this is the full-history view.

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. The description adds a modest amount — it states what the payload contains and that a snapshot timestamp is included (useful freshness signal) — but says nothing about ordering, refresh cadence, or how many metrics are returned, which matters most given no output 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?

A single short clause with the resource and its contents front-loaded, zero filler, nothing repeated from the title or 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?

With no parameters, no output schema and full annotation coverage, the only real burden is telling the agent what comes back — crypto top 5, AI stocks, metrics, timestamp — which it does. It is only slightly thin on response shape/ordering, which is forgivable for a fixed snapshot.

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?

Zero parameters, so there is nothing parameter-side to explain and the baseline applies. The description correctly does not waste words on arguments.

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 (market snapshot) and enumerates its contents — crypto top 5, AI stocks, metrics, plus a timestamp — which is enough to distinguish it from the article/scoreboard siblings. The verb is implicit (it's a fetch of a snapshot), so it stops just short of the 'specific verb + resource' bar.

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 infers 'call this when you need a current market overview.' There is no explicit when-to-use, no exclusion versus get_scoreboard or get_latest, and no note that it takes no filters, so the agent must reason from the content list.

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 read-only, idempotent, closed-world semantics, so safety is covered. The description adds the scope of the searchable fields, which is genuinely useful, but says nothing about result ordering/relevance, what happens with zero matches, or whether matching is exact or fuzzy.

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 the verb-resource pair first and the field scope as parenthetical detail. No filler, nothing 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?

For a simple two-parameter read tool with full annotation coverage, complete schema descriptions, and no output schema, this is nearly sufficient. The only gap an agent might want is how results are ranked/ordered, but that 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%, so both 'query' and 'limit' are already documented in structured fields. The description's field list adds some meaning about what 'query' matches against, but adds nothing about limit behavior beyond the schema's range and default.

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 ('Search') plus resource ('article archive'), with an enumerated set of searchable fields (headline, summary, key facts, entities, tickers) that tells an agent what kind of matching to expect. It doesn't explicitly contrast with get_article or get_latest, so the sibling differentiation is only 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?

Usage is only implied: 'by keyword' suggests you use this when you don't have an identifier, versus get_article (by id) or get_latest (browse). No explicit when-to-use / when-not-to-use statement or named alternative routing is given.

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