get_related

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

With no annotations provided, the description carries the full disclosure burden. It does meaningful work by disclosing bidirectionality and the exact return schema ({fact_id, relation, edge_id, direction}), and 'Get' implies a read with no side effects. It lacks explicit read-only/safety language, pagination, or missing-fact behavior, but for a simple query tool the disclosed traits are substantive.

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 terse sentences with zero waste: the purpose and scope qualifiers are front-loaded, followed by the return shape. The 'Knowledge Graph:' prefix orients the agent instantly, and every clause earns its place.

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?

The return-shape disclosure compensates well for the missing output schema, and params are fully covered by the schema. However, with no annotations, the description omits a safe-to-call statement and any pagination/limit or not-found behavior for a potentially large 1-hop result set. It also doesn't route the agent toward graph_traverse or get_subgraph, which is notable given the sibling set.

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 schema already documents fact_id as 'The Qdrant point ID to find neighbors for' and relation with an example. The description doesn't add parameter-specific meaning beyond the schema; '1-hop, bidirectional' enriches tool behavior rather than param semantics. 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?

The description identifies a specific verb ('Get'), a concrete resource ('directly related facts'), and precise scope qualifiers ('1-hop, bidirectional'). This clearly distinguishes it from sibling tools like graph_traverse (multi-hop) and get_subgraph (broader structure), and it even specifies the return item shape.

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 '1-hop' qualifier implies this tool is for direct neighbors only, which implicitly signals that deeper traversals belong to another tool, but no alternative is named and no explicit when-to-use/when-not-to-use guidance is given. Given the presence of graph_traverse, get_subgraph, and find_entities as siblings, explicit routing would meaningfully improve agent selection.

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