read_mode7_text

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

No annotations are present, so the description carries the full burden. It thoroughly explains the behavior for non-printable bytes under each 'controls' option (row width, visual representation, byte preservation), and discloses the return format (raw row list and joined string). It also discloses the Pydantic wire-boundary rejection of unknown enum values. It does not discuss error handling for an invalid session_id or what happens if MODE 7 is not active, but the disclosed behavior is substantial and accurate for a read tool.

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 front-loaded with the core purpose, then uses a clean bulleted list for the 'controls' options. Each sentence earns its place: the first sentence gives the high-level function, the bullets explain parameter behavior, the JSON/Pydantic paragraph clarifies wire-format expectations, and the final sentence summarizes return values. No redundant filler.

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?

Given the tool's complexity (2 params, no annotations, but an output schema), the description is quite complete. It covers the main parameter behavior, return format, and coercion logic. The missing explanation of session_id is the primary gap, and it could also benefit from a note about when the screen is in MODE 7 vs. other modes. Nevertheless, most necessary information for invocation is present.

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. It does so excellently for the 'controls' parameter, detailing the three enum values, their display effects, and caller considerations. However, it never explains 'session_id'—not its purpose, format, or relationship to the machine/session. Since session_id is required, its omission is a clear gap. The description covers only 50% of parameters meaningfully.

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 opens with a clear, specific verb-object statement: 'Capture the MODE 7 screen as 25 rows of teletext text.' This verb ('capture') distinguishes it from sibling tools like screenshot (visual capture) or read_memory (raw memory access), and the result (25 rows of text) is unambiguous.

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 usage: if you need MODE 7 screen text, this is the tool. It does not explicitly contrast with alternatives (e.g., 'use screenshot for graphics' or 'use read_memory for raw bytes'). However, it does provide guidance on choosing between the 'controls' values (e.g., 'best for substring assertions' vs. 'when callers need the original byte value'), which is a form of usage guidance for parameter selection. No exclusions or when-not-to-use conditions are given.

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