脆弱性の詳細説明の取得

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool performs an external API lookup, returns specific data fields, and does not execute scanning, which are the key behavioral traits an agent needs. It does not mention potential network failures or rate limits, but for a read-only lookup tool, the disclosed behavior is sufficient.

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 three concise sentences in Japanese, starting with the core action, then the returned fields, then usage context and a clear non-scan caveat. Every sentence earns its place with no fluff or duplication of schema details.

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 the simple one-parameter interface, the fully self-describing input schema, and the absence of an output schema, the description is complete enough. It explains the data source, the input, the output fields, the relationship to sibling tools, and the key behavioral constraint (no scanning), so an agent can invoke it correctly without additional information.

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 schema already documents vulnerability_id with examples and length constraints (100% coverage). The description adds valuable semantic context by stating that IDs from scan_java_project or suggest_fix can be passed directly, which helps the agent understand the expected value and provenance of the parameter.

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 action ('取得して返す' fetch and return), a specific resource (OSV database at api.osv.dev), and the input type (GHSA-ID or CVE-ID). It explicitly lists the returned contents (details, CVSS, affected packages, references), which clearly distinguishes this from the sibling scan_java_project and suggest_fix tools.

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 clearly indicates this tool is for retrieving vulnerability details from IDs obtained via scan_java_project or suggest_fix, and explicitly states that scanning is not performed. This gives an agent clear contextual guidance on when to invoke it, though it does not explicitly state 'when not to use' for all alternatives.

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