codex_read

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

Annotations already mark this as read-only and not open-world; the description adds extra behavioral context by stating that the returned body is limited to Skill/说明载体 and that a configured mode returns a safe summary. No contradiction exists between the description and annotations.

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 dense sentence packs the primary action, the resource, and the key constraints without wasted words. The slight deduction is due to unexplained domain terms that force an agent to decode meaning rather than absorb it immediately.

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 readonly tool with an output schema, the description is mostly complete: it identifies the source of the id, the read-only nature, and body constraints. It falls short only because 'Skill', '说明载体', and '安全摘要' are not expanded, so a cross-domain agent may still be unsure what exactly will be returned.

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 0% schema coverage, the description must explain the single 'id' paramter. It does so by identifying the id as an observation identity returned by codex_list, which gives an agent a way to obtain the value. It is not a 5 because it fails to define what an observation identity looks like or how it is formatted.

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 uses a specific verb ('读取') and names a concrete resource ('codex_list 返回的观察身份'), which helps distinguish it from list/import siblings. It is not a 5 because phrases like '正文限于 Skill 和说明载体' are jargon-heavy and leave the exact read target somewhat ambiguous for an agent unfamiliar with the domain.

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 the intended workflow: first call codex_list, then read one of the observation identities it returns. However, it does not explicitly state when to choose this tool over codex_groups, module_describe, document_read, or other read-style siblings, nor does it give any 'when not to use' guidance.

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