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

With no annotations provided, the description carries the full burden and does so: it enumerates every verdict value with meaning, warns that unknown/error is not 'safe', clarifies that registry_* reflect institutional decisions rather than this tool's observation (and that malicious outranks approval), explains registry_approved+checked=false as 'not verified safe', and discloses network behavior (name/version only, no code, to pypi.org/npmjs.org and OSV.dev) plus offline GVSKB_MODE fallback behavior.

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?

Purpose and usage lead the description, followed by a well-organized verdict glossary and a network/offline note. The verdict enumeration is long but load-bearing for a safety-critical tool; it is only mildly more verbose than necessary given output_schema already exists.

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 safety-gating tool with five parameters, no annotations, and an output schema, the description covers the decision space an agent needs: verdict meanings and their relative severity, the non-equivalence of 'unknown' to safe, network/offline behavior, and the pre-install decision context. Nothing material is missing.

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%, so the schema already documents name, version, ecosystem, caller, and env_grade in detail — including the version-vs-full-history conservatism tradeoff and the E0/E1/E2 cooldown windows. The description adds little parameter-level detail beyond what the schema states, so the baseline 3 applies.

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 opening sentence states a specific action (verify a single package) plus the exact attributes checked — existence, vulnerabilities, maliciousness, publish cooldown — before install. It explicitly separates itself from the sibling scan_dependencies for whole-manifest inspection, so an agent can pick the right tool without opening either schema.

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 names the triggering conditions directly ('before pip/npm install of an AI-suggested package', 'typosquatting-suspect names') and routes the full-manifest case to scan_dependencies. Both the when-to-use and the alternative are stated rather than inferred.

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

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

With no annotations, the description carries the full burden and delivers key behavioral facts: code is never sent externally, and detected values are returned only as short masked evidence. This is exactly the kind of disclosure an agent needs for a security scanner. It stops short of stating permission/auth requirements or performance characteristics, so not a 5.

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?

Three short paragraphs, each earning its place: scope of detection first, then routing guidance to alternatives, then privacy/return behavior. Front-loaded and free of filler.

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 explanation is unnecessary; the description instead supplies the scope, the alternative-tool routing, and the data-handling guarantees. Nothing an agent needs to invoke this correctly is missing.

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%, so both parameters (code, filename) are already documented in the schema, including the display-only nature of filename. The description adds no syntax, format, or constraint detail beyond that, making the baseline 3 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?

Names a specific verb (detect) and precise resource scope: secrets (API keys/passwords/tokens), Korean-format PII (resident registration numbers, phone numbers), and internal network addresses. It explicitly positions itself as a subset check versus the broader scan_code / scan_path siblings, so an agent can distinguish it without opening either schema.

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?

States the triggering scenario ('is there a key/PII in this code?') and the exclusion condition explicitly, naming the alternative tools (scan_code / scan_path) for full security checks and noting they include this detection. Both when-to-use and when-not-to-use are covered.

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

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

With no annotations, the description carries the full burden and does disclose useful behavior: no network call is made and a missing ID returns {"error": "rule not found"}. Read-only intent is conveyed by '조회' (retrieve), but it is not stated outright, and no note on output size or caching is given.

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 — what it returns first, then when to use it — with the error contract appended. No filler, and the purpose is front-loaded.

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 unnecessary, and the description still covers the error case. For a single-parameter lookup with a documented upstream source of IDs, nothing an agent needs is missing.

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 coverage is 100% and the single rule_id parameter already carries example IDs (NIS-AI-M01, OWASP-LLM-2025-01) plus its source. The description adds the same ID-source guidance but no format or validation detail beyond the schema, so the baseline 3 applies.

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+resource (retrieve full security rule text by rule ID) and lists what the payload contains (evidence sources, detection criteria, safe remediation examples). This clearly distinguishes it from the sibling search_rules, which finds rules rather than fetching one by ID.

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?

Gives a clear trigger — when the agent needs the rationale for why a finding fired — and names the ID sources (finding.rule_id, search_rules results), effectively documenting the upstream workflow. It never explicitly states the inverse (use search_rules to locate rules by keyword), so the alternative is only implied.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses a behavioral trait beyond structure – 'no network calls,' implying a cheap local read – which is genuinely informative. However, it never explicitly states that the operation is read-only with no side effects, and gives no detail on ordering, stability, or scale of the result.

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?

