frida_memory_read

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

With no annotations provided, the description carries the transparency burden. It reveals the read-only nature and active-session requirement, but does not disclose failure behavior, permission needs, or effects of invalid addresses.

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 exceptionally concise, front-loaded with the purpose, and uses a clean Args block. Every sentence carries useful information with no 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?

For a simple 3-parameter read operation, the description covers all parameters and the active-session prerequisite. Since an output schema exists, the lack of return-value explanation is acceptable, though edge-case guidance (e.g., invalid address handling) is absent.

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 description adds substantial meaning beyond the bare schema types: PID must be a process with an active session, address is a hex string with an example, and size is the byte count. This fully compensates for the 0% schema description coverage.

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 'Read bytes from process memory' clearly states the tool's action and target resource. It is specific enough to distinguish from write/scan/protect, though it does not explicitly differentiate itself from sibling memory tools.

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 through its purpose and notes a prerequisite ('pid must have active session'), but it does not explicitly state when to prefer this tool over alternatives like frida_memory_scan or frida_memory_write.

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