internal_hltb_v1

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

With no annotations provided, the description must carry the behavioral disclosure burden. It discloses the HTTP method and API key requirement (including environment variable names), but omits return format, error behavior, rate limits, or what the overview includes. The pointer to a guide is helpful but not a substitute for inline disclosure.

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 concise and well-structured: endpoint, purpose, required parameter, authentication, and pointer to documentation. Each sentence earns its place with no filler, making efficient use of space.

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?

Although there is no output schema and the tool has nested parameters, the description is too minimal for an agent to invoke it confidently. It lacks details on response format, optional parameters, potential errors, and the meaning of appid. The link to itad://guide/calling partially compensates, but it does not replace inline completeness.

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 high (100% for top-level parameters), so the baseline is 3. The description adds value by specifying the required query parameter 'appid' and highlighting the API key requirement, but it does not clarify the semantics or acceptable values of appid beyond what the schema's type union already provides.

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 HTTP verb (GET) and resource (HowLongToBeat Overview), clearly identifying the tool's function. The name includes 'hltb' and the description mentions 'HowLongToBeat', distinguishing it from sibling internal_* tools, though 'Overview' is somewhat vague about the specific data returned.

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 implies usage for retrieving HowLongToBeat overview data via appid, and points to a guide for full instructions, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools exist for other internal data sources, but no comparison or guidance is given.

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