AIHOT

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

Annotations already cover the safety profile (readOnly, idempotent, open-world, non-destructive), but the description goes beyond them by disclosing the shape and categories of the result (waiting announcements, 7-day window, last landed one) and the evidence types involved. With no output schema, this added return-context is genuinely useful; it stops short of describing structure 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?

Two tightly written sentences, front-loaded with the verb and resource, then a colon-delimited scope list. The closing sentence is a directive to the caller rather than a description, which is slightly unusual, but it is short and carries real signal about interpretation.

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, so the description bears the burden of explaining what comes back; it does so at the category level (pending / 7-day / last landed, each with evidence) and warns about evidence gradations. What is still missing is the concrete result structure or field-level detail, but the essential orientation for a parameterless read tool is present.

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 the baseline is 4. The description correctly adds no parameter guidance because there is none to give, and schema description coverage is nominally 100%.

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 ("Get Tibo's Codex usage-limit resets and reset credits") and then enumerates the exact scope of the payload: pending announcements, last 7 days, last landed one. This sharp niche is immediately distinguishable from the generic aggregation siblings (daily/weekly/monthly/latest/search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes clear what the tool is about, so an agent can infer when it applies, but it never states when to use it versus an alternative such as aihot_search, nor does it give any exclusion or prerequisite. Usage is implied rather than prescribed.

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 openWorld, so the safety profile is covered. The description adds that the content is 'edited' (curated rather than raw), but says nothing about what the report contains or its size/format; with annotations carrying the behavioral load, a 3 is appropriate.

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 padding, and the what/how (latest vs date) is front-loaded before the when-to-use clause. Every phrase 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 one-optional-param read tool with annotations covering safety and no output schema, the description covers what it returns at a high level and when to call it. Only the nature/contents of the 'edited daily overview' is left unstated, a minor 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 coverage is 100% — the sole optional 'date' param already documents the YYYY-MM-DD pattern and the omit-for-latest behavior. The description only echoes that same rule plus 'real' date emphasis, adding no new syntax or validation 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 ('Get AIHOT's edited daily overview') with the accepted inputs (latest or YYYY-MM-DD). It also distinguishes itself functionally from a raw listing tool via 'rather than a raw chronological list', though it never names which sibling that is.

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?

Explicitly says when to use it: 'when the user asks for a daily report'. It implicitly contrasts with the raw chronological list tool, but does not name get_latest or explain when to pick one over the other, so the routing guidance is clear but not fully decisive.

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 behavioral context beyond that: ranks are one-based and internal heat scores are deliberately not returned, which prevents an agent from promising that field. It stops short of describing pagination or ordering guarantees.

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 purpose and rank detail come first, with the alternative-tool routing tucked into the second sentence where it belongs.

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, so the description has to carry return-value information, and it does so for the two attributes that matter most (rank semantics and the absence of heat scores). It does not spell out the full event payload shape, which is the only remaining gap for a single-optional-param read tool.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented with bounds and default in the schema. The description only indirectly touches it via 'Top 10', adding no syntax or format detail. Baseline 3 is correct when the schema 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?

States a specific verb and resource ('Get the current AIHOT Top 10') plus the shape of the payload (each event's one-based rank). It explicitly positions itself against the sibling aihot_get_latest, so an agent can disambiguate 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 both the positive trigger ('what is hot now') and a secondary use case (discovering valid story public IDs), and names the alternative tool plus the condition that selects it ('use aihot_get_latest for a chronological news list'). Nothing is left 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 already declare read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds scoping context (editorial vs. all public items) but says nothing about result ordering, freshness guarantees, or empty-result behavior for a briefing tool that could plausibly return nothing in a quiet 24h window.

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 first, then the default-mode rule, then the exclusions. No restatement of schema and 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?

For a simple zero-required-parameter read tool with full schema descriptions and no output schema, this is mostly sufficient. The remaining gap is sibling disambiguation against the daily/weekly/hot-topics briefing tools, which an agent choosing among seven aihot_* tools genuinely needs.

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 explains mode, limit, window and category. The description nonetheless adds selection guidance for the mode parameter ('prefer selected unless the user explicitly asks for every public item') that the schema's neutral 'selected returns editorial picks' does not convey.

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 clear verb and resource ('Get the latest AIHOT items') plus the supported windows ('24-hour or 7-day briefing'), so the agent knows it returns a recency-scoped list. It explicitly distances itself from named-topic search, but leaves the overlap with siblings aihot_get_daily and aihot_get_weekly unaddressed, which keeps it below 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?

Gives an explicit default preference ('Prefer selected mode unless the user explicitly asks for every public item') and two exclusions ('Do not use this for named-topic search or multi-source event context'). Missing is guidance on when to pick this over aihot_get_daily/aihot_get_weekly/haihot_get_hot_topics, the closest alternatives.

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 safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint). The description adds that the report is curated/edited from dailies and grouped by section, which sets expectations about coverage and shape, but says nothing about auth, rate limits, or freshness/latency of the underlying 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 sentences, no filler: the content summary comes first and the usage/default rule follows. Every clause carries information an agent needs to select and call the 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 single-optional-parameter read tool with rich annotations and no output schema, the description covers what the tool returns conceptually and how the default resolves. Missing only peripheral detail such as how sections are enumerated or how much history is available.

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 optional parameter with 100% schema description coverage, including the YYYY-MM pattern and the omit-for-latest behavior. The description merely restates the omit-month default and adds no format or boundary 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?

The description names a concrete verb and resource ("Get AIHOT's edited monthly report") and characterizes the content: the month's most important events drawn from its dailies, grouped by section, with an overview. That implicitly separates it from aihot_get_daily/aihot_get_weekly, though it never names those siblings 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?

It states the use case directly ("Use this for what happened this month or in a given month") and gives the default-selection rule ("omit month for the latest"). It lacks explicit exclusion guidance such as when to prefer aihot_get_weekly or aihot_get_daily instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by enumerating the return content (timeline, latest development, AI digest, related events), which matters since there is no output schema. It stops short of noting cost, rate limits, or error behavior for invalid IDs.

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, and the high-value content (what is returned, where the ID comes from) is front-loaded. 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 read-only single-story lookup with full schema coverage and no output schema, the description adequately covers scope, return content, and ID provenance. Only minor gaps remain, such as how report_limit affects the timeline output.

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 documented in the schema, including the same 'final path segment of links.story' sourcing rule. The description reinforces the ID provenance but adds no syntax or format 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 ('Get') and a specific resource ('one public story') plus the exact content returned: timeline, latest development, AI digest, related events. This clearly distinguishes it from siblings like aihot_get_hot_topics or aihot_get_daily, which operate on aggregates rather than a single story.

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 strong precondition guidance: the tool applies to one public story and the public_id must come from aihot_get_hot_topics links.story, with an explicit prohibition on inventing IDs. It does not, however, name alternative tools for other retrieval scenarios or state when not to use this one.

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 this a read-only, idempotent, non-destructive, open-world call, so safety is covered. The description adds genuine behavioral context beyond that: the report is editorially curated, section-grouped, and includes an overview, which tells the agent what kind of content to expect. It stops short of noting pagination, size, or behavior when a week has no report.

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, front-loaded with the resource and content shape, followed by the usage condition. Every clause earns its place with 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 simple one-parameter read tool with full annotation coverage, the description covers purpose, content structure, and parameter behavior. Minor gaps remain around failure modes (invalid or non-existent week) and whether a report is guaranteed for every week, which an agent might need.

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 already documents the ISO week format and the omit-for-latest behavior. The description's 'omit week for the latest' restates the schema rather than adding syntax or edge-case 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 verb and resource (get AIHOT's weekly report) and describes the payload composition: curated events from the dailies, grouped by section, with an overview. The phrase 'chosen from its dailies' implicitly distinguishes it from aihot_get_daily and aihot_get_monthly, so an agent can route without opening sibling schemas.

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 clear usage condition: use it for 'what happened this week or in a given ISO week' and omit the parameter for the latest. It does not name alternatives (e.g. aihot_get_daily for a single day) or state exclusions, so it falls just short of the explicit when/when-not/alternatives bar.

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. The description adds real behavioral context beyond them: the two-stage retrieval (editorial picks first, automatic expansion to all public items only on empty results), which affects result interpretation and is not in any structured field.

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 padding, and the escalation rule is front-loaded right after the core search statement. 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 should carry more of the burden, but it does cover the query scope, the temporal window, and the fallback behavior. Minor gaps remain around result shape and how limit interacts with the two-stage search, but nothing blocking for invocation.

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

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

Schema description coverage is 100%, so both query semantics and limits are already documented in the schema; the description's breakdown of acceptable query subjects ('topic, company, model, product, or person') adds modest value. It also says the window is 'latest 7 days,' which only partially matches the schema's 24h/7d window enum and could mislead an agent away from the 24h option.

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 (search) and resource (AIHOT items from the latest window), and the 'editorial picks first' framing distinguishes it from retrieval siblings like aihot_get_latest or aihot_get_daily. It stops short of naming any sibling directly, so the distinction is inferable 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?

It gives a clear context of use (query by topic, company, model, product, or person), which implies 'use this when you have a search term.' However, it offers no exclusions or alternatives, leaving the agent to guess how it differs from aihot_get_latest or aihot_get_hot_topics when no specific term is needed.

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