list_java_processes

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavior beyond that: it returns pid, main class, command, and masked JVM arguments, and it explicitly excludes the managed MAT helper process.

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 English description is front-loaded and efficient, first stating the purpose and then adding return details and the exclusion. The full Chinese translation duplicates the same content, which is useful for localization but prevents a perfect conciseness score because half the text is redundant for an agent.

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 is complete for a zero-parameter discovery tool. It explains what is listed, what is returned, that JVM arguments are masked, and that the managed MAT helper is excluded; the output schema can carry the full return structure.

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 zero parameters, so there is no parameter semantics to explain. The baseline score for a no-parameter tool is 4, and the schema is empty and complete as expected.

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 states a specific action and resource: discovering local Java processes that can be attached for a live heap dump. It also gives scope boundaries by saying the managed MAT helper is excluded, which helps distinguish it from sibling tools that list heap dumps or operate on existing dumps.

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 usage context is clear: this is for finding local Java processes that can be attached for a live heap dump. It does not explicitly name follow-up alternatives such as open_heapdump or dump_java_heap, but the attach-for-live-heap-dump framing gives the agent enough context to infer the workflow.

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