KernelScan

Server Details

Linux kernel CVE analyzer: upload a .config, get a CycloneDX VEX report of affecting CVEs.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-20 19:24
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-09-18 07:16 across 11 tools

Disambiguation5/5

Each tool targets a distinct resource or action: product CRUD, product listing, VEX manifest vs. VEX entries, CVE lookup vs. CVE search, identity, access guidance, and support reporting are all clearly separated. Even the VEX-related tools are unambiguous because one returns a metadata manifest and the other pages through vulnerability entries.

Naming Consistency4/5

Tool names overwhelmingly follow a consistent snake_case verb_noun pattern: create_product, get_product, list_products, update_product, search_cves, list_product_vex_entries, submit_support_report. The only outlier is whoami, which is a standard command-style name but deviates slightly from the verb_noun convention.

Tool Count5/5

Eleven tools is well-scoped for a kernel CVE scanning and product-management service. The count covers product lifecycle, VEX inspection, CVE searching, account identity, access guidance, and support escalation without feeling bloated or thin.

Completeness4/5

The core workflows are well covered: product create/get/list/update, CVE search/lookup, VEX manifest and entry browsing, quota checks, and support reporting. The main gap is the lack of a delete_product tool, and full VEX document retrieval is intentionally delegated to REST, but these are workable limitations rather than severe dead ends.

Available Tools

11 tools

create_productAInspect

Create a new product, run analysis, and return its initial stats.

    ``config_upload_id`` references a previously-staged .config that the
    caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM
    does NOT emit the config text itself (a real kernel .config is
    ~100–200 KB and exceeds a single tool-call output budget). Workflow:

    1. Caller / wrapper script:
       ``curl -H "Authorization: Bearer ks_live_..." \
              -F "config_file=@.config" \
              https://kernelscan.io/api/configs/uploads``
       returns ``{config_upload_id, sha256, size_bytes, expires_at}``.
    2. Pass that ``config_upload_id`` into this tool.

    Uploads are per-user, single-use, and expire 30 minutes after upload.
    Same gates as POST /api/products: free can't create products; paid
    plans are capped at their resolved product limit — read it (and any
    per-account override) from ``whoami.product_limit`` rather than assuming
    a fixed per-tier number. ``factor_ids`` are silently ignored unless the
    plan allows security factors (``whoami.can_use_factors``). Re-using a
    product name returns 409.

    Creating a product RUNS an analysis, so it spends one unit of the
    team's SHARED monthly analysis allowance (``whoami.monthly_analyses_used``
    / ``monthly_analyses_limit``). When the allowance is exhausted the tool
    fails with "Monthly analysis limit reached (…/month) [429]". This is a
    durable monthly quota — NOT the transient per-call rate limit that also
    surfaces as 429: it will not clear until next month, so report it to the
    user instead of retrying. Check ``whoami`` before a batch of creates.

ParametersJSON Schema

Name	Required	Description	Default
`arch`	Yes
`name`	Yes
`factor_ids`	No
`description`	No
`kernel_version`	Yes
`config_upload_id`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and excels. It discloses that creation triggers an analysis consuming shared quota, that uploads are single-use and expire, that factor_ids are silently ignored without plan permission, and distinguishes durable monthly quota from transient rate limits. This is comprehensive.

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 structured with a summary, numbered workflow steps, a code example, and warnings. It is long but every sentence earns its place given the tool's complexity. Front-loaded with the core purpose and then details.

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

Completeness5/5

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

For a complex tool with prerequisites, plan gates, quotas, and error modes, the description covers all necessary context. It also notes the return value ('initial stats'), which is helpful given no output schema. Overall, it is complete enough for an agent to use correctly.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It provides deep detail on config_upload_id (how to obtain, expiry, workflow) and factor_ids (plan-gated behavior). Other parameters like name, kernel_version, arch are self-explanatory, but the critical one is fully covered.

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 'Create a new product, run analysis, and return its initial stats.' This is a specific verb+resource+output combination. It distinguishes itself from sibling tools like update_product, get_product, and list_products by focusing on creation and analysis.

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

Usage Guidelines5/5

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

The description provides an explicit workflow: upload a config first via curl, then pass the resulting config_upload_id. It explains plan restrictions, quota limits, and error handling (409 for duplicate names, 429 for monthly limit). It even advises checking whoami before batch creates, which is actionable guidance.

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

