quipu_graph_list

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real behavioral context: it discloses what each result carries (class, source, lifecycle, labels for freshness/durability/trust/policy/kind), that `graph` mode skips "materialization enrichment," and the backward-compatibility signal that a store lacking this tool predates the graph-kinds surface. It does not explain what materialization enrichment actually means, which is the one unclear behavioral term.

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?

Dense but front-loaded: the listing purpose and the `graph` special case come first, then what is returned, then filter syntax, then the capability-probe note. No sentence is filler, though the jargon ("materialization enrichment," "dataKind token") adds cognitive load that a short gloss would fix.

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 enumerates the fields returned and the four label dimensions, and it covers mode conflicts and the version-compat signal. It leaves a couple of loose ends for a 3-parameter tool: no pagination or result-size behavior, and the undefined "materialization enrichment" term.

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 would be 3, but the description goes beyond the schema by giving concrete token examples for `kind` (operational | archive) and the only enum value for `lifecycle` (frozen). It also restates and reinforces the mutual-exclusion constraint on `graph`, which is the schema's most consequential semantic detail.

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 registered named graphs") and immediately clarifies the one-exact-IRI variant versus the filtered-list variant. It is distinguishable from siblings such as quipu_graph_create, quipu_graph_label and quipu_graph_freeze because the description scopes itself to enumeration and filtering, not mutation.

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?

Explicitly gives the two modes of use — pass `graph` for one exact IRI, or filter with `kind` and/or `lifecycle` — and states the exclusion that `graph` cannot be combined with kind/lifecycle. It also frames itself as a capability probe for the graph-kinds surface. It stops short of naming a sibling to use instead when the agent actually wants to create, label, or freeze a graph.

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