deck_text

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

With no annotations, the description carries the behavioral burden: it discloses the numbered output format, that decks are plain ASCII, that no WSL is needed, and how file matching against the resolved INCLUDE tree works. It stops short of describing edge cases or line-numbering semantics, but the core behavior is transparent.

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?

Three sentences: main purpose, when to use, and file-parameter behavior. Each sentence adds distinct value and the key behavior is front-loaded.

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 description covers purpose, use case, and include-file selection, and an output schema exists so return details need not be spelled out. However, the under-documented parameters and lack of guidance relative to sibling text/deck tools leave the definition only moderately 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 must compensate, but only the file parameter is explained in depth. deck_path, n_lines, and start_line are left to their schema titles/defaults, and the description does not clarify their interaction, such as inclusive range or 1-based indexing.

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 opening phrase 'Numbered text slice of a deck (or one of its include files)' clearly names the resource and output form. It does not explicitly contrast with siblings like deck_grep or summarize_deck, though the alternative to host-shell head/sed helps position it.

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?

It explicitly says to use this instead of host-shell head/sed when a client misdetects .DATA as binary, which is a concrete when-to-use condition. It does not discuss when not to use it in favor of MCP sibling tools such as deck_grep.

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