Get Page Content

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

With no annotations, the description must fully disclose behavior. It does add notable context such as 'this tool just returns raw text' and 'Claude Code handles all reasoning,' which clarifies it is a dumb read-only operation. However, it doesn't disclose potential ambiguity when providing both node_id and page parameters, nor error behavior for unindexed or missing documents. The description covers the core behavior but leaves these edge cases unaddressed.

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 two sentences that are front-loaded with purpose and immediately provide a workflow hint. There is no redundancy or filler; every word adds value. This is an exemplary concise structure.

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?

Despite having no output schema, the description states it returns raw text, which is a minimal but valid return explanation. It also captures the indexing prerequisite and the expected workflow with get_document_tree. It falls short of explicitly explaining parameter exclusivity (node_id vs. pages) or edge cases, but given the simplicity of a content-extraction tool, this is fairly 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?

The schema already provides 100% parameter description coverage, including the note for node_id to 'use get_document_tree to find IDs.' The description adds little new information, only a general mention of 'specific pages or a tree node.' While this reinforces the parameter usage, it doesn't significantly deepen the schema's existing guidance, so a baseline score is appropriate.

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 starts with 'Extracts text content from specific pages or a tree node of an indexed document,' which clearly identifies the action (extracts) and the resource (text content from an indexed document). This distinguishes it from sibling tools like get_document_tree (which returns structure) and index_document (which indexes), making the purpose unmistakable.

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 instruction 'Use get_document_tree first to find relevant node_ids, then call this to read the content' provides an explicit workflow and places the tool in a sequence. It doesn't explicitly state when not to use it, but the complementary relationship with get_document_tree and the contrast with other siblings (list, delete) is clear. This is solid guidance without being overly verbose.

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