get_cveAInspect

Fetch a single Linux kernel CVE by ID (e.g. CVE-2024-12345).

    No API key required: keyless callers get the public representation of a
    CVE, but only for CVEs in the public set (recent high-severity); any
    other id returns ``not found``. Free *keyed* callers get a 404 for CVEs
    published more than 60 days ago. AI risk-summary / analysis fields are
    included for any keyed user on CVEs in the public set, and for pro /
    enterprise on every assessed CVE.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and excels. It details behavior based on caller type, access levels, error responses, and inclusion of AI fields, going beyond a basic fetch description.

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?

The description is front-loaded with a clear first sentence but includes a lengthy second paragraph with conditional details. Fairly well-structured but could be more concise.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema), the description is comprehensive: it explains the exact behavior, access tiers, and edge cases, leaving no major gaps.

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?

The input schema has 0% description coverage, and the description adds an example ID format but does not fully specify the parameter constraints or allowed values. It partially compensates but leaves room for ambiguity.

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

Purpose4/5

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

The description clearly states the tool fetches a single Linux kernel CVE by ID, specifying the verb and resource. However, it does not explicitly distinguish this from the sibling search_cves tool, leaving some ambiguity.

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 provides clear context on usage for different caller types (keyless, free keyed, pro/enterprise), including when results are returned vs not found or 404. It does not explicitly mention when to use this tool over alternatives, but the sibling context implies it.

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

get_productAInspect

Fetch one product owned by the caller, including the CVE breakdown.

Returns 404 (not 403) if the product belongs to another user, so product existence isn't leaked across accounts.

ParametersJSON Schema

Name	Required	Description	Default
`product_id`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the 404 behavior for other owners, which is a key security detail, but omits other aspects like error handling or rate limits.

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 sentences, to the point, no fluff. Front-loaded with the core purpose.

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

Completeness3/5

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

For a simple fetch tool with one parameter and no output schema, the description covers purpose and security behavior, but lacks parameter details and return format, making it adequate but not complete.

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

Parameters2/5

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

Schema coverage is 0% and the description does not explain the product_id parameter beyond implication. Adding format or constraints would improve usability.

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 fetches one product including CVE breakdown, distinguishing it from list_products (list) and get_cve (CVE only).

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 provides a security note about 404 vs 403 to prevent info leakage, which is helpful for correct usage, but lacks explicit when-to-use vs siblings.

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

get_product_vexAInspect

