list_instance_settings

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

With no annotations, the description carries the disclosure burden and does well: it explains that a running bridge-enabled Prism yields effective resolved values while otherwise values come from instance.cfg, and that absent keys report null. It omits error behavior for an unknown instance id and any mention of whether the read is side-effect free, but the sourcing and null semantics are genuinely useful context.

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 tight sentences with zero waste; the content scope is front-loaded and the conditional behavior follows. Every clause carries information an agent would otherwise have to guess.

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 single-parameter read tool with no output schema and no annotations, the description covers what is returned, under which conditions, and how missing data surfaces (null). Naming the exact response shape or the error case for an invalid id would close the remaining gap.

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?

There is one required parameter (`id`) at 0% schema description coverage. The description implies the scope is a specific instance ('per-instance', 'instance.cfg'), so the parameter's meaning is inferable, but it never states that `id` is the instance identifier or what form it takes. Marginal value beyond the schema.

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 ('Read') and resource ('common per-instance settings') and enumerates the setting families covered (Java path/args, memory, window, console, join-on-launch, Override gates). The phrase 'in one call' implicitly contrasts with the singular sibling get_instance_setting, but that sibling is never named, so differentiation is inferential rather than explicit.

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 'in one call' phrasing hints this is the bulk-read alternative to per-key retrieval, but no explicit when-to-use or when-not-to-use guidance is given. The bridge-vs-file distinction describes where values come from, not when an agent should choose this tool over get_instance_setting or get_instance.

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