inspect_isolated_dependency_graph

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

readOnlyHint=true already establishes the safety profile, and the description adds real value by stating the graph is 'bounded' and limited to 'required' (native) edges rather than optional or inferred ones, plus an explicit disclaimer that it will not infer compatibility or authorize release. It still omits what happens when max_depth/max_nodes truncate the graph (silent truncation, error, or partial result) and what permissions the isolated organization requires.

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, front-loaded sentences with no filler; the scope statement precedes the disclaimer, which is the right order. It is arguably under-specified rather than padded, but nothing here is wasted.

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?

Insufficient for a tool with 4 required parameters and near-zero schema coverage. The two-sentence description leaves the profile parameters unexplained and gives no guidance on truncation behavior, partial results, or how the 'isolated organization' is designated among the three profile arguments.

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 only 14% across 7 parameters, so the description carries most of the burden and supplies none of it. source_profile, target_profile, isolated_profile, and components are all required but never explained, and the meaning of the 'bounded' limits (max_depth, max_nodes) is not clarified either.

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 names a specific verb and resource ('Read a bounded native required-dependency graph') and narrows scope with qualifiers: bounded, native, required-only, and within a named isolated organization. It does not, however, name which sibling it competes with (e.g. inspect_target_dependency or get_solution_component_dependencies), so differentiation must be inferred.

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 implied by the exclusions 'Does not infer target compatibility or authorize release', which tells the agent this is inspection only and that compatibility/release decisions live elsewhere. No sibling is named and no positive trigger condition ('use when you need X in order to Y') is given, so routing still requires guesswork.

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