Front-loaded with the core purpose, followed by usage context, alternatives, and a brief behavioral note. Four short sentences, each earning its place, with no redundancy.

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 values needn't be explained in depth, and with no input parameters there is nothing else to document. The description covers purpose, routing to siblings, and the no-network behavior, leaving no meaningful gap for an agent to call it correctly.

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?

This tool takes zero parameters, so the baseline is 4. The description's listing of returned fields applies to output rather than input, so there is nothing parameter-level it needs to compensate for.

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 and resource – returns the full list of security rules currently loaded on the server – and even enumerates the returned fields (ID, title, severity, layer). It cleanly distinguishes itself from sibling read tools by naming search_rules and get_rule as the alternatives for different retrieval needs.

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?

Explicitly scopes usage to debugging/auditing – checking how many rules loaded or whether a specific rule is present – and names the alternatives (search_rules for content search, get_rule for full-text lookup). The when-to-use and when-to-use-something-else conditions are both spelled out.

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

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

With no annotations at all, the description carries the full load and does so well: it discloses the exact save location convention, the GVSKB_REPORT_DIR env override, that the HTML is self-contained with no CDN/JS, that output is self-contained enough for stakeholder sharing, and the side effect that files are written at a standard location rather than by the agent.

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?

Purpose is front-loaded and the warning precedes the details, which is the right ordering. The format bullet list partially restates the schema enum descriptions, so a small amount of the text is redundant with structured data.

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 and the description correctly leans on the returned 'saved' path rather than re-explaining return values, and it covers input provenance, formats, save behavior and location override. The remaining gap is the unaddressed relationship to the save_report sibling.

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 coverage is already 100%, so the baseline is 3. The description goes beyond it by explaining what each format enum value is actually good for and by surfacing the GVSKB_REPORT_DIR environment variable, which appears nowhere in 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 and resource ('ScanReport → Korean report, saved to file'), names the input-producing siblings (scan_code/scan_path), and enumerates output formats. It does not, however, differentiate itself from the sibling save_report, so an agent cannot tell the two apart from this text alone.

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?

Gives concrete when-to-use guidance per format (html for print→PDF/email, sarif for CI/GitHub code scanning, save=False for piping) and a strong when-not-to-do ('do not re-save the returned content'). The one missing piece is that it never mentions the save_report sibling as an alternative, which matters given the overlapping purpose.

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

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

No annotations are provided, so the description carries the full burden, and it largely does: it discloses the on-disk path convention, three output formats with their intended uses (HTML printable to PDF with no external CDN, MD for editing, JSON for history/redo), and the GVSKB_REPORT_DIR env var for a shared folder. It does not address overwrite behavior or permission requirements, which keeps it short of a 5.

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?

Front-loads the core action and return value in the first sentence, then structures the format details as a tight bullet list. Every sentence earns its place; no repetition of schema content.

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?

Given no annotations, a nested-object schema, and the presence of an output schema (so return values need not be restated here), the description covers the missing pieces an agent needs: purpose vs sibling, destination path, format selection, and the shared-folder override.

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%, so the baseline is 3, but the description adds value beyond the field docs by spelling out the save convention and filename pattern, the format extensions, and the env-var override that governs where output_dir effectively resolves.

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+resource ('점검 보고서를 파일로 저장') and even names the return value (save path). It explicitly differentiates from the sibling render_report, explaining that render_report returns only the body string while this persists to a file, so the agent can tell them apart without opening either schema.

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?

Explicitly frames the when-to-use: if the report would otherwise vanish in the chat window and you need it for approval/reporting, use this tool. It names the concrete alternative (render_report) and the condition that selects save_report, leaving nothing to inference.

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

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

With no annotations, the description carries the burden and does add real behavioral context: code is never sent to an external API, secrets/PII are returned only as masked short evidence, and each finding carries why_it_matters and safe_fix. It still omits permissions, determinism, or cost/rate characteristics, so it is strong but not exhaustive.

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?

