check_library_usage

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

With NO annotations present, the description carries the full safety burden and delivers richly. It's transparent about behavior: it SURFACES signature+docs as 'inline context' (leaving judgment to the agent), it ASSERTS a `deprecated` verdict only when docs mark it, and it explicitly lists error/edge statuses (`NoOracleRun` / `NoExternalSymbols`). Most notably, it proactively discloses a potential misconception by stating it does NOT handle arity or drift checks and explains the reason ('not instrumented / needs a cross-version baseline').

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?

Structurally dense with zero wasted words. The multi-sentence description front-loads the core purpose, uses parentheticals to pack secondary details, and leverages bold/uppercase formatting effectively. Every clause earns its place (e.g., '(judge arity / misuse yourself)' is a compact, high-value instruction). It's information-dense but easily skimmable.

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 read-only, filterable tool with no output schema and a fully-documented parameter set, the description is exceptionally complete. It covers the key user-facing details: call context (external symbols), filtering, output semantics (deprecated verdict), and preconditions (oracle run). The worktree caveat is a nice touch that saves a user from confusion about which index the tool reads from. The explicit non-coverage of arity/drift is exactly the kind of boundary definition that prevents LLM confusion. I can't identify a meaningful gap for a tool of this scope.

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 100% with good inline docs for each parameter. The description adds value by conceptualizing them (`Filter by path, package, deprecated_only`), and it clarifies the return semantics (`limit` vs summary counts) that isn't obvious from the schema. It doesn't deeply re-explain each parameter but correctly treats the schema as authoritative, using the description solely to illuminate the filtering access pattern.

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?

Vividly clear: 'Dependency-contract check for the code's EXTERNAL library calls, from the SCIP oracle's external symbol info' immediately establishes the specific verb (check), resource (external library calls), and scope (vs. internal call graph). It explicitly names what it does NOT assert (arity or removed/renamed drift), effectively distinguishing itself from siblings like `find_callers` or `trace_callees`. This goes beyond a generic restatement of the name.

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 weaves in critical usage guidance: filter options (`path`, `package`, `deprecated_only`), the `oracle run` prerequisite, and explicit non-goals ('To filter by user/workspace, use search_calls_extensive' style contrast is absent, but it clearly warns about what it does NOT do (arity checks) which a user might otherwise assume). A clear when/why-not is implied rather than contrasted against a specific sibling by name, hence a 4.

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