Lattice

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it explains the result shape (each match with its source, kev/nvd nodes for CVEs, a uid usable with graph_node/graph_neighbors) and defines the empty-items case as 'no such id' rather than an error.

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

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

Two tightly packed sentences: the lookup rule and examples come first, followed by the return semantics and the empty-result edge case. No filler, and every clause carries information an agent needs.

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

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

There is no output schema, so the description must carry return semantics — and it does explain match structure, source nodes, the uid chaining into graph_node/graph_neighbors, and the empty-list meaning. The label filter is left entirely to the schema, which is a minor gap given the otherwise strong coverage.

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

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

Schema description coverage is 100% — both the id format (case-insensitive, no prefixes) and the label semantics (valid labels from graph_meta, unknown labels refused) are fully documented in the schema. The description adds no parameter meaning beyond what the schema already states, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Find nodes by exact external id') and grounds it with three concrete id examples (CVE-2021-44228, T1059.001, CWE-79). It does not itself differentiate from siblings like graph_search or graph_node, though that distinction lives in the schema rather than the description.

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

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

Usage is only implied by the word 'exact' — the reader infers this is not for prefix/free-text lookups, but the explicit 'use graph_search for a prefix' routing lives in the schema's id description, not the tool description. The empty-result note is helpful context but is not when-to-use guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds instead of repeats: it takes no arguments, returns no CVE/technique/group/detection data, and yields the same answer to every caller of a given snapshot. It stops short of stating whether there is any cost, caching, or staleness caveat beyond the snapshot framing.

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

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

Front-loads the core definition, then uses labeled blocks ('When to call it', 'What it is not for') so an agent can scan the trigger and the exclusion without reading the enumeration of return fields. No sentence is filler.

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

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

With no output schema and no parameters, the description carries the return-value burden itself and does so fully: it names every field returned and the downstream arguments those fields populate. Nothing an agent needs before calling it is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description usefully reinforces this ('takes no arguments') and redirects the agent to the metadata it exposes rather than implying any input.

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

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

States a specific verb and resource ('Describe the graph this server reads') and enumerates exactly what it returns: snapshot id and creation time, schema version, node labels, relationship verbs, contributing sources, and path templates. It is immediately distinguishable from siblings like graph_lookup, which return actual facts.

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

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

Gives an explicit trigger ('once at the start of a session'), names the concrete downstream uses (valid label values for graph_lookup/graph_search/graph_neighbors, verb values for graph_neighbors, template names for graph_path, snapshot citation when reporting), and an explicit 'What it is not for' exclusion routing fact-seekers to graph_lookup.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: result ordering (declared and cross-source links first) and the truncation/next_cursor continuation protocol. It omits detail on confidence semantics and result size behavior.

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

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

Three tight sentences with no waste, and the most important content (what is returned and in what order) is front-loaded before the pagination mechanics.

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

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

With no output schema, the description usefully names the returned fields and the truncation contract, which is what an agent needs to page correctly. Remaining gaps, such as confidence scale or whether duplicate links can appear, are minor.

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

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

Schema description coverage is 100%, so the schema fully documents uid, verb, label, limit, cursor and direction. The description restates the cursor/truncated relationship and the returned fields but adds no filter syntax or format detail beyond the schema.

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

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

States a specific resource and scope: 'directly connected nodes' with each link's verb, source, confidence and declared/inferred status. It is clear this is a single-hop neighbor listing rather than a search or path tool. It does not, however, explicitly name a sibling to contrast against.

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

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

Usage is only implied by the resource itself (list links for a node). There is no statement of when to prefer this over graph_path or graph_search, nor any prerequisite guidance beyond the uid source noted in the schema. The pagination instruction is operational rather than selection guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the truncation disclosure ('long text is clipped') and the field-level semantics for kev and nvd nodes. The clipping note in particular is a behavioral trait an agent cannot get from structured fields.

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

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

Front-loaded with the core purpose and the truncation caveat, then the uid provenance, then field semantics. The node-type field enumeration is dense but each item earns its place given there is no output schema.

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

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

With no output schema, the description takes on the burden of describing returns and does so for kev and nvd node types, including the important 'cvss_score of 0 means not scored' edge case. It is not exhaustive about other possible node types, which is the main gap.

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

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