Front-loads purpose, then usage triggers, then behavioral guarantees in three short paragraphs, each earning its place. Slightly verbose in listing synonyms (보안·검토·체크·검사), but nothing 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?

For a six-parameter tool with no annotations but a present output schema, the description covers purpose, the key sibling alternative, and privacy/output behavior adequately; return-value structure can be deferred to the output schema. Minor gaps remain around the profile/scenario parameters' effect, but nothing essential to correct invocation is missing.

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%, so the schema already documents all six parameters including the file-vs-text distinction for `code`. The description's reinforcement of 'in-memory code, not a path' duplicates what the schema states rather than adding syntax or format detail, so baseline 3 applies.

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 and resource (inspects code snippets against public-institution security standards) and enumerates the risk classes covered (PII, secrets, SQL injection, dangerous execution, LLM risk). It explicitly names the sibling it is not (scan_path) for path inputs, so an agent can route without opening either schema.

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?

Gives explicit triggers (user asks whether in-memory/pasted/generated code is 'safe' or requests a security check/review) and an explicit exclusion plus alternative ('if it's a file/folder path, use scan_path instead'). The when/when-not split is unambiguous.

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

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

With no annotations, the description carries the full burden and does so: it discloses exactly what leaves the machine over the network (package name/version to official registry and OSV.dev, no source code), the offline (GVSKB_MODE=offline) fallback behavior and the resulting '미확인' status, that lockfiles widen coverage to transitive deps, and that truncated_count means packages were NOT scanned.

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?

Front-loaded with the core purpose, then organized into clearly themed paragraphs (routing, network, lockfiles, report integration, truncation). Each paragraph carries actionable content, though the length is on the heavier side for a five-parameter tool.

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?

Complete for a five-parameter tool with a full schema and an output schema. The description need not explain return values but still covers the two operational outputs that matter (dependency_audit field for render_report, and truncated_count as a warning signal).

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 coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: lockfile input causes ecosystem to be ignored, env_grade affects only the cooldown reference date and is not auto-detected, and limit defaults auto-scale to format. The only gap is that it doesn't tie these back to the parameter names explicitly.

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 and resources ('의존성 매니페스트를 파싱해 각 패키지의 실재·취약점·악성·쿨다운을 일괄 검사'), and explicitly distinguishes itself from the sibling scan_path by naming the condition ('scan_path 결과에서 ... "검사 제외"로 표시되면 이 도구로 이어서 검사하세요'). An agent can select it without opening the schema.

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?

Gives an explicit routing rule from scan_path, a strong preference rule for lockfiles over manifests (with the reason: transitive deps), and a recovery action when truncated_count > 0 ('limit 를 올려 재검사하세요'). It also tells the agent to leave env_grade blank when the user hasn't specified a deployment environment.

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

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

With no annotations, the description carries the full burden and does so richly: it enumerates exactly which files are read (.dist-info/METADATA, *.whl names, node_modules package.json), states that packages are never imported or executed, discloses that the network is used only for vulnerability lookup and only package names/versions are transmitted, mentions offline mode (GVSKB_MODE=offline), and notes licenses are returned only here.

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?

Front-loaded with the core distinction and well organized into a bulleted list of installation traces. It is somewhat long, with some detail that overlaps the schema's enum documentation, but nearly every sentence carries useful disambiguation.

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 values need not be explained, and the description covers behavior, side effects, network/privacy posture, and sibling differentiation. Nothing an agent needs to call it correctly is missing.

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%, so the schema already documents path, limit, and env_grade (including the E0/E1/E2 meanings and cooldown semantics). The description adds little parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 (scan) and resource (actually-installed packages, including transitive dependencies), and explicitly contrasts with the sibling scan_dependencies, which only reads manifest files. An agent can distinguish the two without opening either schema.

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?

Names the alternative (scan_dependencies) and the gap it covers (transitive dependencies missing from requirements.txt/package.json), which is clear routing guidance. It does not spell out explicit exclusions or when this tool would be the wrong choice, so it stops short of a full when/when-not statement.

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

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

With no annotations, the description carries the full disclosure burden and does well: it states traversal is local, build/vendor directories are skipped, binaries ignored, and source is never sent to an external API — the key trust concern for this tool. It also previews that findings carry why_it_matters and safe_fix. What is missing is mask/coverage behavior on partial scans and any permission or gating caveats, so it stops short of a 5.

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?

Purpose and trigger conditions are front-loaded in the first paragraph, with behavior and follow-up steps after. The parenthetical synonym lists ('보안·검토·체크·검사') and repeated framing add slight redundancy for keyword-matching reasons, but no sentence is truly 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?

For a tool with six parameters, a rich output schema, and no annotations, the description covers purpose, trigger, privacy behavior, finding shape, and the render_report follow-up — enough for correct invocation. It leaves profile/scenario selection semantics entirely to the schema, which is acceptable but is the one area an agent might still need guidance on.

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%, so every parameter (path, caller, profile, scenario, max_files, max_file_bytes) is already documented in structured form. The description adds no syntax or default guidance beyond the schema — baseline 3 applies when the schema does the heavy lifting.

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 (점검/검사) plus the resource (local file or folder path) and the security standard being applied. It explicitly distinguishes itself from scan_code for in-memory snippets and names render_report as the downstream step, so an agent can place it among 15 siblings without opening a schema.

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?

Gives literal user phrasings that should trigger this tool ('이 폴더/프로젝트 보안 점검해줘', '이 파일 검토/체크해줘'), states the negative case (in-memory code → scan_code instead), and positions the tool as the entry point of the codebase-audit flow. Nothing is left to inference.

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

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

With no annotations, the description carries the full behavioral burden and does so: unreadable components are not dropped but returned in `skipped` with a reason, purl-less or NOASSERTION-versioned components cannot be judged, and truncated_count > 0 signals incomplete coverage requiring a higher limit. This tells the agent exactly how results can be silently incomplete—context that is not derivable from the schema.

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?

Purpose and scope are front-loaded in the first sentence, followed by usage cases, then the important caveat block. It is slightly long for a 3-parameter tool, but every paragraph (usage, skip semantics, export alternative) adds information rather than restating the schema.

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 and the description still usefully explains the two fields that change how results must be interpreted (skipped, truncated_count). Authentication/permission requirements and the intent of the `caller` audit parameter are not mentioned, but for a read-style scan of caller-supplied text this is a minor 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning about `limit`: exceeding it surfaces as `truncated_count` and the remedy is to raise the limit and re-scan. It says nothing extra about `caller` or `sbom_text`, which the schema already documents well.

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 concrete verb+resource ('SBOM 컴포넌트를 검사합니다') and immediately clarifies the key scope condition ('소스 코드가 없어도 됩니다'). It explicitly distinguishes itself from the sibling scan_dependencies ('매니페스트/락파일을 받는 것과 짝'), so an agent can route correctly without opening either schema.

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?

Gives two concrete triggering scenarios (procurement/supplier submits only an SBOM; build pipeline already emits an SBOM) and names the counterpart tool for the other input shape (scan_dependencies). It also rules out one wrong direction—exporting results to SBOM is a CLI operation, not this tool—which is an explicit when-not.

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

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

With no annotations, the description carries the burden well: it discloses a fail-closed policy (bundles whose version can't be pinned are not queried and left as 'undecidable', and 'undecidable' ≠ 'safe') and explains why guessing is avoided. It does not discuss network calls, caching, or rate limits, which keeps it short of a 5.

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?

Front-loaded with the purpose, then the when-to-use condition, then caveats and workflow. Every sentence carries content, though the multi-paragraph block is longer than strictly needed for a 3-parameter tool.

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-format explanation is unnecessary. The description supplies everything else an agent needs: the trigger condition, the pass-through input contract, the fail-closed semantics, and the downstream render_report integration.

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 coverage is 100%, so the baseline is 3. The description's only parameter-adjacent guidance (pass vendor_bundles verbatim from scan_path, don't hand-assemble) is already stated in the schema's own property description, so the description adds no meaning beyond structured fields.

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+resource+scope: scanning component vulnerabilities in vendored frontend libraries (`static/*.min.js`). It explicitly contrasts with source-rule scanning (minified files are excluded there) and with package-manager auditing, letting an agent separate it from scan_dependencies and scan_path without opening schemas.

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?

Gives an explicit trigger ('if scan_path's vendor_bundles is non-empty, you MUST scan next'), an exclusion rationale (source rules produce only false positives on minified code), and the fallback case (no package.json / node_modules → this is the only component-discovery path). It also prescribes the downstream workflow: merge into dependency_audit with scan_dependencies results and call render_report.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses that only locally loaded rules are searched, that there are no network calls, and that each result carries a rule_id for a follow-up get_rule call. It omits result ordering/pagination behavior, keeping it short of a 5.

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?

Front-loaded with purpose, then usage/exclusions, then behavior and output chaining across three tight paragraphs. Each sentence earns its place, though the description is a touch longer than strictly necessary for a search tool.

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 detail is unnecessary, and the description covers purpose, usage, exclusions, offline behavior, and the follow-up get_rule chain. Nothing an agent needs to call it correctly is missing.

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%, so all 7 parameters (query, status, language, scenario, severity_min, approved_only, limit) are already documented in the schema. The description adds no parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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 (search) and resource (security guide rules, baseline + real-time intel) with an explicit scope note that only locally loaded rules are queried. It distinguishes itself from scan_code/scan_path by naming them as the wrong tool for code inspection.

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?

Gives concrete when-to-use triggers: finding the rationale/regulation behind a vulnerability type, safe alternatives, or related rules beyond a scan's rule_id. It also states when NOT to use it (code inspection → scan_code / scan_path), which is exactly the routing an agent needs.

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

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

With no annotations to lean on, the description carries the load well: it discloses 'No network calls' and, more importantly, explains that results may originate from stale in-memory code/rules and that the remedy is a server restart (not reinstall). That is meaningful operational context beyond any structured field, though it never explicitly states the tool is read-only/idempotent.

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 purpose and usage are well front-loaded in the first two English sentences, but the memo then runs long and switches into Korean, mixing languages and spending most of its length on output-interpretation detail. Much of that duplicates what the existing output schema should carry, so not every sentence earns its place.

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 zero-parameter diagnostic with an output schema, the definition is more than sufficient — arguably over-complete, since it interprets return fields the output schema already defines. The added value (how to detect and fix a stale process) is genuinely useful, so nothing an agent needs is missing.

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?

The tool takes zero parameters, so per the baseline this scores 4. The description's field-by-field guidance (process_stale, commit_id, total_rules, mcp_tools) concerns return values rather than inputs, so it cannot add input semantics.

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?

Opens with a specific verb+resource ('Return runtime diagnostics') and enumerates exactly what is returned ('install identity, rules dir, rule counts, env'). This distinguishes it from siblings like list_loaded_rules, get_rule, and scan_path, whose names describe different resources.

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?

Explicitly states when to use it: 'to verify the server is healthy and to see which rules are loaded,' and from any MCP client. It does not, however, name or exclude alternatives despite overlapping siblings (list_loaded_rules also reports loaded rules), so the routing guidance is clear but not fully disambiguated.

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

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

With no annotations, the description carries the full burden and it discloses real behavioral traits: no network calls, and auto-fix must go through diff preview plus human confirmation before applying. These are the kind of operational facts an agent needs. It does not mention authentication or rate-limit behavior, keeping it from a 5.

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 structure is well front-loaded: purpose, then when to call, then return fields, then the safety caveat. Each sentence carries distinct information with minimal redundancy. It is slightly verbose in re-listing return fields that the output schema already covers.

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 values need not be explained, yet the description usefully still names them. Given the absence of annotations, the coverage of no-network behavior and the confirmation-gated auto-fix path makes this complete enough for correct invocation.

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%, so the schema already documents rule_id and the optional unsafe_code with its masking-preview behavior. The description adds the calling convention (invoke by rule_id) but contributes little parameter meaning beyond what the schema provides, matching the baseline 3.

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 and resource: it returns a safe fix direction for a finding, and it enumerates the returned fields (plain_title, safe_fix, can_auto_fix). This clearly separates it from scanner siblings like scan_code or get_rule, though it never names a sibling explicitly to reinforce the distinction.

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 gives an explicit trigger: call with rule_id when asking 'how do I fix this?' for a specific finding. That is clear context for invocation. It omits any when-not guidance or comparison to alternatives such as get_rule, so it stops just short of full routing clarity.

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