list_links

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

With no annotations, the description must describe behavior itself. It does describe the response keys and the error payload ('记录不存在返回 {"error": "NOT_FOUND"}'), which is useful. However, it says nothing about permissions, result-set size limits, pagination, or the cost of traversing a high-degree node.

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?

The purpose is front-loaded in the first clause, and the error behavior follows compactly. The content is fully duplicated in Chinese and English, which doubles the length without adding information, but each half is efficient and the overall size is manageable.

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 description compensates well for the missing output schema by specifying the response keys and the NOT_FOUND payload. With no annotations and 0% parameter coverage, however, an agent still cannot tell what 'client', 'project', or 'relation' do, so the definition is not complete enough for confident invocation.

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 0% across 4 parameters, so the description must explain them, but it does not. 'relation' and 'direction' appear only as returned fields, not as input filters, and 'client'/'project' are never mentioned at all, leaving half the schema opaque.

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 names a precise verb and resource: 'List one-hop neighbors of a memory'. It also states the return shape, {'record_id','links'}. It never names a sibling such as search_memory or read_memory, so the agent must infer that this is a graph-traversal tool rather than a keyword search, but the purpose itself is unambiguous.

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 phrase 'one-hop neighbors' implies graph exploration, but the description gives no explicit condition for choosing this tool over read_memory or search_memory, and it does not say when not to use it. The only usage behavior it states is the NOT_FOUND case for a nonexistent record.

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