Retrieve all acyclic link paths and per-hop cardinalities for an object type within up to three hops, enabling analysis of derived relationships in an ontology.
返回对象在最多三跳内的全部无环 Link 路径及每跳基数。
| Name | Required | Description | Default |
|---|---|---|---|
| max_hops | No | ||
| object_type | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It indicates a read-only 'returns' behavior and discloses the acyclic/path and hop-limit semantics. However, it does not explicitly state that it has no side effects, warn about potentially large result sets, or mention any operational considerations.
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 a single, tightly packed Chinese sentence that front-loads the core behavior and key constraints. There is no filler or repetition.
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?
Given the tool reads a graph neighborhood and has an output schema, the return values are presumably covered by the schema. The description covers the essential graph concept and hop limit, but omits any guidance on acquiring or naming the object type, and does not clarify whether all link types are included. Sibling distinctions are also left entirely to the name.
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%, yet the description adds meaning for max_hops by clarifying the 'at most three hops' limit. It does not enrich object_type explanation; the agent must infer that 'object' refers to object_type and would not know how to choose valid values without additional context.
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 states a specific verb ('返回' / returns), a specific resource (acyclic Link paths around an object), and a scope (within at most three hops, including per-hop cardinality). It is clearly distinguishable from the sibling tools, which concern object types, derived properties, and field requests.
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?
No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites such as how to obtain a valid object_type, nor does it explain why an agent would choose this over sibling tools like snw_list_object_types or snw_execute_derived_property.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.