mcp-registry/io.kernelscan/kernelscan · v1.26.0
As of 2026-10-22 14:07 UTC, the Kernelscan MCP server is up with a Glimind reliability score of 93/100 (grade A). Over the last 30 days it answered 100% of Glimind's liveness checks. It had 4 outages in 90 days, with a median recovery of 5 minutes.
Linux kernel CVE analyzer: upload a .config, get a CycloneDX VEX report of affecting CVEs.
Claude Code
claude mcp add --transport http kernelscan-mcp-server https://kernelscan.io/mcp/
Claude Desktop · Windsurf · Cline (mcpServers JSON)
{
"mcpServers": {
"kernelscan-mcp-server": {
"type": "http",
"url": "https://kernelscan.io/mcp/"
}
}
}
Third-party server, listed as discovered. Review its source before installing.
11 of 11 tool(s) carry no readOnlyHint/destructiveHint annotations.
Annotate read-only tools with {"readOnlyHint": true}. Agents and gateways can then run them without a confirmation prompt, and route around destructive ones. How to fix →
38 parameter(s) across 9 tool(s) have no description.
Add a "description" to each parameter with its format and an example ("ISO 8601 date, e.g. 2026-10-17"). This is the commonest cause of wrong arguments on the first call. How to fix →
3 tool(s) look like they change state (create/send/delete/pay…) but declare no destructiveHint.
Set annotations {"readOnlyHint": false, "destructiveHint": true|false, "idempotentHint": …}. Clients use these to ask the user before a side effect and to auto-approve safe reads. How to fix →
Handshake + tools/list takes ~2,046 ms.
Serve tools/list from memory, keep the process warm, and host close to your users. Every new agent session pays this before its first call.
Paste-ready definitions with the problems above fixed. Changes marked verify need a human look. 9 tool(s) still need parameter descriptions written by someone who knows the API. All of them as JSON: /v1/readiness/mcp-registry%2Fio.kernelscan%2Fkernelscan/fixes
{
"name": "create_product",
"description": "Create a new product, run analysis, and return its initial stats.\n\n ``config_upload_id`` references a previously-staged .config that the\n caller POSTed to ``/api/configs/uploads`` over plain HTTP — the LLM\n does NOT emit the config text itself (a real kernel .config is\n ~100–200 KB and exceeds a single tool-call output budget). Workflow:\n\n 1. Caller / wrapper script:\n ``curl -H \"Authorization: Bearer ks_live_...\" \\\n -F \"config_file=@.",
"inputSchema": {
"type": "object",
"title": "create_productArguments",
"required": [
"name",
"kernel_version",
"arch",
"config_upload_id"
],
"properties": {
"arch": {
"type": "string",
"title": "Arch"
},
"name": {
"type": "string",
"title": "Name"
},
"factor_ids": {
"anyOf": [
{
"type": "array",
"items": {
"type": "string"
}
},
{
"type": "null"
}
],
"title": "Factor Ids",
"default": null
},
"description": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"title": "Description",
"default": null
},
"kernel_version": {
"type": "string",
"title": "Kernel Version"
},
"config_upload_id": {
"type": "string",
"title": "Config Upload Id"
}
}
},
"annotations": {
"readOnlyHint": false,
"destructiveHint": false,
"idempotentHint": false
}
}{
"name": "get_cve",
"description": "Fetch a single Linux kernel CVE by ID (e.g. ``CVE-2024-12345``).\n\n No API key required: keyless callers get the public representation of a\n CVE, but only for CVEs in the public set (recent high-severity); any\n other id returns ``not found``. Free *keyed* callers get a 404 for CVEs\n published more than 60 days ago. AI risk-summary / analysis fields are\n included for any keyed user on CVEs in the public set, and for pro /\n enterprise on every assessed CVE.",
"inputSchema": {
"type": "object",
"title": "get_cveArguments",
"required": [
"cve_id"
],
"properties": {
"cve_id": {
"type": "string",
"title": "Cve Id"
}
}
},
"annotations": {
"readOnlyHint": true
}
}{
"name": "get_product",
"description": "Fetch one product owned by the caller, including the CVE breakdown.\n\n Returns 404 (not 403) if the product belongs to another user, so\n product existence isn't leaked across accounts.\n ",
"inputSchema": {
"type": "object",
"title": "get_productArguments",
"required": [
"product_id"
],
"properties": {
"product_id": {
"type": "string",
"title": "Product Id"
}
}
},
"annotations": {
"readOnlyHint": true
}
}Get an email or webhook when this server's readiness drops by 10+ points, tool-poisoning text appears, or a tool breaks:
curl -X POST https://glimind.com/v1/subscriptions -H 'content-type: application/json' -d '{"tools":["mcp-registry/io.kernelscan/kernelscan"],"email":"[email protected]"}'Agents: watch_tool({"toolId": "mcp-registry/io.kernelscan/kernelscan"}) over MCP.
list_product_vex_entries ~392 tokensupdate_product ~362 tokenscreate_product ~312 tokenssubmit_support_report ~310 tokenssearch_cves ~293 tokensStatic checks of the advertised tools/list (schema, descriptions, annotations, tool-poisoning patterns, names, size) plus observed protocol, uptime, latency and contract changes. Read-only: no tool is ever called. Weights: schema 15, docs 20, safety 15, efficiency 15, compatibility 15, protocol 5, reliability 10, stability 5. Token counts are estimates (~3.6 characters per token).
Operator? Fix these, then re-check live. Embed the readiness badge:
[](https://glimind.com/server/mcp-registry%2Fio.kernelscan%2Fkernelscan?ref=badge)
<a href="https://glimind.com/server/mcp-registry%2Fio.kernelscan%2Fkernelscan?ref=badge"><img src="https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.kernelscan%2Fkernelscan.svg" alt="MCP agent-readiness"></a>
.. image:: https://glimind.com/v1/readiness/badge/mcp-registry%2Fio.kernelscan%2Fkernelscan.svg :target: https://glimind.com/server/mcp-registry%2Fio.kernelscan%2Fkernelscan?ref=badge :alt: MCP agent-readiness
Glimind records every version of this server's tool definitions in a signed, append-only transparency log. Current manifest sha256:ca83168a2f0c3f28…, first seen 2026-10-17, included at leaf 1320 of 46,359. Version history · verify what your client received.
Compare: most reliable other servers · most reliable retrieval servers · most reliable security servers · most reliable data servers · most reliable communication servers
Glimind tells agents whether a server is up right now and how to call it, then fails over to a live alternative when it isn't.
Claude Code
claude mcp add --transport http glimind https://glimind.com/mcp
Claude Desktop · Windsurf · Cline (mcpServers JSON)
{
"mcpServers": {
"glimind": {
"type": "http",
"url": "https://glimind.com/mcp"
}
}
}
As of 2026-10-22 14:07 UTC, the Kernelscan MCP server is up with a Glimind reliability score of 93/100 (grade A). Over the last 30 days it answered 100% of Glimind's liveness checks. It had 4 outages in 90 days, with a median recovery of 5 minutes.
Kernelscan MCP server advertises 11 tools, including create_product, get_cve, get_product, get_product_vex, list_product_vex_entries.
Point your MCP client at this streamable-http endpoint: https://kernelscan.io/mcp/
Glimind scanned all 11 tool definitions for tool-poisoning patterns — hidden or invisible characters, instructions that override the model, concealment from the user, requests to read credential or MCP config files, conversation exfiltration and cross-tool shadowing — and found none. This checks what the server tells the model, not what its code does; review the source before granting access to sensitive data.
Status page: 90-day uptime, every outage and how long it lasted.
Claim this listing to get the Verified operator marker, a remediation checklist and owner analytics, or embed the live badge from any of the tool pages above. Maintainers: alerts, deploy attestation and monthly reports.
Status is an automated estimate from Glimind's liveness checks (handshake and tool listing only; no tool is ever called) and may lag or differ from your network. Glimind is not affiliated with this server or its operator. Operator? Request a correction or opt out at https://glimind.com/opt-out.