Import local SCIP index

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

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds genuinely useful behavior beyond that: the dual execution modes (read JSON directly vs ask the local scip CLI to print binary SCIP as JSON) and the explicit safety guarantee that no remote service or project script executes. Nothing contradicts 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?

Two sentences with zero waste: the first front-loads the purpose and mechanism, the second delivers a security-relevant behavioral guarantee. Every sentence earns its place and the structure is easy to scan.

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?

An output schema exists, so return-value documentation is not the description's burden, and annotations cover idempotence/destructiveness. The description covers input sources, the conversion mode, the target catalog, and a safety safeguard. The main gap is the absence of routing guidance versus index_codebase/update_index, which matters given the tool's two execution modes.

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 75%, so format, directory, and index_file are already documented in the schema. The description reinforces the format enum by describing the two modes (direct JSON export vs CLI conversion), which is additive but not substantial. It does not cover the undocumented timeout_ms parameter; at 75% coverage the baseline 3 is appropriate.

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: import a local SCIP JSON export, or convert a binary SCIP index via the local scip CLI, into the project-isolated semantic-navigation catalog. This is enough to distinguish it from search/query/parse siblings, but it does not explicitly contrast the closest sibling, index_codebase, which builds an index from source rather than importing an existing one.

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 context is implied: use this when an existing local SCIP file (JSON or binary) must be loaded into the catalog, and the guardrail 'No remote service or project script is executed' communicates a meaningful constraint. However, there is no explicit when-to-use vs alternatives, no when-not-to-use, and index_codebase/update_index are never named.

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