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 by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 54 days
Last Tested: 2026-10-10 18:14
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-06 17:00 across 11 tools

Disambiguation4/5

Most tools target distinct resources and actions (product CRUD, CVE lookup/search, VEX, account, support). The only real overlap is get_product_vex vs list_product_vex_entries, but the descriptions explicitly delineate manifest metadata versus paged entries, so misselection is unlikely.

Naming Consistency4/5

Names follow a consistent snake_case verb_noun pattern (create_product, get_cve, list_products, update_product, search_cves, submit_support_report). The single deviation is whoami, which is a widely understood convention rather than a chaotic outlier.

Tool Count5/5

Eleven tools is well within the sweet spot and each maps to a real operation in the kernel-scanning domain (product lifecycle, CVE retrieval, VEX inspection, quota/identity, support). No redundant or filler tools are present.

Completeness3/5

Product coverage is create/get/list/update with no delete_product, leaving the lifecycle incomplete. Several capabilities referenced in descriptions (kernel-release discovery, full VEX document, config upload) are deliberately REST-only, which agents can work around but leaves gaps in the tool surface.

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.

    ``kernel_version`` is the kernel's release. For a stable kernel that is
    its version (``6.6.67``). For a CIP SLTS kernel pass its CIP release or
    the full ``uname -r``: ``4.19.325-cip136``, ``4.19.325-cip136-rt50``;
    a trailing local suffix such as ``-yocto-standard`` is accepted and
    ignored. The ``-cipN`` counter decides which of CIP's own backported
    fixes apply, so pass it whenever the device runs a CIP kernel — a bare
    ``4.19.325`` is analysed as the final 4.19 stable release (the
    ``.config`` never names the ``-cipN``). The known CIP releases of a
    series are listed by ``GET /api/kernel-releases?flavor=cip&series=4.19``
    (add ``&rt=1`` for the RT tree). The returned
    ``kernel_release`` shows how the string was read (``flavor``, ``base``,
    ``series``, ``cip``, ``rt``, ``local``; null when the string is no
    release). Surrounding whitespace is trimmed. A version string the
    analysis cannot read (e.g. ``4.19.325cip136``, or anything non-ASCII)
    fails with "Unrecognized kernel version" [400] before anything is
    created or the upload is consumed.

    A CIP release must be on the stable base the uploaded ``.config``'s
    header names (the header shows the exact base; a CIP tag never changes
    it): ``4.19.300-cip90`` with a ``4.19.325`` config fails with "… is
    based on 4.19.300, but the .config header says 4.19.325" [400]. This is
    checked before the upload is consumed, so the same upload can be used
    again with the right release. A stable version, or a ``.config``
    without a version header, is not checked.

ParametersJSON Schema

Name	Required	Description	Default
`arch`	Yes
`name`	Yes
`factor_ids`	No
`description`	No
`kernel_version`	Yes
`config_upload_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 richly: uploads are per-user, single-use, and expire in 30 minutes; creating spawns an analysis that spends a shared monthly allowance; factor_ids are silently ignored unless the plan permits factors; duplicate names return 409. It also details error semantics (400 on unreadable version, base-mismatch check occurring before upload consumption).

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

Conciseness3/5

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

The purpose is front-loaded and the workflow numbering is helpful, but the block is long and includes a full multi-line curl example plus parenthetical tangents that could be trimmed. Much of the detail is warranted given the domain, yet the volume exceeds what a well-sized tool description needs.

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 complex, quota-gated mutation with no annotations and no output schema, the description covers the workflow, plan gates, quotas, and version-parsing edge cases well. Gaps remain: the return value ('initial stats') is not described, and the required arch parameter is unaddressed.

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?

With 0% schema coverage the description must compensate, and it thoroughly explains config_upload_id (its origin endpoint and lifecycle), kernel_version (CIP vs stable, trailing suffix handling, -cipN significance, error strings), name (409 on reuse), and factor_ids (ignored under certain plans). However the required 'arch' and optional 'description' parameters are left entirely undocumented.

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?

Opens with a specific verb+resource+side-effect: 'Create a new product, run analysis, and return its initial stats.' An agent can immediately distinguish this from update_product, get_product, and list_products without inspecting 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 lays out the required pre-step (upload .config and pass config_upload_id), tells the agent to check whoami before batch creates, warns which tiers cannot create products, and distinguishes the durable 429 monthly quota from the transient rate limit ('report it to the user instead of retrying'). Genuine when/when-not 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; the product's VEX is re-evaluated
    against the new factors in the background (not metered), so ``get_product`` /
    ``get_product_vex`` show the new verdicts a few seconds later.

    ``kernel_version`` takes the same forms as in ``create_product``: a
    stable version, or a CIP release / full ``uname -r`` such as
    ``4.19.325-cip136-rt50``, whose ``-cipN`` counter decides which CIP
    fixes apply. A changed version string the analysis cannot read fails
    with 400 and changes nothing; re-sending the stored value is always
    accepted. A CIP release must stay on the base its ``.config`` header
    names: whichever of the two the update changes is checked against the
    other ([400], before the upload is consumed).

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.7/5.0

Behavior5/5

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

No annotations, so the description carries full behavioral burden — and it does: discloses the metered analysis allowance, distinguishes durable quota 429 from transient rate-limit 429 with retry guidance ('don't retry it'), explains async VEX re-evaluation timing, and that a rename is free. This is rich, actionable context beyond the schema.

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-loads the core purpose then layers side-effects, dependencies, and edge cases. Long but every section earns its place; could tighten slightly, but density is justified by 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?

Covers the dependency chain (upload then reference), metering and quota semantics, async side-effects, validation failure modes (400 on unreadable version, CIP base mismatch checked before upload consumed), and cross-sibling behavior. Complete for a 7-param mutation with no annotations or output schema.

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 coverage is 0%, so the description must compensate — and it does per-parameter: kernel_version accepted forms (stable version, CIP release, uname -r) and that -cipN selects fixes; config_upload_id=None keeps existing; factor_ids=None preserves vs. empty list clears. Each semantic is non-obvious from the schema alone.

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?

States a specific verb and resource ('Update a product owned by the caller') and immediately distinguishes which fields trigger side effects vs. which are free. Does not explicitly contrast with create_product, but the dependency chain (upload config, then pass id) implies the relationship.

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?

Explicit when/when-not guidance: when to POST a .config to uploads first, when to leave config_upload_id as None, when factor_ids=None vs empty list, and what triggers analysis vs. not. Names the alternative for config upload ('see create_product for the curl recipe').

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

EchelonGraph CVE & Exposure A
io.echelongraph
CVE, KEV, EPSS, SBOM and advisory lookups; per-CVE exposure from Shodan data (© Shodan). Keyless.
Security Penetration Testing Open Data
1612
cve-intelligence A
com.cve-security
CVE intelligence: exploitation (KEV/EPSS), detection coverage, fixed versions, CPE configurations.
Security Monitoring Observability
91
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
nist-nvd-mcp-server A
io.github.cyanheads
Search and audit NIST NVD CVEs by keyword, severity, CWE, CISA KEV status, and CPE.
Penetration Testing Government Data
511

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)
-
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 2 months 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
A
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 2 days ago (2026-10-09 06:47 UTC)
414 npm
1
Apache 2.0
CVE Search MCP Server
Security Penetration Testing
Arnabdaz
F
license
A
quality
D
maintenance
Enables searching and analyzing CVEs and vulnerabilities from multiple sources, optimized for PR review scenarios to help developers identify the latest security issues.
Updated 5 months ago (2026-04-28 12:17 UTC)
8
2
-

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?