Return the VEX MANIFEST for one of the caller's products — metadata, not the document.

    Multi-megabyte CycloneDX documents (up to 8,000+ vulnerability entries)
    are not safe model-context payloads, so this tool returns a bounded
    manifest: CycloneDX format/spec version, product id, generated/expires
    timestamps, the VEX hash and the composite ETag identity, the
    uncompressed size in bytes, total + per-status vulnerability counts,
    and the authenticated REST download path. Reads from the 24h
    ProductVexCache; if the cache is empty/expired the next call to
    ``get_product`` (or the REST endpoint) will regenerate it.

    The MANIFEST carries the same ``kernelscan.io:exploit_maturity`` /
    ``kernelscan.io:kev`` overlay identity as the REST download
    (backend#337), so ETags compare across transports.

    To inspect the entries themselves, use ``list_product_vex_entries``.
    To retrieve the COMPLETE CycloneDX document, use the authenticated
    REST endpoint ``GET /api/products/{product_id}/vex`` (same ks_live_
    key) — that is the canonical way to retrieve the full artifact; no
    MCP tool returns it.

ParametersJSON Schema

Name	Required	Description	Default
`product_id`	Yes

TDQS

A4.6/5.0

Behavior5/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 and does so thoroughly: it explains the 24h ProductVexCache read path, when the cache regenerates (next get_product call), why the payload is bounded (multi-megabyte documents unsafe for model context), and the cross-transport ETag identity. This is exactly the operational context an agent needs for a caching, size-bounded read.

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?

Front-loaded with the core purpose and the metadata-vs-document distinction, then layers rationale, cache behavior, and sibling routing. It is longer than average, but every block earns its place by supplying information the agent cannot get from the schema or annotations. Slightly dense, not padded.

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

Completeness5/5

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

With no output schema and no annotations, the description fully enumerates the manifest fields (spec version, product id, timestamps, VEX hash, composite ETag, uncompressed size, total and per-status counts, REST download path), so the agent knows what it will receive. Combined with cache and retrieval guidance, nothing material is missing.

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 0% for the single product_id parameter, so the schema adds nothing. The description partially compensates by scoping it to 'one of the caller's products,' implying ownership and lookup semantics, but it does not state the id format or where to obtain it (e.g., list_products). Adequate but not fully compensating for the coverage gap.

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?

States a specific verb and resource ('Return the VEX MANIFEST for one of the caller's products') and immediately disambiguates scope with 'metadata, not the document.' It distinguishes itself from sibling list_product_vex_entries and from get_product without the agent needing to open any schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use list_product_vex_entries to inspect entries, use the authenticated REST endpoint for the complete document, and states plainly that no MCP tool returns the full artifact. This is a clear when-to-use/when-not-to-use with named alternatives.

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

list_productsAInspect

List the calling user's products with denormalized analysis stats.

Paid plans only (basic / pro / enterprise). Free callers get a clear upgrade message.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description bears full responsibility. It discloses that the tool is read-only (listing) and provides behavior for free users (upgrade message). It also mentions 'denormalized analysis stats' giving insight into the output. This is sufficient 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 two sentences long with no unnecessary words. The first sentence states the main action, and the second provides the key condition. It is front-loaded and efficient.

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

Completeness5/5

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

With 0 parameters and an output schema (not shown), the description covers all necessary context: it lists user's products, includes analysis stats, and notes the paid plan restriction. There are no gaps for an agent to make a decision.

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

Parameters4/5

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

The tool has 0 parameters, so the baseline is 4. The description does not need to add parameter semantics and correctly focuses on the tool's behavior.

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 lists the calling user's products with denormalized analysis stats. It specifies the verb 'list' and the resource 'products' with additional detail on the content (denormalized analysis stats). This distinguishes it from sibling tools like 'create_product' and 'get_product'.

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 states that it is for paid plans only (basic/pro/enterprise) and that free callers receive an upgrade message. This provides clear guidance on when to use the tool, though it does not explicitly mention alternatives for free users.

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

list_product_vex_entriesAInspect

Page through the VEX vulnerability entries of one of the caller's products.

    Returns COMPLETE CycloneDX vulnerability objects for one bounded page
    — never the root document, never all entries — plus ``returned``,
    ``total_matching``, and a ``next_cursor`` to continue with. Every
    result is bounded to 256 KiB: the page stops before the byte limit and
    returns a cursor when necessary. Entries are ordered by CVE id
    (ascending) and carry the same live ``kernelscan.io:exploit_maturity``
    / ``kernelscan.io:kev`` properties as the REST download (backend#337).

    Filters (all optional, combinable):
    - ``statuses``: ``affected`` / ``not_affected`` / ``in_triage``
    - ``severities``: ``critical`` / ``high`` / ``medium`` / ``low`` / ``none``
    - ``kev``: true/false — CISA KEV listing only / non-KEV only
    - ``exploit_maturity``: ``poc`` / ``weaponized``
    - ``cve_ids``: exact-match list of CVE ids

    ``limit`` defaults to 25, maximum 100. ``cursor`` is the opaque
    continuation token from a previous page — it is tied to the product,
    the active filters, AND the current document + threat-overlay
    revision: changing filters, a regenerated cache, or a KEV/PoC signal
    that moved since the last page invalidates it (start a fresh page
    without a cursor — re-using a stale one is rejected, never silently
    re-applied). Within one revision, concatenating all pages yields
    each matching CVE exactly once.

    The COMPLETE multi-megabyte CycloneDX document is served by the
    authenticated REST endpoint ``GET /api/products/{product_id}/vex``
    (same ks_live_ key) — the canonical way to retrieve the full artifact.

ParametersJSON Schema

Name	Required	Description	Default
`kev`	No
`limit`	No
`cursor`	No
`cve_ids`	No
`statuses`	No
`product_id`	Yes
`severities`	No
`exploit_maturity`	No

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so richly: 256 KiB page bound, CVE-id ascending ordering, live exploit_maturity/kev properties, cursor invalidation on filter/cache/revision change, stale cursors rejected rather than silently re-applied, and the each-CVE-exactly-once guarantee across pages.

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?

Long but front-loaded, with the core action, return shape, and filters ordered sensibly and no filler sentences. It is denser and longer than strictly necessary, but each block carries operational information.

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

Completeness5/5

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

No output schema exists, and the description supplies the return contract (complete CycloneDX vulnerability objects plus returned, total_matching, next_cursor) along with pagination, ordering, and staleness behavior. Nothing needed to invoke or iterate correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and does: it enumerates every filter with its allowed values (statuses, severities, kev, exploit_maturity, cve_ids), documents limit default/max (25/100), and gives precise semantics for the opaque cursor including its binding to product, filters, and document revision.

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?

States a specific verb (page through) and resource (VEX vulnerability entries of one of the caller's products), and explicitly contrasts with the full-document route ('never the root document, never all entries'), which distinguishes it from siblings like get_product_vex.

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?

Gives clear conditions for using this paged listing vs the full CycloneDX artifact served by the REST /vex endpoint, and explains how to continue with a cursor. It stops short of naming the sibling tool get_product_vex explicitly as the alternative, so it is clear context without a fully explicit tool-to-tool mapping.

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

request_accessAInspect

Explain how to get a KernelScan account (no API key needed).

    Self-registration is open — there is no invitation to wait for and no
    admin in the loop. The user signs up on kernelscan.io themselves (email
    + password, accepting the terms), confirms the verification mail, and
    mints a ks_live_ API key on their account page.

    This tool only hands that path back: it files nothing and sends no
    mail. ``email`` / ``name`` / ``reason`` are still accepted so older
    clients don't break, but they are ignored — never tell the user that a
    request was submitted on their behalf.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No
`email`	No
`reason`	No

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full burden. It transparently discloses that the tool has no side effects ('files nothing and sends no mail'), that the parameters are ignored ('they are ignored'), and instructs the agent to never mislead the user about a request submission. This goes well beyond the minimal schema and provides essential behavioral context.

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 well-structured: it opens with the core purpose, then explains the self-registration process, and closes with the critical behavioral caveat about parameters and no-op behavior. Every sentence adds value; there is no redundancy or fluff. The most important information (that parameters are ignored) is front-loaded in the latter part but still prominent.

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

Completeness5/5

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

For a simple informational tool with no output schema and no annotations, the description is complete. It covers the purpose, the exact process a user follows, the tool's no-op behavior, and the role of parameters. An agent can call this tool correctly without needing any additional information.

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

Parameters5/5

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

The schema has 0% description coverage, but the description explicitly states that `email`, `name`, and `reason` are accepted only for backward compatibility and are ignored. This is the only relevant semantic information about these parameters, and it is fully provided, so the description fully compensates for the schema's lack of detail.

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's purpose: to explain how to get a KernelScan account via self-registration. It uses a specific verb ('explain') and resource ('how to get a KernelScan account'), and its focus on account registration distinguishes it from all sibling tools (products, CVEs, support reports). The phrase 'This tool only hands that path back' reinforces the exact scope.

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 provides clear context on when to use the tool: when a user needs an account and no admin is involved. It explicitly states what it does NOT do ('files nothing and sends no mail') and warns against claiming a request was submitted, effectively telling the agent this is informational only, not a submission tool. It doesn't name alternative tools explicitly, but the behavioral guidance makes the usage boundaries clear.

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

search_cvesAInspect

Search Linux kernel CVEs.

    No API key required: keyless callers get the free public tier — recent
    high-severity Linux kernel CVEs (capped at 25 results). Free *keyed*
    callers see only CVEs published in the last 60 days; basic+ keyed
    callers get the full corpus.
    ``query`` matches against CVE id and description (case-insensitive).
    ``severity`` filters by effective severity (``critical``/``high``/``medium``/``low``).
    ``cvss_min`` filters by effective CVSS score.
    ``published_after`` (ISO 8601) returns only CVEs newer than that date.
    Returns up to ``limit`` (max 100) CVEs, newest first.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	No
`cvss_min`	No
`severity`	No
`published_after`	No

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description must disclose all behavioral traits. It covers tier differences, query behavior, sorting (newest first), and max limit. However, it does not describe the return fields (no output schema) or error handling, leaving some behavioral gaps.

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?

The description is relatively concise with clear point-by-point explanations, though the tier information could be briefer. It front-loads the purpose and uses line breaks for readability.

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 0% schema coverage, no annotations, and no output schema, the description covers the main functionality well (parameters, tiers, sorting). However, it lacks details on return fields and error conditions, which would make it more complete for an agent.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all parameters. It thoroughly describes all five parameters (query, severity, cvss_min, published_after, limit) with details on matching, filtering behavior, and default values, adding significant beyond the schema.

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 explicitly states 'Search Linux kernel CVEs' with a clear verb and resource. It distinguishes itself from sibling tools like 'get_cve' by focusing on search over multiple CVEs, not a single one.

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 details tier-based access restrictions (keyless, free keyed, basic+ keyed) and explains how each filter works (query, severity, cvss_min, published_after, limit). However, it does not explicitly state when to use search_cves versus get_cve (direct lookup), though the context implies it.

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

submit_support_reportAInspect

Send a support / dispute report to KernelScan staff.

    Use this when an automated CVE or factor assessment looks wrong, or
    when you need to hand human-needed context back to the team. The
    caller's API-key user is attached automatically (id, email, plan)
    so support can look the account up.

    ``category`` should be one of:
    - ``cve_assessment`` — wrong AI verdict / CVSS / CWE on a CVE
    - ``factor_assessment`` — wrong factor verdict for a product
    - ``bug`` — broken behavior in the API or UI
    - ``other`` — anything else

    ``cve_id`` / ``product_id`` / ``assessment_id`` are optional but
    recommended — they let support jump straight to the relevant row.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	No
`message`	Yes
`subject`	Yes
`category`	Yes
`product_id`	No
`assessment_id`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that caller API key user (id, email, plan) is attached automatically, and lists categories and optional IDs. No side effects are mentioned, but for a submission tool this 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.

Conciseness4/5

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

The description is fairly long but well-structured with bullet points and front-loaded purpose. Every sentence adds value, though slight trimming could improve conciseness.

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 6 parameters, no output schema, and a support tool context, the description covers categories, optional IDs, and user info attachment. It does not specify return value, but for a submission tool this is acceptable.

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

Parameters4/5

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

Schema coverage is 0%, so the description compensates by explaining the category enum values in detail and clarifying that cve_id, product_id, assessment_id are optional but recommended. Subject and message are self-explanatory.

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 sends a support/dispute report to KernelScan staff, and distinguishes from sibling tools like product and CVE tools by focusing on human review of automated assessments.

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 to use when an automated assessment looks wrong or when human context is needed. It does not explicitly mention when not to use, but the purpose is clear enough to guide selection.

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

update_productAInspect

Update a product owned by the caller. Re-runs analysis if the kernel_version, arch, or referenced .config changed.

    To change the .config, first POST the new file to
    ``/api/configs/uploads`` (see ``create_product`` for the curl recipe)
    and pass the returned ``config_upload_id`` here. Leave
    ``config_upload_id`` as ``None`` to keep the existing .config.
    ``factor_ids=None`` leaves factor selections untouched; an empty
    list clears them. Same tier gates as PUT /api/products/{id}.

    A change that re-runs analysis (``kernel_version``, ``arch``, or the
    ``.config``) spends one unit of the team's shared monthly analysis
    allowance and can fail with the same durable "Monthly analysis limit
    reached … [429]" quota error as ``create_product`` (distinct from the
    transient rate-limit 429 — don't retry it). A rename / description /
    factor-only edit runs no analysis and is free.

ParametersJSON Schema

Name	Required	Description	Default
`arch`	No
`name`	No
`factor_ids`	No
`product_id`	Yes
`description`	No
`kernel_version`	No
`config_upload_id`	No

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: it spends one unit of the shared monthly analysis allowance on re-running analysis, can fail with a durable 429 quota error distinct from the transient rate-limit, and explicitly says 'don't retry it'. It also explains the semantics of config_upload_id and factor_ids, covering side effects and edge cases.

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?

The description is dense but well-structured, with each paragraph addressing a distinct aspect (basic behavior, config upload, cost/error handling). Every sentence adds value, and it is front-loaded with the primary purpose. It is longer than a minimal description but appropriately so given the tool's complexity.

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

Completeness5/5

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

For a 7-parameter mutation tool with no annotations and no output schema, this description is remarkably complete. It covers authorization ('owned by caller'), quota impact, error differentiation, parameter semantics, and references the API route. No important aspect of tool behavior is left unexplained.

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

Parameters4/5

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

Schema description coverage is 0%, but the description compensates for the non-obvious parameters: config_upload_id (upload flow, None keeps existing), factor_ids (None vs empty list), and kernel_version/arch (trigger analysis). Name, description, and product_id are left to the schema but are self-evident. Minor gap: no explicit treatment of name/description, but these are trivial.

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 opens with a clear verb+resource: 'Update a product owned by the caller.' It further clarifies scope by specifying when analysis is re-run (kernel_version, arch, or .config changed), which also distinguishes behavior from the sibling create_product. This makes the tool's purpose unambiguous.

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 gives explicit guidance on when analysis is re-run versus free edits (rename/description/factor-only), and explains the multi-step process for changing the .config via the upload endpoint. It references the API tier gates and create_product for the curl recipe. However, it does not explicitly state 'use this to update an existing product instead of create_product', though it is implied.

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

whoamiAInspect

Return the caller's identity, plan, and quota state.

    Works without an API key: keyless callers get a lightweight public-tier
    payload (no account) describing how to request access.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description bears full responsibility. It discloses the keyless usage and payload variation, which is important behavioral context. It could mention that it is a read-only operation, but the description implies safety through its read nature.

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 sentences, front-loaded with the core purpose, no fluff. Every sentence adds critical information.

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

Completeness5/5

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

For a zero-parameter, read-only identity tool with no output schema, the description fully covers the return value and the keyless edge case. No gaps identified.

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

Parameters4/5

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

There are no parameters, so the description does not need to elaborate. It adds value by explaining the different response formats based on authentication state, which is beyond the schema's scope.

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 uses a clear verb 'Return' and specifies exact resources: 'identity, plan, and quota state'. It also distinguishes behavior for keyless vs keyed callers, which differentiates it from sibling tools that are CRUD or search operations.

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 states it works without an API key and describes the payload difference, providing clear context for when to use. It does not explicitly list when not to use or alternative tools, but the behavior is self-contained.

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.

1 tool updateSep 18, 2026
- Changedrequest_access4 fields changed
  - addedInput schema / properties / email / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
  - addedInput schema / properties / email / default
```
Added value: +null
```
  - removedInput schema / properties / email / type
```
Removed value: -"string"
```
  - removedInput schema / required
```
Removed value: -[
-  "email"
-]
```
1 tool updateSep 12, 2026
- Addedlist_product_vex_entries
10 tool updatesJun 27, 2026
- First observedcreate_product
- First observedget_cve
- First observedget_product
- First observedget_product_vex
- First observedlist_products
- First observedrequest_access
- First observedsearch_cves
- First observedsubmit_support_report
- First observedupdate_product
- First observedwhoami

Related MCP Connectors

cve-intelligence A
com.cve-security
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions. All tools keyless.
Security Monitoring Observability
81
SBOMApp - SBOM Generator & Vulnerability Scanner
io.github.mcpsbom
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Developer Tools Security Testing & QA Tools
2
Vulnerability Intel MCPOAuth
net.nexlab
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS
Penetration Testing Security
1
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

Related MCP Servers

dep-guard-mcp
Security CI/CD & DevOps Code Analysis
mdjahidanwar
F
license
Not graded
quality
C
maintenance
Scans Python, Node.js, Java/Spring, and PHP dependency manifests for known vulnerabilities using OSV and GitHub Advisory APIs.
Updated 6 months ago (2026-03-29 19:29 UTC)
-
Sbom Cyclonedx MCP
Legal & Compliance Security
CSOAI-ORG
A
license
Not graded
quality
C
maintenance
Generates SBOM in CycloneDX 1.6 and SPDX 2.3 formats, compliant with EO 14028, NIS2, and CRA.
Updated 18 days ago (2026-09-03 03:59 UTC)
53 PyPI
1
MIT
Vulnary-MCP
Penetration Testing Security Open Data
Agam-S
A
license
A
quality
B
maintenance
MCP server for querying CVE and package vulnerability data from NVD and OSV.dev, allowing CVE lookups and dependency scanning.
Updated a month ago (2026-08-18 07:12 UTC)
4
1
MIT
@cyanheads/cisa-cybersecurity
Government Data Open Data Penetration Testing
cyanheads
A
license
Not graded
quality
B
maintenance
Provides keyless, read-only access to CISA KEV, SSVC, and full ICS advisory corpus, letting users check CVE statuses, compute BOD 26-04 remediation timelines, and search advisories by vendor, product, CVE, CVSS, or sector.
Updated 16 hours ago (2026-09-20 03:38 UTC)
Apache 2.0

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?