Skip to main content
Glama

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

Search ids by prefix

graph_search
Read-onlyIdempotent

List nodes whose external id starts with a prefix (e.g. CVE-2024-1, T105). Ids only, not free text. If the answer has truncated: true, pass its next_cursor as cursor to continue; a list without truncated is complete.

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": {
      "id_prefix": "<id_prefix>"
    },
    "name": "graph_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional node label (type) to restrict the answer to, for example CVE, Technique or Detection. The valid labels are listed by graph_meta; an unknown label is refused with the valid ones.
limitNoMaximum items to return. The server clamps it to its own maximum; the answer reports applied_limit and limit_clamped.
cursorNoContinuation token: pass the next_cursor from a previous answer that had truncated: true to get the next page. Omit it for the first page.
id_prefixYesStart of an external id, at least a few characters, for example CVE-2024-1 or T105. Not free text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed4 schema fields changed
    • addedInput schema / properties / cursor / description
      Added value: +"Continuation token: pass the next_cursor from a previous answer that had truncated: true to get the next page. Omit it for the first page."
    • addedInput schema / properties / id_prefix / description
      Added value: +"Start of an external id, at least a few characters, for example CVE-2024-1 or T105. Not free text."
    • addedInput schema / properties / label / description
      Added value: +"Optional node label (type) to restrict the answer to, for example CVE, Technique or Detection. The valid labels are listed by graph_meta; an unknown label is refused with the valid ones."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum items to return. The server clamps it to its own maximum; the answer reports applied_limit and limit_clamped."
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety burden is largely covered. The description adds genuinely new behavioral context by describing the response envelope (truncated, next_cursor) and how completeness is signalled, which matters because there is no output schema. It doesn't cover ordering or result stability, so it isn't exhaustive.

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?

Three short sentences, front-loaded with what is listed, then the hard exclusion, then the pagination contract. No filler, and the truncation rule is phrased as a single actionable condition.

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 four-parameter, fully documented read tool with no output schema, the description supplies the one thing structured fields lack: how to tell whether the returned list is complete and how to page. Minor gaps remain around ordering of results and whether label filtering interacts with prefix matching, but nothing essential to a correct call 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 100%, with every parameter including label, limit and cursor already documented in detail, so the schema carries the semantics. The description merely restates the prefix constraint and pagination rule that the cursor field already explains, adding no new syntax, format or constraint information. Baseline 3 applies.

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 ("List nodes whose external id starts with a prefix") with concrete example prefixes, and explicitly contrasts it with free-text search ("Ids only, not free text"). It does not name any of the sibling retrieval tools (graph_lookup, graph_node, graph_path), so the agent must infer the boundary from the id-vs-text distinction alone.

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?

Clear usage context: prefix-based id lookup only, with an explicit exclusion of free-text queries, plus a concrete rule for continuing pagination when truncated is true. It stops short of naming an alternative tool for the non-prefix case, leaving the agent to pick a sibling on its own.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources