How do I use yamory MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yamory MCP Server Show me all open vulnerabilities" 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.

yamory MCP Server

by AranSeshita

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

yamory MCP Server (Unofficial)

npm version License: MIT coverage

Note: This is an unofficial community-driven project and is not affiliated with or endorsed by yamory or Assured, Inc.
日本語版はこちら / Japanese version is available at the bottom of this page.

Model Context Protocol (MCP) server for yamory vulnerability management cloud. Connects AI agents to yamory as a knowledge base — providing what's detected, how dangerous it is, and how to fix it.

Quick Setup

1. Get Your API Token

Log in to yamory
Navigate to Team Settings > API Tokens
Click Issue Token with the usage scope set to API Server
Set the token as an environment variable:

export YAMORY_API_TOKEN="your-token-here"
# export YAMORY_TEAM_NAME="your-team"     # Optional: filter by team name

Tip: Add this to your shell profile (~/.zshrc, ~/.bashrc, etc.) so it persists across sessions.

2. Add to Your MCP Client

Claude Code

claude mcp add yamory \
  --env YAMORY_API_TOKEN=$YAMORY_API_TOKEN \
  -- npx @aranseshita/yamory-mcp-server@latest

Claude Desktop — Add to claude_desktop_config.json:

{
  "mcpServers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": {
        "YAMORY_API_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Cursor — Add to .cursor/mcp.json:

{
  "mcpServers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": { "YAMORY_API_TOKEN": "<YOUR_TOKEN>" }
    }
  }
}

VS Code (GitHub Copilot) — Add to .vscode/mcp.json:

{
  "servers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": { "YAMORY_API_TOKEN": "<YOUR_TOKEN>" }
    }
  }
}

Docker — Replace npx command with:

{
  "mcpServers": {
    "yamory": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "YAMORY_API_TOKEN", "ghcr.io/aranseshita/yamory-mcp-server"],
      "env": { "YAMORY_API_TOKEN": "<YOUR_TOKEN>" }
    }
  }
}

Team sharing (Claude Code) — Add .mcp.json to your project root. Each member sets YAMORY_API_TOKEN in their own environment:

{
  "mcpServers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": { "YAMORY_API_TOKEN": "${YAMORY_API_TOKEN}" }
    }
  }
}

Related MCP server: Exploit Intel Platform MCP Server

What Can I Ask?

Vulnerability Check & Remediation

Ask about your team's current vulnerabilities and get actionable remediation guidance. Combine with coding agents for automated fixes.

"Show me all open vulnerabilities"
"What immediate-priority issues do we have?"
"How do I fix the log4j vulnerability?"
"Update the affected packages and create a PR"

CVE Impact Analysis

When a new CVE is disclosed, instantly check if your projects are affected.

"Is CVE-2024-XXXXX affecting any of our projects?"
"List all projects using the vulnerable package"
"Summarize the impact and remediation steps"

Reporting & Triage

Generate summaries for standups, audits, or security reviews.

"Summarize this month's vulnerability status"
"Any projects with unresolved immediate-priority issues?"
"Show RCE vulnerabilities that are in the CISA KEV catalog"
"How many new vulnerabilities were detected this month?"

Tools

This server provides five tools. MCP clients automatically discover all parameters — the key filters are listed below.

`search_vulns` (recommended default)

Search app library and container image vulnerabilities in a single call. Results are grouped by source type (app / container).

`search_app_vulns`

Search app library (npm, Maven, pip, etc.) vulnerabilities.

`search_container_vulns`

Search container image vulnerabilities.

`search_host_vulns`

Search host (OS-level) vulnerabilities.

`search_asset_vulns`

Search IT asset (network devices, appliances, etc.) vulnerabilities.

Common filters (all tools):

Filter	Example	Description
`keyword`	`log4j`, `CVE-2024-1234`	Match project name, package name, or CVE-ID
`triageLevel`	`immediate,delayed`	Triage priority
`status`	`open`	Vulnerability status
`vulnType`	`RCE`, `XSS`, `SQLI`	Vulnerability category
`cvssScore`	`9.0`	Minimum CVSS score
`includeKev`	`true`	CISA Known Exploited Vulnerabilities only
`includePoc`	`true`	Only vulnerabilities with public PoC
`openTimestamp`	`2024-01-01`	Detected after this date

You don't need to remember these — just describe what you're looking for in natural language, and the AI agent will select the right filters.

Configuration

Environment Variables

Variable	Required	Description
`YAMORY_API_TOKEN`	Yes	API token from yamory team settings
`YAMORY_TEAM_NAME`	No	Filter by team name. Set `*` for organization-wide access (security team tokens only)

Scope Filter

yamory API tokens are scoped per team. YAMORY_TEAM_NAME adds an optional additional filter:

Scenario	Token	`YAMORY_TEAM_NAME`	Result
Developer	Team token	(unset)	Own team's data only
Security lead, one team	Security token	`Dev Team`	Filtered to specified team
Security lead, org-wide	Security token	`*`	All teams visible

Security

Never commit tokens to version control
Use environment variables or .mcp.json with ${YAMORY_API_TOKEN} syntax
Restrict scope with YAMORY_TEAM_NAME when possible
Rotate tokens periodically from yamory team settings

Development

npm install
npm run build
npm test

Debug with MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Roadmap

v1 (Current)

App library vulnerability search
Container image vulnerability search
Host vulnerability search
IT asset vulnerability search
Scope filter (token / team / organization-wide)
npm + Docker distribution

v2

CVE detail tool
CSPM vulnerability endpoints

References

License

MIT — see LICENSE.

Disclaimer

This project is an unofficial, community-driven integration. It is not affiliated with, endorsed by, or supported by yamory or Assured, Inc. "yamory" is a trademark of Assured, Inc. Use of the yamory API is subject to yamory's terms of service.

日本語 / Japanese

yamory MCP Server（非公式）

注意: 本プロジェクトは非公式のコミュニティ主導プロジェクトであり、yamory および Assured 株式会社とは一切関係ありません。

Model Context Protocol (MCP) を利用した yamory 脆弱性管理クラウド向けサーバーです。AI エージェントを yamory のナレッジベースに接続し、何が検出されたか、どの程度危険か、どう修正すべきかを提供します。

クイックセットアップ

1. API トークンの取得

yamory にログイン
チーム設定 > API トークン に移動
用途に API Server を選択して トークンを発行 をクリック
環境変数にトークンを設定:

export YAMORY_API_TOKEN="your-token-here"
# export YAMORY_TEAM_NAME="your-team"     # 任意: チーム名でフィルタリング

ヒント: シェルプロファイル（~/.zshrc、~/.bashrc など）に追加すると、セッション間で保持されます。

2. MCP クライアントへの追加

Claude Code

claude mcp add yamory \
  --env YAMORY_API_TOKEN=$YAMORY_API_TOKEN \
  -- npx @aranseshita/yamory-mcp-server@latest

Claude Desktop — claude_desktop_config.json に追加:

{
  "mcpServers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": {
        "YAMORY_API_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

チーム共有 (Claude Code) — プロジェクトルートに .mcp.json を追加。各メンバーは自身の環境で YAMORY_API_TOKEN を設定:

{
  "mcpServers": {
    "yamory": {
      "command": "npx",
      "args": ["@aranseshita/yamory-mcp-server@latest"],
      "env": { "YAMORY_API_TOKEN": "${YAMORY_API_TOKEN}" }
    }
  }
}

何を聞ける？

脆弱性の確認と修正

チームの現在の脆弱性を確認し、実行可能な修正ガイダンスを取得できます。コーディングエージェントと組み合わせて自動修正も可能です。

「未対応の脆弱性を一覧表示して」
「即時対応が必要な脆弱性は？」
「log4j の脆弱性はどう修正する？」
「影響を受けるパッケージを更新して PR を作成して」

CVE 影響分析

新しい CVE が公開された際、プロジェクトへの影響を即座に確認できます。

「CVE-2024-XXXXX は影響ある？」
「脆弱なパッケージを使用しているプロジェクトを一覧表示して」
「影響と修正手順をまとめて」

レポートとトリアージ

定例会、監査、セキュリティレビュー向けのサマリーを生成できます。

「今月の脆弱性状況をまとめて」
「即時対応の未解決問題があるプロジェクトは？」
「CISA KEV カタログに含まれる RCE 脆弱性を表示して」
「今月新たに検出された脆弱性は何件？」

ツール

本サーバーは5つのツールを提供します。MCP クライアントが全パラメータを自動検出します。主要なフィルターは以下の通りです。

ツール	説明
`search_vulns`	アプリライブラリとコンテナイメージの脆弱性を一括検索（推奨デフォルト）
`search_app_vulns`	アプリライブラリ（npm, Maven, pip 等）の脆弱性を検索
`search_container_vulns`	コンテナイメージの脆弱性を検索
`search_host_vulns`	ホスト（OS レベル）の脆弱性を検索
`search_asset_vulns`	IT 資産（ネットワーク機器等）の脆弱性を検索

共通フィルター:

フィルター	例	説明
`keyword`	`log4j`, `CVE-2024-1234`	プロジェクト名、パッケージ名、CVE-ID で検索
`triageLevel`	`immediate,delayed`	トリアージ優先度
`status`	`open`	脆弱性のステータス
`vulnType`	`RCE`, `XSS`, `SQLI`	脆弱性カテゴリ
`cvssScore`	`9.0`	最低 CVSS スコア
`includeKev`	`true`	CISA KEV に含まれる脆弱性のみ
`includePoc`	`true`	公開 PoC がある脆弱性のみ
`openTimestamp`	`2024-01-01`	この日付以降に検出されたもの

これらを覚える必要はありません。自然言語で検索したい内容を伝えれば、AI エージェントが適切なフィルターを選択します。

設定

環境変数

変数	必須	説明
`YAMORY_API_TOKEN`	はい	yamory チーム設定から取得した API トークン
`YAMORY_TEAM_NAME`	いいえ	チーム名でフィルタリング。組織全体にアクセスする場合は `*` を設定（セキュリティチームトークンのみ）

スコープフィルター

yamory API トークンはチーム単位でスコープが設定されます。YAMORY_TEAM_NAME でさらにフィルタリングできます:

シナリオ	トークン	`YAMORY_TEAM_NAME`	結果
開発者	チームトークン	（未設定）	自チームのデータのみ
セキュリティリード（1チーム）	セキュリティトークン	`Dev Team`	指定チームに限定
セキュリティリード（組織全体）	セキュリティトークン	`*`	全チーム表示

セキュリティ

トークンをバージョン管理にコミットしない
環境変数または .mcp.json の ${YAMORY_API_TOKEN} 構文を使用
可能な限り YAMORY_TEAM_NAME でスコープを制限
yamory チーム設定から定期的にトークンをローテーション

免責事項

本プロジェクトは非公式のコミュニティ主導の統合です。yamory および Assured 株式会社とは一切の提携・推奨・サポート関係にありません。「yamory」は Assured 株式会社の商標です。yamory API の使用は yamory の利用規約に従います。

Available Tools

5 tools

search_app_vulnsA

Search app library vulnerabilities detected by yamory. Returns triage level, status, affected package, solution, and CVE information. Results are scoped to the configured team.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (default: 100, max: 10000)
`status`	No	Comma-separated statuses: open, in_progress, wont_fix_closed, not_vuln_closed, closed
`keyword`	No	Search keyword — matches against project name, package name, CVE-ID, etc.
`vulnType`	No	Vulnerability type filter
`cvssScore`	No	Minimum CVSS score (0-10.0)
`includeKev`	No	If true, only CISA KEV vulnerabilities
`includePoc`	No	If true, only vulnerabilities with PoC
`triageLevel`	No	Comma-separated triage levels: immediate, delayed, minor, none
`openTimestamp`	No	Detected after this date. Format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ (UTC)

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so description carries full burden. It reveals return fields and team scoping but omits whether the tool is read-only, authentication needs, rate limits, or side effects. For a search tool, this is minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences with no redundant fluff. Every sentence adds value: purpose+returns, scoping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 10 optional parameters and no output schema, the description covers key returned fields and scoping. It lacks details on default pagination behavior (though schema mentions page/size) and the structure of results, but overall is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter has a description. The tool description adds no extra meaning beyond schema; it only provides high-level context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for app library vulnerabilities from yamory and lists returned fields (triage, status, package, solution, CVE). It implicitly distinguishes from siblings like 'search_host_vulns' by specifying 'app library'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this vs sibling tools (e.g., search_vulns). The mention of team scoping implies a use-case, but no when-not-to or alternatives are given.

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

search_asset_vulnsA

Search IT asset vulnerabilities detected by yamory. Returns triage level, status, affected asset/version, CVE-ID, and detail URL. Note: solution/fixedVersion are not available — refer to the yamoryVuln URL for remediation details. Results are scoped to the configured team.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (default: 100, max: 10000)
`status`	No	Comma-separated statuses: open, in_progress, wont_fix_closed, not_vuln_closed, closed
`keyword`	No	Search keyword — matches against project name, package name, CVE-ID, etc.
`vulnType`	No	Vulnerability type filter
`cvssScore`	No	Minimum CVSS score (0-10.0)
`includeKev`	No	If true, only CISA KEV vulnerabilities
`includePoc`	No	If true, only vulnerabilities with PoC
`triageLevel`	No	Comma-separated triage levels: immediate, delayed, minor, none
`openTimestamp`	No	Detected after this date. Format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ (UTC)

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It explicitly notes that solution/fixedVersion are not available and directs to the detail URL for remediation, which is useful. It also mentions scoping to the team. However, it omits authentication needs, rate limits, or any destructive/read-only nature beyond what's implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences long, front-loaded with the core purpose, and every sentence adds necessary information: what it returns, a critical limitation, and scope. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters with full schema descriptions and no output schema, the description covers the key behavioral aspects (return fields, missing fields, scoping). It omits details like pagination behavior or default ordering, but these are partially covered by schema. Overall, it is sufficiently complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 10 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds value by explaining the return fields and a specific limitation (missing solution/fixedVersion), but it does not enrich parameter-level semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search IT asset vulnerabilities detected by yamory', specifying the resource (IT asset vulnerabilities), source (yamory), and scope (team). It also lists returned fields, distinguishing it from sibling tools like search_app_vulns or search_host_vulns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for IT asset vulnerabilities within a configured team, but it does not explicitly state when to use this tool over siblings or provide exclusion criteria. No alternatives or when-not-to-use guidance is given.

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

search_container_vulnsA

Search container image vulnerabilities detected by yamory. Returns triage level, status, affected image/package, solution, and advisory information. Results are scoped to the configured team.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (default: 100, max: 10000)
`status`	No	Comma-separated statuses: open, in_progress, wont_fix_closed, not_vuln_closed, closed
`keyword`	No	Search keyword — matches against project name, package name, CVE-ID, etc.
`vulnType`	No	Vulnerability type filter
`cvssScore`	No	Minimum CVSS score (0-10.0)
`includeKev`	No	If true, only CISA KEV vulnerabilities
`includePoc`	No	If true, only vulnerabilities with PoC
`yamoryTags`	No	Comma-separated management tags
`triageLevel`	No	Comma-separated triage levels: immediate, delayed, minor, none
`openTimestamp`	No	Detected after this date. Format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ (UTC)

TDQS

A4/5.0

Behavior3/5

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

No annotations provided. The description mentions scoping to team and return fields, but lacks details on behavioral traits like pagination, authentication, or rate limits. As a search tool, it's minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose and key return fields. No superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and 100% schema coverage, the description adequately explains the tool's purpose and return content, though it omits explanation of pagination behavior beyond the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are well described in the schema. The description adds no additional meaning beyond what is already in the schema, earning a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches container image vulnerabilities from yamory, listing specific return fields. This distinguishes it from sibling tools targeting app, asset, host vulns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for container image vulnerabilities via its name and description, but no explicit when-to-use or alternatives guidance beyond the sibling tool names.

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

search_host_vulnsB

Search host vulnerabilities detected by yamory. Returns triage level, status, affected host/package, solution, and advisory information. Results are scoped to the configured team.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (default: 100, max: 10000)
`status`	No	Comma-separated statuses: open, in_progress, wont_fix_closed, not_vuln_closed, closed
`keyword`	No	Search keyword — matches against project name, package name, CVE-ID, etc.
`vulnType`	No	Vulnerability type filter
`cvssScore`	No	Minimum CVSS score (0-10.0)
`includeKev`	No	If true, only CISA KEV vulnerabilities
`includePoc`	No	If true, only vulnerabilities with PoC
`yamoryTags`	No	Comma-separated management tags
`triageLevel`	No	Comma-separated triage levels: immediate, delayed, minor, none
`openTimestamp`	No	Detected after this date. Format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ (UTC)

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions results are scoped to the configured team, but omits details like read-only nature, pagination behavior, or rate limits. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundancy. Could front-load the scope ('Results are scoped to the configured team') more prominently, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters and no output schema, more context is needed—e.g., default sorting, error handling, or relationship to other data. Description covers only basic purpose and scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage, so baseline is 3. Description adds no extra meaning beyond the schema; it only restates purpose and return fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool searches for host vulnerabilities and lists the return fields (triage level, status, affected host/package, solution, advisory). The term 'host vulnerabilities' differentiates it from siblings like search_app_vulns or search_container_vulns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention when-not to use or provide context for choosing it over other search tools.

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

search_vulnsA

Search vulnerabilities across app libraries and container images in a single call. This is the recommended default tool for general vulnerability queries. Returns results grouped by source type. Results are scoped to the configured team.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (0-indexed)
`size`	No	Results per page (default: 100, max: 10000)
`status`	No	Comma-separated statuses: open, in_progress, wont_fix_closed, not_vuln_closed, closed
`keyword`	No	Search keyword — matches against project name, package name, CVE-ID, etc.
`vulnType`	No	Vulnerability type filter
`cvssScore`	No	Minimum CVSS score (0-10.0)
`includeKev`	No	If true, only CISA KEV vulnerabilities
`includePoc`	No	If true, only vulnerabilities with PoC
`triageLevel`	No	Comma-separated triage levels: immediate, delayed, minor, none
`openTimestamp`	No	Detected after this date. Format: YYYY-MM-DD or YYYY-MM-DDThh:mm:ssZ (UTC)

TDQS

A4.2/5.0

Behavior4/5

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 discloses that results are grouped by source type and scoped to the configured team, which is useful context. However, it does not mention pagination behavior or what happens when filters yield no results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, each serving a clear purpose: explaining what it does, recommending its use, describing output grouping, and noting scoping. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 10 parameters and no output schema, the description covers high-level behavior (grouping, scoping, recommended use) but lacks a quick note on combining filters or pagination details, which would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides, which is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches vulnerabilities across app libraries and container images, distinguishing it from sibling tools like search_app_vulns. It specifies the verb 'search' and resource 'vulnerabilities' with additional context on grouping and scoping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'This is the recommended default tool for general vulnerability queries,' providing clear usage guidance. While it doesn't explicitly state when not to use it, the sibling tool names imply alternatives for specific scopes.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.1Jul 29, 2026
- First observedsearch_app_vulns
- First observedsearch_asset_vulns
- First observedsearch_container_vulns
- First observedsearch_host_vulns
- First observedsearch_vulns

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-07-29 13:00 across 5 tools

Disambiguation4/5

Each search tool targets a distinct vulnerability type (app, container, asset, host) with a general-purpose fallback. Overlap exists between the general search and specific ones, but descriptions clarify use cases.

Naming Consistency4/5

All tools follow the 'search_<target>_vulns' pattern consistently except the general 'search_vulns' which lacks a target specifier. This minor deviation is acceptable.

Tool Count5/5

With 5 tools covering general and specific vulnerability searches, the count is well-scoped for the domain. Each tool has a clear purpose and no redundancy.

Completeness4/5

The toolset covers the main resource types for vulnerability search. While missing advanced features like vulnerability updates or detailed lookups, the surface is complete for a search-focused MCP server.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

sectora A
io.github.megabrainee
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
Security Monitoring AI & Machine Learning
142
Security Intel MCP A
io.github.selflabbs
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Security Penetration Testing
2
Security Intel MCP A
com.datakoot
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Penetration Testing Security
31
Exploit Intelligence Platform — CVE, Vulnerability and Exploit Database A
com.exploit-intel
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Security Penetration Testing Monitoring
2

Related MCP Servers

ScanRook MCP Server
Security Monitoring
devinshawntripp
A
license
A
quality
D
maintenance
Enables AI assistants to perform vulnerability scanning on Docker/OCI images, check CVE details, analyze licenses, and compare scan results via ScanRook.
Updated 5 months ago (2026-04-24 03:35 UTC)
8
8 npm
MIT
Exploit Intel Platform MCP
Penetration Testing Security
OyaAIProd
A
license
A
quality
D
maintenance
Enables AI assistants to search and analyze vulnerabilities and exploits from multiple intelligence sources, including NVD, CISA KEV, ExploitDB, Metasploit, and more, with tools for CVE research, exploit analysis, and report generation.
Updated 4 months ago (2026-05-19 02:06 UTC)
17
MIT
Security Vulnerability MCP
Security Penetration Testing Search
nileshg21
F
license
Not graded
quality
C
maintenance
Provides Claude with live access to multiple vulnerability databases (NVD, OSV, GitHub Advisories, Snyk) for querying CVEs, package vulnerabilities, and remediation guidance.
Updated 3 months ago (2026-06-24 22:12 UTC)
-
vuln-intel-mcp
Security Penetration Testing
rohanrajnist
A
license
Not graded
quality
C
maintenance
Provides CVE lookup, search, and exploit intelligence from public vulnerability sources (NVD, CISA KEV, EPSS) for AI agents to produce remediation guidance without consuming LLM tokens for data fetching.
Updated 2 months ago (2026-07-06 06:18 UTC)
1
MIT

yamory MCP Server (Unofficial)

Quick Setup

1. Get Your API Token

2. Add to Your MCP Client

What Can I Ask?

Vulnerability Check & Remediation

CVE Impact Analysis

Reporting & Triage

Tools

search_vulns (recommended default)

search_app_vulns

search_container_vulns

search_host_vulns

search_asset_vulns

Configuration

Environment Variables

Scope Filter

Security

Development

Roadmap

v1 (Current)

v2

References

License

Disclaimer

日本語 / Japanese

yamory MCP Server（非公式）

クイックセットアップ

1. API トークンの取得

2. MCP クライアントへの追加

何を聞ける？

脆弱性の確認と修正

CVE 影響分析

レポートとトリアージ

ツール

設定

環境変数

スコープフィルター

セキュリティ

免責事項

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`search_vulns` (recommended default)

`search_app_vulns`

`search_container_vulns`

`search_host_vulns`

`search_asset_vulns`