e/acc

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. Against that lower bar the description adds genuine value by spelling out the return structure — one row per capability threshold with price, cost-decline multiple, and halving time — which matters because no output schema exists. It does not say how fresh the index is or whether it is a fixed published artifact or recomputed on each call, which is the main remaining behavioral 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 front-loaded sentence introduces the index and then lists its fields in a parallel structure that is easy to parse. It is dense but every clause carries content; only the nested parenthetical about blended USD pricing verges on over-compression.

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?

A zero-argument read tool with no output schema places the burden of describing returns entirely on the description, and it meets that burden by naming all three per-threshold values plus the unit basis. What is missing is metadata an agent would want before calling: data recency and the source of 'first-party API price'. That is a modest gap rather than a blocking one.

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 zero parameters there is nothing to disambiguate, so the baseline of 4 applies. The description does not waste words re-describing an empty schema, which 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 names a specific artifact — a 'cost-of-intelligence index' — and enumerates the three quantities it reports per GPQA Diamond threshold: cheapest first-party blended API price in USD per million tokens, the improvement multiple, and the months-to-halve figure. That is specific enough to distinguish it from the news-oriented siblings (daily/weekly/monthly/story/search). It stops short of an explicit verb or a direct contrast with any sibling, so it is clear but not fully differentiated.

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 to reach for this index versus eacc_get_latest, eacc_get_monthly, or eacc_search. The description is a noun phrase describing the payload, not an instruction, so an agent must infer that this is the tool for AI-price-versus-capability analysis. No exclusions, preconditions, or alternative routing are offered.

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 open-world behavior, so the safety profile is covered. The description adds that the content is an 'edited' overview rather than raw entries, which is genuine context, but it says nothing about edition availability handling or limits beyond what the schema already documents.

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 action and scope, then the usage cue. No filler, no repetition of the schema, and nothing that could be trimmed 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?

