GravityPort

generation_relation_record

Record an explicit parent-child link between two generations, such as edited_from or variant_of, with the evidence level you choose. Log relations only when the evidence supports them.

Instructions

Record an explicit generation-to-generation relationship such as edited_from or variant_of. Do not infer a parent unless the evidence supports it. When verificationLevel is omitted the relation is recorded as user_confirmed (you are asserting it on the user's behalf); pass "observed" or "inferred" to record a weaker evidence level.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "childGenerationId": "<childGenerationId>",
      "parentGenerationId": "<parentGenerationId>"
    },
    "name": "generation_relation_record"
  }
}

Input Schema

Name	Required	Description	Default
`evidence`	No
`createdAt`	No
`relationType`	No	How the child relates to the parent; defaults to derived_from when omitted.	derived_from
`childGenerationId`	Yes
`verificationLevel`	No	Evidence level for this externally supplied record. provider_verified is reserved for trusted GravityPort provider integrations.
`parentGenerationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.11Nov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare non-read-only, non-destructive, closed-world, so the description carries the meaningful burden and does so: it discloses the silent default of user_confirmed (a real consequence for data integrity) and the evidence-standard expectation. It does not say whether duplicate relations are rejected, merged, or overwritten, nor what happens to cycles.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, and each one carries a distinct instruction. The enumerated examples (edited_from, variant_of) partially duplicate the schema enum, which is minor waste but nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Six parameters, a free-form nested evidence object, no output schema, and only partial coverage — the description covers the highest-risk semantic (the user_confirmed default) but says nothing about what evidence should contain or what the tool returns. Adequate for the core call, insufficient for the full parameter surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 33%, so the description must compensate; it does explain the verificationLevel default and weaker levels, which the schema does not state. However, the nested evidence object, createdAt, and the two generation id parameters get no added meaning, leaving a third of the parameters fully undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (record) and a specific resource (generation-to-generation relationship) with concrete examples (edited_from, variant_of). It is implicitly distinguishable from the read-oriented sibling generation_lineage, but it never names a sibling to sharpen that boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Do not infer a parent unless the evidence supports it" is an explicit when-not condition, and the verificationLevel paragraph explains which value to pass and why. It lacks any direct routing guidance versus generation_lineage or generation_record, so the agent must infer that this is the write counterpart to lineage reads.

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