read_workspace_text

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's one added behavioral fact is that the SHA-256 is intended for a later checked edit, which hints at optimistic-concurrency semantics. It says nothing about truncation, pagination, or what happens at file boundaries.

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 dense sentence with the core action front-loaded and no filler. It is efficient, though the trailing 'for a later checked edit' clause is slightly compressed for the amount of meaning it carries.

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?

Because there is no output schema, the description usefully states that the return is text plus a SHA-256 hash. But it leaves the paging behavior of start_line/max_lines and any truncation semantics entirely undocumented, which is a real gap for a 3-parameter 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 0% and all three parameters (path, max_lines, start_line) have only bare titles. The description never mentions path or the line-windowing parameters, so an agent gets no help understanding that start_line/max_lines page through the file. With low coverage the description is expected to compensate and does not.

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 (read) and resource (local Lua/XML/code/documentation text), and adds that it returns the text plus its SHA-256. That clearly separates it from siblings like read_wiki_page or inspect_file, though it never names an alternative 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?

The phrase 'for a later checked edit' implies this is a read-before-write step paired with write_workspace_text, which is useful contextual guidance. However, there are no explicit when-to-use/when-not-to-use rules and no named alternatives, so the routing 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.