get_relations

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

No annotations are provided, so the description carries full burden for behavioral disclosure. The one-word description 'エントリの関連を取得' (get entry relations) tells the reader this is a read operation but nothing more—no pagination, sorting, response shape, or failure behavior. The parameter 'direction' implies filtering between incoming/outgoing/both, which is some behavioral context, but the description itself is nearly empty.

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 description is extremely short (8 characters of meaning), which is efficient but drastically underspecified. Conciseness alone isn't the issue; the problem is that nothing is explained. There is no wasted text, but there is also essentially no content to evaluate for structure.

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 tool has 3 parameters (one complex enum), 2 required params, no output schema, and no annotations—so the description must carry substantial explanatory weight. It clarifies which entities can have relations (entry_type enum suggests profiles, skills, projects, etc.) but doesn't explain what 'relations' means, how direction affects results, or what the return format is. For a read tool with zero annotation support, this is inadequate.

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 each parameter has a schema-level description (entry_id: 'エントリID', direction: '方向 (デフォルト: both)', entry_type: 'テーブル名'). The schema already documents parameters well, placing a baseline of 3. However, the description adds nothing beyond this—no clarification of the default parameter interactions or how entry_type maps to relation semantics. The 'direction' default of 'both' is helpful but is already in 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?

The description 'エントリの関連を取得' (get entry relations) uses a specific verb (取得/get) and a resource (relations), which is reasonably clear. However, it doesn't distinguish itself from sibling tools like create_relation or delete_relation beyond the verb, and it doesn't clarify what kind of relations (inter-entry links for the persona graph). It's functional but minimal.

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?

There is no guidance about when to use this tool versus alternatives. The sibling set includes create_relation and delete_relation, and the description gives no hint about when to use get_relations versus other retrieval tools like get_profile or get_skill. No exclusions, alternatives, or context are provided.

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