ipc_read_file

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower, and the description still adds real behavioral context: the transfer goes over ADS with no SMB share required and binary content is returned base64-encoded. It omits truncation/size behavior tied to max_bytes and any permission requirements.

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?

Two short sentences, front-loaded with the action and mechanism, then a concrete example path and the binary encoding rule. Every clause carries information; nothing is padded.

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?

An output schema exists so return values need not be described, and annotations cover safety, but for a 4-parameter reader with zero schema descriptions the entry omits how max_bytes affects results (truncation vs error), how encoding applies, and whether any boot/runtime state is required on the IPC.

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% for all four parameters, so the description must carry the load and it does not: as_text, encoding, and max_bytes are never mentioned. The phrase 'Binary → base64' loosely relates to as_text but gives no mapping, defaults, or interaction rules.

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?

States a specific verb and resource (read a file from the target IPC's file system) plus the transport mechanism (over ADS, no share needed), which separates it from project-side readers like proj_read_file and from directory listing siblings like ipc_list_dir.

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?

Usage is only implied: the example paths (TcUnit result XML, a log) hint at when this tool is useful, but there is no explicit when-to-use, when-not-to, or named alternative (e.g. ipc_list_dir to discover paths first, proj_read_file for local project files).

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