With 100% schema coverage and a single required uid parameter, the schema already documents the argument fully, including its origin. The description repeats the same sourcing information and adds no format or syntax detail beyond it.

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

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

States clearly that it returns one node's properties, with the node identified by uid, which is a specific resource and implicitly a read verb. It does not explicitly differentiate itself from siblings like graph_neighbors or graph_meta, which also return node-adjacent data.

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

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

It tells the agent where uid comes from (graph_lookup or graph_search), which is useful prerequisite context, but gives no guidance on when to prefer graph_node over graph_neighbors or graph_meta, nor any when-not condition.

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

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

Beyond the read-only/idempotent annotations, it discloses truncation behavior (long texts cut, flagged text_truncated, text_url for the full text), the graceful handling of unknown ids (reported in unknown rather than failing), and deterministic snapshot reads. These are exactly the behaviours an agent cannot infer from annotations.

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

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

Well front-loaded: the core action leads, then call timing, then exclusions. The "What it is not for" paragraph is slightly padded with the legal-advice caveat, but every part still carries selection-relevant information.

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

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

With no output schema, the description carries the full burden and delivers: it enumerates the returned fields (title, what it applies to, the obligation, the notice text) and the truncation metadata. Nothing needed to call or interpret the tool correctly is missing.

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

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

Schema description coverage is 100%, so the ids parameter, the 10-per-call cap and the unknown-id behaviour are already documented in the schema. The description adds a little framing (ids come from other answers) but largely restates the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource ("Return the licence and attribution notices for the data sources behind an answer") and explicitly positions itself against the other graph_* siblings by noting that they list notice ids while this tool resolves them. An agent can select it without opening any schema.

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

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

Gives an explicit trigger ("before you quote, republish or build on anything the graph returned") and explicit non-uses ("returns no security facts", "not legal advice"). It also documents the intended call chain from the notice ids emitted by other tools, which is the key routing fact.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds template semantics and one concrete output shape for cve-to-defense, but says nothing about latency, result size, or how the multi-hop answer is structured beyond that one template.

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

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

Front-loaded purpose followed by a compact template enumeration; every clause carries information. The trailing sentence singling out cve-to-defense is slightly uneven in weight but not wasteful.

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

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

There is no output schema, so the description should carry more of the return-shape burden; it only fully describes one of five templates' outputs. For a multi-hop traversal tool with three parameters this is adequate but leaves meaningful gaps for four of the five modes.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning the schema lacks: which node kind each template starts from, and what cve-to-defense returns. This is required reading because the schema's 'id' description defers the template/start-kind mapping to the tool description.

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

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

States a specific verb and resource: 'Answer a fixed multi-hop question from an external id', and enumerates the five templates with their entry node kinds. It is clearly distinguished in spirit from single-hop siblings like graph_lookup or graph_neighbors, though it never names an alternative explicitly.

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

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

The template list with start-node kinds gives real selection guidance for choosing between the five modes, and the 'fixed' wording implies predefined questions. There is still no stated when-not-to-use or routing to sibling tools such as graph_lookup for single-hop facts.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds return-behavior semantics that annotations can't: the meaning of 'truncated: true' and that its next_cursor must be passed back, and that a result without truncated is complete. That is genuine value, though it doesn't cover rate limits or permissions.

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

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

Three tightly written sentences: what it returns, what it is not, and how to paginate. Front-loaded purpose with zero filler.

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

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

With no output schema, the description usefully explains the truncated/next_cursor contract, which is the key thing an agent needs to loop correctly. It stops short of naming the returned id field or showing a full envelope, so a small gap remains.

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

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

Schema description coverage is 100%, so label, limit, cursor, and id_prefix are already documented in the schema, including the graph_meta cross-reference and clamping behaviour. The description largely restates the cursor/id_prefix semantics, so the baseline of 3 is appropriate.

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

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 id examples, and explicitly bounds the scope with 'Ids only, not free text.' This clearly separates it from sibling search/lookup tools.

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

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

Gives the triggering condition (prefix of an external id) plus an explicit exclusion ('not free text'), and explains when to use the cursor. It doesn't name an alternative sibling for the free-text case, which keeps it short of a 5.

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