Skip to main content
Glama

Traceable

Create or delete a trace link

traceable_link
DestructiveIdempotent

Create or delete a trace link between two TraceIDs (traceable rows, ID rows, or table trace rows), resolved server-side within one project. Both ops address the edge THE SAME WAY, by the pair of TraceIDs, which is the address a document read gives you: link columns render as TraceID names. op=create is idempotent on the PAIR, not the direction (F914): if an edge already exists between the two rows in EITHER direction, the existing edge is returned and nothing is written — existingDirection says "same" or "opposite", and on "opposite" a warning explains that no chip was placed because a second edge would be a cycle. When the source row is an ID Row, create also writes the link into its link column so the chip SHOWS on the page — placedInColumn says which column took it. The column chosen is the row's first OUTPUT link column, since the target is downstream of the source; pass toColumnIndex to place it elsewhere. If the row has no link column the edge is still created and pinned, and a warning explains why nothing is shown. op=delete removes the edge AND the chip from the source row's link cell. Direction is not guessed: if the pair exists only the other way round, nothing is deleted and the error says so, because in a traceability chain the direction carries meaning.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYescreate the edge, or delete it
toItemIdYesTarget TraceID (e.g. FR-012)
fromItemIdYesSource TraceID (e.g. UN-4)
toDocumentIdYesDocument UUID containing the target TraceID
toColumnIndexNocreate only: which of the source row’s link columns shows the chip; defaults to its first OUTPUT link column
fromDocumentIdYesDocument UUID containing the source TraceID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say idempotent/destructive; the description goes well beyond them, explaining that idempotency is on the unordered pair (F914), what happens on an opposite-direction collision (existingDirection, warning, no chip placed), what delete destroys (edge and chip), and the no-link-column fallback with its warning. This is rich, non-obvious behavioral disclosure.

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?

Dense but front-loaded, opening with the create/delete scope and the shared addressing rule before the edge cases. Every clause carries decision-relevant information, though the run-on density pushes slightly against readability.

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

Completeness5/5

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

With no output schema, the description compensates by naming the return signals an agent will see (existingDirection, warning, placedInColumn) and the failure modes. Nothing needed to call create or delete correctly appears to be missing.

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

Parameters4/5

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

Schema coverage is 100% and the schema already documents each field, so the baseline is 3. The description adds real meaning: toColumnIndex placement semantics and its default (first OUTPUT column) plus why the target is downstream, which the schema does not state.

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

Purpose5/5

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

States a specific verb pair (create/delete) and precise resource (a trace link between two TraceIDs). It distinguishes the edge from the sibling block/grid/segment tools by naming the exact objects addressed and the ops available.

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?

Gives clear conditions for each op: create is idempotent on the pair, delete requires the pair to exist in the same direction. It does not name alternative sibling tools or explicit when-not-to-use cases, but the create vs delete framing is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources