hcm_get_atom_entry

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

Annotations already declare readOnlyHint=true, matching the read-only 'Get' verb; there is no contradiction. The description adds little beyond what the annotation conveys, however—it does not disclose what an Atom entry is, how it relates to Atom feeds and checkpoints, what happens on a miss (e.g., null vs error), or whether pagination/replay behaviors apply. With the safety profile carried by annotations, a 3 baseline 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?

A single sentence that front-loads the verb and resource, with zero filler or repetition of the tool name. Every word contributes 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?

The tool has no output schema and sits inside a dense Atom-related sibling cluster (feeds, poll, consume, checkpoints, list_entries). The description does not suffice for an agent to understand how this single-entry fetch relates to those flows or what the returned entry contains. For such a simple call shape it is acceptable, but the missing ecosystem context and absence of any return-value hint keep it below complete.

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 0%, so the description carries the full burden for the single entryId parameter. It does tell the agent that the ID is an EntryId that identifiers the Atom entry, which adds meaning beyond the raw schema type. However, it does not specify the value format, whether the ID is globally unique or feed-scoped, or how to obtain a valid EntryId (e.g., via hcm_list_atom_entries), leaving a gap the schema cannot fill.

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 a specific verb ('Get'), a distinct resource ('a single Atom entry'), and the identifying mechanism ('by EntryId'). This clearly differentiates it from the sibling hcm_list_atom_entries (plural listing) and hcm_atom_poll/consume (processing flows), which is exactly what a retrieval-by-ID tool should convey.

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?

No guidance is given on when to use this tool versus its many Atom-related siblings (hcm_list_atom_entries, hcm_atom_poll, hcm_atom_consume). The description does not say it's the right choice when you already know a specific entry ID, nor does it clarify how it fits into the feed/checkpoint workflow. An agent must infer all usage context from the name alone.

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