For a two-optional-parameter read tool with full annotation coverage and full schema descriptions, the description covers purpose, selection rule, and content nature adequately. There is no output schema, but the phrase 'edited daily overview' gives enough sense of the return shape that nothing essential 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 100%, so both parameters are already fully documented, including the enum and the edition_unavailable behavior. The description reinforces that the date must be a 'real' YYYY-MM-DD and that omission yields the latest, but adds no syntax or format detail beyond the schema — baseline 3.

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 ('Get e/acc's edited daily overview') plus the scope of what can be requested (latest issue or a dated one). It implicitly separates itself from a raw chronological feed, which differentiates it from eacc_get_latest, though it never names that 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?

'Use this when the user asks for a daily report rather than a raw chronological list' gives a clear selection condition and a contrast case. It stops short of naming the alternative tool or stating when to prefer weekly/monthly siblings, so it is not a full when/when-not map.

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 open-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: ranks are one-based, the IDs returned are valid story public IDs usable downstream, and internal heat scores are deliberately withheld from the response. It does not mention edition_unavailable behavior, though the schema parameter description carries that.

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 the action and resource, then the selection guidance, then the one output caveat an agent would otherwise get wrong. Nothing is repeated from the schema and no sentence is 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?

For a two-optional-parameter read tool with no output schema, this covers everything needed: what is returned (top 10 with one-based rank), what is not (internal heat scores), and what the identifiers can be used for. Annotations already handle the safety profile, so no important gap remains.

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 both parameters (lang enum with default and edition_unavailable semantics, limit 1-10 with default) are fully documented in the schema itself. The description adds no parameter meaning beyond that, 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 and resource ("Get the current e/acc Top 10") plus the exact shape of the result ("each event's one-based rank"). It explicitly names the sibling eacc_get_latest as the contrasting tool, 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 selection rule: use this for "what is hot now" and for discovering valid story public IDs, and use eacc_get_latest for a chronological news list. That is a when-to-use plus a named alternative with the condition that selects 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered and the burden is lower. The description adds the editorial-vs-complete distinction of the result set, which is genuine behavioral context, but says nothing about freshness, whether editions are pre-generated, or what a caller gets when data is missing beyond what the lang schema entry already states.

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: purpose, default preference, exclusions. The scope statement is front-loaded and no sentence is redundant with the title or schema. Nothing could be cut without losing routing 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?

With no output schema and five optional parameters, the description should carry more weight on what comes back (fields, ordering, pagination versus the 30-item cap). It covers selection scope and exclusions well but leaves the return shape entirely undefined, which is the main gap for a retrieval tool of this complexity.

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 schema descriptions are unusually rich (enum meanings, defaults, edition_unavailable behavior, limit bounds), so the schema carries the parameter explanation. The description's one contribution is advising the selected default over all, which is a policy hint rather than new meaning for window, limit, or category. Baseline 3 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 ("Get the latest e/acc items") and scopes the result set to a 24-hour or 7-day briefing, so the agent knows what it returns. It partially differentiates from siblings by excluding named-topic search (eacc_search) and multi-source event context. However, it never addresses its overlap with eacc_get_daily and eacc_get_weekly, which an agent selecting among these will immediately wonder about.

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 an explicit default preference ("Prefer selected mode unless the user explicitly asks for every public item") and two explicit exclusions with the alternative use case named. What it lacks is naming the sibling tools to route to instead of only describing the excluded capability, leaving the agent to guess that eacc_search is the target.

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, so the safety profile is covered. The description adds useful structure about the result (edited curation of dailies, section grouping, overview) and the default-to-latest behavior, but says nothing about report size, date coverage limits, or what happens for a month with no 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?

Two tightly written sentences, front-loaded with the resource and its contents before moving to usage. No filler or redundant phrasing.

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-optional-parameter read tool with full annotation coverage and no output schema, the description does everything needed: it explains the curation model, the section/overview structure of the result, and the default behavior when month is omitted.

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 `month` parameter is fully documented in the schema, including format and the omit-for-latest rule. The description's 'omit month for the latest' largely restates the schema rather than adding new meaning, so baseline 3 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?

States a specific verb and resource ('Get e/acc's edited monthly report') and specifies its contents: the month's most important events drawn from dailies, grouped by section, plus an overview. The aggregation level implicitly separates it from the daily/weekly siblings, though no sibling is named directly.

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: 'Use this for what happened this month or in a given month; omit month for the latest.' That resolves the main selection ambiguity (current vs. historical). It stops short of naming alternatives such as eacc_get_daily or eacc_get_weekly for guidance on when not to use this tool.

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 open-world behavior, so the safety profile is covered. The description adds only that the result is scoped to a single story and lists its sections; it does not mention the edition_unavailable failure mode or that content is a stored snapshot rather than live, both of which would be genuinely new context beyond the 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?

Two sentences with no filler; the payload contents come first and the ID-hygiene constraint follows. 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?

With no output schema, the description usefully enumerates the returned sections so the agent knows what it will get, and the single required parameter is covered in the schema. Only minor gaps remain, such as how editions or timeline truncation behave, but nothing blocks a correct 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?

Schema description coverage is 100%, so public_id, lang, and report_limit are all already documented, including the 'never guess it' rule. The description restates the ID provenance constraint rather than adding syntax, format, or edge-case meaning, 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 verb ('Get') and resource ('one public story') and enumerates the returned content: evolving timeline, latest development, AI digest, related events. The mention of eacc_get_hot_topics as the ID source implicitly separates it from the sibling that lists stories, so an agent can choose between them 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 precondition for invocation: the public_id must come from eacc_get_hot_topics links.story, and IDs must never be invented or inferred. It names the upstream tool clearly but does not state when this tool should be preferred over, say, eacc_search, so it stops short of full when/when-not 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 declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds meaningful context beyond that: the report is curated/edited rather than raw, it is organized by section with an overview, and omitting the week yields the latest. It does not discuss pagination or size, but for a read-only report tool this is solid.

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 what the tool returns and followed by when to use it and the default. No filler or redundant restatement of the 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 one-optional-parameter read tool with rich annotations and no output schema, the description covers purpose, usage, default behavior, and the rough shape of the return (sections plus overview). Only finer return details are absent, which is acceptable 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 coverage is 100% and the schema already documents the ISO week pattern and the omit-for-latest default. The description reinforces the default behavior and the ISO-week semantics in prose, adding a little clarity for the single optional parameter, though it introduces no format details 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?

The description names a specific verb and resource ('Get e/acc's edited weekly report') and characterizes the content precisely: events chosen from dailies, grouped by section, with an overview. The phrase 'chosen from its dailies' implicitly separates it from eacc_get_daily, so an agent can distinguish it from siblings without opening a 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?

It states the use case explicitly ('Use this for what happened this week or in a given ISO week') and gives the default behavior ('omit week for the latest'). It does not name the alternative tools (eacc_get_daily, eacc_get_monthly) or state when not to use it, which keeps it 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?

Beyond the annotations (which already declare read-only, idempotent, non-destructive, open-world), the description discloses a genuinely useful behavior: results come from editorial picks first and expand to all public items only when picks return nothing. That fallback semantics is not derivable from the schema or annotations, though result ordering/pagination after expansion is still unstated.

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 compact sentences with zero filler: the scope constraint is front-loaded and the fallback behavior follows. Nothing repeats the schema or annotations verbatim.

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, single-query search tool with full schema descriptions and complete annotations, the description covers scope and the result-tier behavior sufficiently. Missing only minor details such as how to page past the limit or how window interacts with the 'latest 7 days' framing.

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 schema already documents q, lang, limit, window, and category, including enum values and defaults. The description only adds a hint about what kinds of entities the query string accepts (topic, company, model, product, or person), which is marginal value over the existing field description.

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 (search) and resource (e/acc's latest 7 days), plus the query domain (topic, company, model, product, person). That distinguishes it from the sibling 'get_*' retrieval tools, which appear to fetch predefined slices rather than run a query, though 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?

Implicit guidance is present: use this to search by topic rather than to browse predefined editions like eacc_get_latest or eacc_get_daily. However, it never states when not to use it or names an alternative sibling, leaving the agent to infer the split from tool names 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations — no key or credit is consumed — but says nothing about caching/refresh cadence for 'today' or what the response actually contains.

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 the time scope ('Today's') front-loaded and zero filler. Every clause carries information, and nothing is buried after extraneous preamble.

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 tool is simple enough that the description is close to sufficient. Still, the phrase 'preview and product page' does not tell the agent whether it receives an image, a JSON payload or a URL, and the lack of sibling differentiation leaves routing 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the schema leaves nothing undocumented. The description correctly avoids inventing arguments that do not exist; the baseline of 4 applies for a parameterless 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 names a specific resource (today's wallpaper) and what the caller gets (public preview plus product page), which is more concrete than the bare tool name. It does not, however, distinguish itself from similarly named siblings such as eacc_get_daily or eacc_get_latest, leaving some ambiguity about whether 'today's wallpaper' is the same content as the daily feed.

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 and no mention of alternatives among the eight sibling tools. The only usage-adjacent claim is that no key or credit is required, which tells the agent nothing about when this tool is preferred over eacc_get_daily or eacc_search.

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