Skip to main content
Glama

query_insights

Discover bridge nodes in a Markdown knowledge graph that connect otherwise separate domains, revealing non-obvious cross-domain links and patterns.

Instructions

Surface vault nodes that bridge different domains. Finds nodes connected to items from domains outside their own — these are the unexpected cross-domain links that reveal non-obvious patterns. Each entry: {uid, title, type, domains, connects_to_domains, degree}.

Args: limit: Maximum number of bridge nodes to return (default 10)

Input Schema

NameRequiredDescriptionDefault
limitNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It signals a read-only analytical operation ('surface', 'finds') and describes the per-entry fields, which is helpful, but it says nothing about result ordering, whether the limit is applied before or after ranking by degree, or how 'domain' is determined. Those are the behavioral details that would matter most for a ranking-style query.

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 core purpose is front-loaded in the first sentence and the second sentence sharpens it. The 'Each entry: {uid, title, type, ...}' line largely duplicates the existing output schema and is the one part that does not earn its place, though it is short.

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

Completeness3/5

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

Because an output schema exists, the return-value enumeration is redundant rather than compensating. What remains missing is the semantics of the ranking and the meaning of 'domain' and 'degree' in this vault model — the things an agent needs to interpret results correctly. Adequate, but with real gaps for an analytical query tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it does: 'limit: Maximum number of bridge nodes to return (default 10)' explains the unit of the limit (bridge nodes, not raw edges) and restates the default. With only one optional parameter, this is nearly complete; the only omission is whether limit truncates a sorted result set.

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?

The description names a specific analytical operation and defines its scope precisely: 'Surface vault nodes that bridge different domains' plus a definition of bridge nodes as nodes 'connected to items from domains outside their own.' This is enough for an agent to tell it apart from query_neighbors, query_related, query_path, and find_nodes on conceptual grounds, but it never explicitly contrasts itself with those siblings, so a 4 rather than a 5.

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?

The 'unexpected cross-domain links that reveal non-obvious patterns' framing implies an exploratory use case, but there is no explicit when-to-use statement, no when-not condition, and no named alternative. An agent must infer that this is for discovery rather than for tracing a known relation.

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