Run a lightweight vulnerability scan on a target URL to detect SQL injection, XSS, sensitive files, and missing security headers using built-in payloads.
轻量级漏洞扫描（内置 payload，无需外部工具）
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 目标 URL | |
| check_sql | No | 检测 SQL 注入（默认 true） | |
| check_xss | No | 检测 XSS（默认 true） | |
| check_files | No | 检测敏感文件（默认 true） | |
| check_headers | No | 检测安全响应头（默认 true） |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It mentions built-in payloads and no external tools, but it does not disclose that the scanner sends HTTP requests, may actively probe the target with malicious payloads, could be intrusive, or may require authorization. This is a significant gap for a vulnerability-scanning tool.
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 description is a single compact sentence with no filler. The main purpose is front-loaded, and the parenthetical adds a meaningful constraint about internal payloads and external dependencies.
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?
The tool has five parameters, no output schema, and no annotations, so the description should explain what the scan returns, what side effects it has on the target, and when it should be used. The one-sentence description leaves all of that implicit, making it incomplete for an agent to confidently invoke the tool in a real remediation or scanning workflow.
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 fully documents the URL and all boolean check toggles. The description adds no parameter-level meaning beyond confirming that payloads are built in, which is acceptable given the schema already carries the parameter details.
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 clearly identifies the tool as a lightweight vulnerability scanner, using a specific verb/resource ('漏洞扫描') and adding a qualifier ('轻量级', '内置 payload，无需外部工具'). It is distinguishable from sibling tools like port-scan-lite and web-fingerprint-lite because it targets vulnerabilities generically, though it could be more explicit about which vulnerability classes it covers.
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 phrase '轻量级' and '无需外部工具' implies the tool is for quick or self-contained scans where external tools are unavailable. However, there is no explicit when-to-use or when-not-to-use guidance, and no comparison to alternatives such as verify-cve or the other '-lite' scanners.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.