frida_host_diagnostics

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

No annotations are provided, so the description carries full responsibility for behavioral transparency. While it describes a read-like operation ('collect'), it does not confirm read-only status, potential side effects, or required permissions. The description is not misleading but leaves ambiguity about what exactly is collected and whether the operation is safe.

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 a single 11-word sentence that efficiently conveys the tool's purpose. It is front-loaded and contains no extraneous information, earning full marks for conciseness.

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 parameters, the description lacks crucial context for a diagnostic tool. It does not specify what diagnostic information is returned (no output schema), how to interpret results, or typical usage patterns (e.g., run as a first step). This leaves the agent underinformed about the tool's value and output.

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 tool has no parameters, and the input schema is empty (100% coverage trivially). The description adds no parameter information, which is appropriate since none exist. Given the zero-parameter baseline of 4, the description meets expectations.

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 clearly states the tool's purpose: 'Collect local host diagnostics relevant to Frida MCP operation.' It specifies a specific verb ('collect'), a specific resource ('local host diagnostics'), and context ('relevant to Frida MCP operation'). This distinguishes it from siblings that focus on device interaction or process manipulation.

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 provides no guidance on when or when not to use this tool. With over 100 sibling tools, explicit context on prerequisites or alternatives (e.g., 'Run this before other operations') would be beneficial. The current description implies a diagnostic role but lacks usage directives.

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