Get Behavior Details

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

Annotations only cover readOnly/openWorld, so the description carries real weight and delivers: it discloses the default compact response, bounded one-level dependency expansion, labeling of unresolved calls, explicit warnings plus recovery references for inaccessible/oversized details, and closes with 'This reads configuration only.' These are substantive traits beyond the annotations.

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 block is dense but front-loaded with the cap and input source, then layers details, defaults, and error behavior. Every clause carries information, though the run-on sentence packing could be split for easier scanning.

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?

With no output schema, the description still covers the response shape (compact metadata vs. requested details) and failure behavior (warnings, recovery references). For a read-only six-parameter tool this is nearly complete, missing only explicit pagination/truncation semantics beyond max_bytes.

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?

At 83% schema coverage the baseline is 3, and the description adds value on top: it clarifies that the default response is compact metadata, that dependency expansion requires the dependencies detail, and that flows use sourceTable sys_hub_flow with kind flows, which is a valid-pairing detail the schema only gestures at.

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 verb (read) and resource (known behavior references) with explicit scope: up to 50 per call, sourced from discover_table_behavior or kind/sourceTable/sysId values. It also names the sibling that produces its inputs, so an agent can distinguish it from discover_table_behavior at a glance.

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?

It routes the agent clearly: pass references from discover_table_behavior, and add scripts/definitions/dependencies immediately when needed since the default is compact metadata. It gives the source and the timing, but offers no explicit when-not-to-use or exclusion conditions.

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