Lattice: CVE, MITRE ATT&CK and detection graph for security agents

Check one product and version

graph_affects

Read-onlyIdempotent

The CISA-exploited CVEs that one product and version may concern, each with a verdict: in-range, outside-range or undetermined.

        Ask about ONE item per call. A result is a lead for a person to read: names are matched, versions are compared as upstream numbers, and a distribution can fix a CVE under an unchanged version number. No result does not mean safe. What you ask about is not tied to you: no key, address or time of day is kept with it, and it is counted anonymously for statistics. Do not send a hostname, path, address or any text that identifies a machine: it is refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product": "<product>"
    },
    "name": "graph_affects"
  }
}

Input Schema

Name	Required	Description
`os`	No	Optional operating system family and version, for example Alpine 3.12.
`kind`	No	Optional: package (the default), kernel (product linux, version the release) or hardware (vendor the maker, product the model).
`vendor`	No	Optional vendor name.
`product`	Yes	One product or package name, for example openssl. Letters, digits and . _ + - only: no hostname, path, address or URL.
`version`	No	Its version exactly as installed, for example 3.0.2-0ubuntu1.10. Without it every result is undetermined.
`ecosystem`	No	Optional: pypi, npm, maven, deb, apk, rpm, cargo, docker or generic. It picks how versions are compared.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond readOnly/idempotent annotations, the description discloses matching semantics (names matched, versions compared as upstream numbers), a genuine analyst caveat (a distribution fix can suppress a CVE under an unchanged version number), the meaning of no results ('does not mean safe'), and an explicit refusal rule for machine-identifying input. The privacy statement about no key/address/time being retained also tells the agent the call is safe to repeat without identity leakage.

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 purpose and verdict vocabulary are front-loaded, and each following sentence carries a real caveat rather than filler. The second paragraph is a long semicolon-chained run mixing matching semantics, safety caveat, privacy and input rejection, which costs some scannability.

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

Completeness4/5

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

With no output schema, the description correctly supplies the return content (CVEs plus one of three verdicts) and the important negative case. Given the schema fully documents inputs and annotations cover safety, the main remaining gap is routing guidance among the seven sibling tools.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all six parameters with examples. The description adds interpretive context for how version and ecosystem interact ('versions are compared as upstream numbers', distribution backports), but gives no parameter-level syntax or precedence rules beyond what the schema states.

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 resource and scope: 'The CISA-exploited CVEs that one product and version may concern' with per-CVE verdicts (in-range, outside-range, undetermined). An agent can predict the output shape and the query shape from the first sentence. It stops short of naming which sibling to prefer (graph_lookup, graph_exposure) for adjacent questions.

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

Usage Guidelines3/5

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

'Ask about ONE item per call' is a real usage constraint, and 'Do not send a hostname, path, address' defines a rejection boundary. But there is no explicit when-to-use versus the sibling tools, and no statement of when this tool is the wrong choice for a question the graph can also answer.

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

All Lattice: CVE, MITRE ATT&CK and detection graph for security agents tools Inspect

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?