Creates explicit graph edges from document metadata using declarative rules such as path hierarchy, foreign keys, and exact matches to build or enrich a knowledge graph.
Declaratively induce explicit graph edges from existing document metadata attributes (path_hierarchy, foreign_key, exact_match). Parameters: collection, rules array.
| Name | Required | Description | Default |
|---|---|---|---|
| rules | Yes | ||
| collection | Yes | Collection name |
Changes observed during successful MCP inspections.
v4.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It never says whether induced edges persist, are recomputed on each call, replace or merge with existing edges, or what permissions are needed. For a mutation-oriented tool with zero annotation coverage these are significant gaps.
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 compact sentences with no filler, and the core action is front-loaded. The trailing parameter list is mildly redundant with the schema but low-cost.
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?
No output schema, no annotations, and a nested rules array whose item fields (field, target_field, weight, relation) are never explained. An agent can guess intent but cannot confidently construct valid rules from this description alone.
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 50% (collection documented, rules array not), and the description restates the parameter names while surfacing the three rule_type values. It adds a little meaning by tying rule types to metadata attributes, but explains nothing about field, target_field, weight, or relation within rule objects.
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?
States a specific verb and resource: 'Declaratively induce explicit graph edges from existing document metadata attributes'. The three named rule types give concrete scope. It doesn't explicitly differentiate itself from sibling linking tools like hyperspace_link or hyperspace_link_batch, which is the only thing keeping it from a 5.
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 statement of when to use this versus hyperspace_link or hyperspace_link_batch, and no prerequisites or exclusions. 'Declaratively' hints at a derived/bulk approach, but the agent must infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.