Add an MCP server exposing the OSV API as tools for AI agents

Đang mở
  • Có gì không ổn?
#6,272 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
api, security

Hướng nghiên cứu

Start with the existing Python tooling pattern in tools/datafix and the MCP SDK. Create an isolated server under tools/osv-mcp/ with its own pyproject.toml, using OSV_API_BASE_URL to target the stable /v1 endpoints. Done means exposing the four listed query and vulnerability lookup tools without adding dependencies to the root library; the issue says a PR is being opened, so check for that work before starting.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Is your feature request related to a problem? Please describe.

AI coding agents (Claude, Gemini, Joule, etc.) increasingly author and modify dependency manifests, but they have no first-class, machine-native way to ask OSV "is this package/version vulnerable?" during a task. Today an agent has to know and hand-roll the OSV REST contract. There is no Model Context Protocol (MCP) server in this repo, so OSV cannot be plugged into the MCP tool ecosystem that these agents natively consume.

Describe the solution you'd like

A small, self-contained MCP server under tools/ that wraps the stable public OSV REST API (https://api.osv.dev) as MCP tools, so any MCP-capable agent can query OSV directly:

  • query_package_vulnerabilities(package_name, ecosystem, version=None) → POST /v1/query
  • query_by_commit(commit) → POST /v1/query
  • query_batch(queries) → POST /v1/querybatch
  • get_vulnerability(vuln_id) → GET /v1/vulns/{id}

Design intent:

  • Python, using the official mcp SDK, matching the existing Python tooling (poetry, yapf, pylint).
  • Fully isolated in its own tools/osv-mcp/ directory with its own pyproject.toml (same pattern as tools/datafix), so nothing leaks into the root osv library.
  • Thin REST wrapper only — no GCP dependencies, no new surface on the Go migration path. Only the stable /v1 endpoints (the two /v1experimental/ endpoints are intentionally excluded).
  • OSV_API_BASE_URL env var to target staging / a local API dev server.

Describe alternatives you've considered

  • A Go implementation (matching the repo's Python→Go migration direction) — but the MCP SDK is most mature in Python, this is auxiliary tooling rather than a core service, and tools/datafix establishes the Python-in-tools/ precedent.
  • Leaving it to third-party/out-of-tree MCP wrappers — but a first-party server keeps the tool surface and endpoint contracts in sync with OSV itself.

Additional context

Happy to open a PR for this. Flagging up front per CONTRIBUTING: this would be an AI-assisted contribution and the PR will disclose that. I'll sign the CLA. Opening a PR alongside this issue for concreteness, but happy to iterate on scope/placement first.

Ngôn ngữ chính
Go
Star
3k
Fork
390
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
129

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của google/osv.dev

Tất cả issue của google/osv.dev

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.