Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CVE-info-mcp Look up CVE-2024-3094 and summarize the official advisory and AI notes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CVE-info の公開脆弱性情報を、ローカルで動く読み取り専用 MCP から検索・取得します。検索結果・詳細本文には dev.mhirano.jp の個別ページ URL を含め、公式情報、AI解説、Web調査メモと出典を分けて返します。LLM API キーは不要で、このパッケージ自体は生成・追加調査を行いません。
uv と利用するクライアントを先にインストールしてください。Python 3.11 以上が必要です。uv は必要な Python を取得できます。
uvx cve-info-mcp install --client claude-desktopClaude Desktop を再起動すると cve-info が利用できます。Windows/macOS の設定ファイルを更新し、既存設定を保存してバックアップを作ります。同名の異なる設定があるときは上書きせずエラーにします。確認だけなら --dry-run、設定ファイルを明示する場合は --config PATH を付けてください。
CLI クライアント用の登録コマンドもあります。
uvx cve-info-mcp install --client claude-code
uvx cve-info-mcp install --client codex配布名 CVE-info は同一バージョンの CVE-info-MCP を導入するエイリアスです。uvx cve-info install --client claude-desktop でも同じ実装が動きます。PyPI の名前は大文字小文字を区別しないため、CVE-info-MCP と cve-info-mcp は同一パッケージです。
Related MCP server: NVD CVE MCP Server
ツール | 内容 |
| CVE番号・製品・日本語・CWEの検索。結果ごとに |
| 公式情報、AI解説、Web調査メモ。本文冒頭と |
| KEV・AI解説・調査メモの有無で絞り込み、最大50件とページ送り |
|
|
| ローカル索引のバージョン・更新状態・収録件数・公式サイト URL |
例: CVE-2026-99083 の引用先は https://dev.mhirano.jp/CVE-info/cve.html?id=CVE-2026-99083 です。外部のベンダー告知・調査記事 URL も出典として返します。クライアントにはこれらを引用して回答するよう指示しますが、最終的な引用表示はクライアント側の動作に依存します。
検索は Unicode 正規化後の部分一致・空白区切り AND 検索です。意味検索ではありません。公開日の新しい順で返します。調査メモがない場合は「未作成」、長い内容は省略したセクションをメタデータに記載します。KEV未掲載や検索結果なしを安全という意味には解釈しません。収録範囲と各情報源の状態は 元サイトの収集状況を確認してください。
CVE-info の公開 search-index.json
→ 毎時37分の GitHub Actions（LLM 呼び出しなし）
→ CVE-info-mcp の Pages: data/manifest.json + 圧縮した検索データ
→ 利用者の Python MCP: ローカル SQLite 検索
→ 詳細は元サイト assets/cves/...json から必要時に取得データ配信先は https://dev.mhirano.jp/CVE-info-mcp/data/ です。動的サーバーやクラウドDBは不要です。Actions のスケジュールは実行が遅れる場合があります。索引は初回検索時にダウンロードして構築し、その後は1時間ごとに確認、変更のあった圧縮ファイルだけ再取得します。詳細データは必要な番号帯だけ取得し1時間キャッシュします。索引と詳細は別時点の情報になり得るため、双方の鮮度を表示します。
初回検索には待ち時間があるため、クライアント接続前に uvx cve-info-mcp update で準備できます。更新失敗時は古いキャッシュを stale とエラー情報付きで返し、初回取得失敗・明示した update の失敗はエラーになります。配信 Actions が取得に失敗した場合も CI は失敗します。
uvx cve-info-mcp update
uvx cve-info-mcp search "Linux 認証"
uvx cve-info-mcp fetch CVE-2026-99083
uvx cve-info-mcp status保存先は OS 標準のユーザーキャッシュです。CVE_INFO_CACHE_DIR または --cache-dir PATH で変更できます。配信元変更は CVE_INFO_DATA_URL または --data-url HTTPS_URL、これらの CLI オプションはサブコマンドの前に置きます。元記事へのリンクは返しますが、外部記事へのアクセスや任意URL取得ツールは提供しません。
上の1行はローカル MCP に対応するクライアント用です。GitHub Pages の URL を ChatGPT・Claude Web のリモート MCP URL に登録しても接続できません。Web 版から使う場合は、対応するトンネル等で利用者の端末へ到達させる構成が別途必要です。HTTP モードはローカルループバックだけに待ち受けます。
uvx cve-info-mcp serve --transport streamable-http --port 8766エンドポイントは http://127.0.0.1:8766/mcp です。公開認証・HTTPS・トンネル設定はこのパッケージの対象外で、端末と MCP プロセスの稼働が必要です。
uv sync --locked
uv run pytest
uv build --out-dir dist/primary
uv build alias --out-dir dist/alias
uv run python scripts/check_release.py
uv run twine check dist/primary/* dist/alias/*check.yml は Windows・macOS・Linux と Python 3.11/3.13 で検証します。data.yml は毎時のデータ公開、publish.yml は GitHub Release 作成時のパッケージ公開です。バージョンを本体・aliasの両 pyproject.toml、aliasの依存指定、src/cve_info_mcp/__init__.py で揃え、uv lock を実行してからタグ vX.Y.Z を main 上に作成し、GitHub Release を公開します。再実行では対象タグを指定してください。本体の公開成功後にエイリアスを公開します。
PyPI Trusted Publisher は次の2件を登録します。APIトークンや Actions Secret は不要です。
PyPI Project name | Owner | Repository name | Workflow name | Environment name |
|
|
|
|
|
|
|
|
|
|
Pending Publisher の登録だけでは名前は予約されません。初回アップロード成功後にプロジェクトが作成されます。GitHub Pages の Source は GitHub Actions を指定します。
このリポジトリの Python コードは MIT License です。取得する脆弱性情報・外部文書・AI解説に一括して MIT を付与するものではありません。各情報源の権利と利用条件を引き継ぎます。元サイトの情報源・利用条件と、返却する出典 URL を確認してください。
Fetch one CVE by its exact ID, including official data, AI explanation, research and source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description does not need to repeat safety traits. It adds useful context by specifying the returned content: official data, AI explanation, research, and source URLs. It does not cover not-found behavior or rate limits, but the remaining gap is minor for this simple lookup.
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 definition is a single, front-loaded sentence with no filler. Every phrase earns its place by stating the action, the input constraint, and the returned 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?
For a one-parameter lookup tool with no output schema, the description is nearly complete: it explains what is fetched, how it is identified, and what data comes back. The only meaningful omission is what happens when the exact ID is not found.
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 0% for the single id parameter, so the description must carry the semantic burden. It does so partly by saying the ID must be exact, which implies an exact-match identifier rather than a fuzzy search term. It does not specify the expected CVE ID format or provide an example.
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 states the verb and resource: fetch one CVE by exact ID, and it lists the data returned. It implicitly distinguishes exact-ID lookup from search-style siblings, but it does not differentiate itself from the sibling get_cve, which appears to serve a similar purpose.
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 'by its exact ID' implies this tool is for direct lookup when the exact CVE identifier is known, while search tools handle discovery. However, it does not explicitly name search or search_cves as alternatives, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch all or one section: official, ai, research. Increase max_characters up to 50000 for truncated records.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| section | No | all | |
| max_characters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's job is narrower, and it does add real context: responses can be truncated and can be widened up to a 50000 character cap. It does not explain what the sections contain or whether 'all' is expensive, but the truncation disclosure is a meaningful behavioral trait.
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 short sentences with no filler, and the parameter-relevant advice is front-loaded. It is terse to the point of being cryptic about what is being fetched, but it does not waste words.
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?
With no output schema, the description is the only place to learn return shape, and it says nothing about the structure of a record or its sections. Combined with the missing id format guidance, an agent can call it but cannot predict the response.
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 0%, so the description must carry the load. It enumerates the valid section values and gives meaning plus a ceiling for max_characters, but the required 'id' parameter is completely undocumented (no expected format such as CVE-YYYY-NNNN), leaving a third of the surface unexplained.
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 verb 'Fetch' plus the enumerated sections (official, ai, research) makes the retrieval behavior reasonably clear, and the tool name supplies the CVE resource. However, the description never states what a 'section' is or that it returns a CVE record, and it does not distinguish the tool from the sibling search_cves.
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?
'Increase max_characters up to 50000 for truncated records' gives a concrete trigger for adjusting a parameter, which is genuine usage guidance. But there is no guidance on when to pick this tool over search_cves or search, and no statement of what to do when the id is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return local index freshness, dataset version, coverage and source collection-status URL. Does not trigger a download.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds useful behavioral context: it does not trigger a download and it returns a source collection-status URL. The description does not contradict any 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 efficient sentences: the first front-loads what is returned, and the second immediately clarifies a key non-behavior ('Does not trigger a download'). There is no wasted text.
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?
With no output schema, the description must explain what the tool returns, and it lists all key fields: freshness, dataset version, coverage, and source URL. Annotations cover safety and openness, and the description adds the no-download assurance. Nothing essential is missing for a parameterless status tool.
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?
There are zero parameters, so the baseline is 4. The description focuses on return content rather than parameter semantics, which is appropriate for a parameterless tool.
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 uses a specific verb ('Return') and clearly names the resource: local index freshness, dataset version, coverage, and source collection-status URL. It is distinct from siblings like search, fetch, search_cves, and get_cve, though it does not explicitly reference those alternatives.
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 is implied as a status-checking tool, and 'Does not trigger a download' clarifies an important side effect. However, there is no explicit guidance on when to choose this over siblings or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CVE IDs, products, Japanese keywords or CWEs. Returns up to 20 results with citation URLs; use fetch for details.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds behavior the annotations don't: a 20-result cap and citation URLs in the response, plus the handoff to fetch. Pagination and rate limits are unstated, but that is a minor gap given annotation coverage.
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 short sentences with no filler. The capability statement comes first and the return shape plus fetch handoff second, so the useful routing information 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?
With no output schema, the description must convey the return shape, and it does (up to 20 results with citation URLs). Only the unresolved overlap with the search_cves sibling keeps it from being fully complete.
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 0% and the single required parameter 'query' has no schema-level description. The description compensates well by enumerating the acceptable query domains (CVE IDs, products, Japanese keywords, CWEs), which is exactly the semantic an agent needs to form a valid call.
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 gives a specific verb (Search) and enumerates the searchable resource types: CVE IDs, products, Japanese keywords, and CWEs. It is clear what the tool does, but it never explains how it differs from the sibling search_cves, leaving an agent to guess which search tool to pick.
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 explicitly routes the agent to the fetch sibling for details, and states the result cap of 20, which sets expectations. There is no explicit when-not guidance or mention of search_cves as an alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter and paginate CVEs, newest publication first. Limit 1..50; offset <= 10000. Search is literal, not semantic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| ai_only | No | ||
| kev_only | No | ||
| research_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety traits (readOnly, idempotent, non-destructive), and the description adds useful behavior beyond them: newest-first ordering, pagination caps, and literal search semantics. It stops short of describing the return shape or the meaning of the boolean filters, but the added behavioral context is substantive.
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 sentences, front-loaded with the core operation and followed by the most important constraints. There is no filler and every sentence contributes useful information.
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 core search and pagination behavior is clear, but with six parameters at 0% schema coverage and no output schema, the description should do more to explain the boolean filter parameters and expected result shape. It is adequate for basic use but incomplete for fully informed 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 0%, so the description must carry parameter meaning. It explains limits for limit and offset and clarifies that query is literal, but it leaves ai_only, kev_only, and research_only entirely unexplained, so half the parameters remain opaque.
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 gives a specific verb and resource: "Filter and paginate CVEs," plus sort order ("newest publication first"). It is clear enough to distinguish a list-search operation from a single-record fetch, but it does not explicitly differentiate itself from siblings like get_cve or search.
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 provides operational guidance on pagination bounds and query semantics ("Search is literal, not semantic"), which helps an agent invoke it correctly. However, it does not state when to use this tool versus alternatives such as get_cve or fetch, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0fetchget_cveget_statussearchsearch_cvesScored across 5 tools
The set contains two overlapping search tools (`search` vs `search_cves`) and two overlapping detail tools (`fetch` vs `get_cve`). Descriptions hint at differences in pagination and section selection, but an agent could easily choose the wrong one for a simple CVE lookup.
Names mix bare verbs (`search`, `fetch`) with verb_noun patterns (`search_cves`, `get_cve`, `get_status`). The same action is labeled both `fetch` and `get_cve`, making the convention inconsistent rather than predictable.
Five tools is a reasonable count for a CVE lookup server, but the redundancy between the two search tools and the two retrieval tools means not every tool clearly earns its place. Consolidating the pairs would yield a cleaner three-tool surface.
The server covers the core read-only CVE lifecycle: search, filtered pagination, detailed retrieval by ID, section selection, and index status. Minor gaps exist around related metadata such as CWE or product browsing, but the main workflows are supported.
Search and audit NIST NVD CVEs by keyword, severity, CWE, CISA KEV status, and CPE.
CVE, KEV, EPSS, SBOM and advisory lookups; per-CVE exposure from Shodan data (© Shodan). Keyless.
Look up CVEs, CISA KEV, EPSS and open-source package vulnerabilities, including malicious packages.
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS