Skip to main content
Glama

link_dependency

DestructiveIdempotent

Create a dependency between two tasks. Type is one of FINISH_TO_START (default, successor starts when predecessor finishes), START_TO_START, FINISH_TO_FINISH, START_TO_FINISH. Lag defaults to integer days; pass lagUnit "hours" or "minutes" for a finer lag (stored to the minute, applied to the schedule at whole-day resolution for now). Negative values create lead time (successor starts before predecessor finishes). One pair may hold several types at once (e.g. an SS and an FF); the SAME type twice is refused. The server rejects self-dependencies and cyclic chains, and surfaces a clear error if the dependency graph is too large to validate safely. Both tasks must be visible to you. Re-linking the same type with the same lag succeeds as a no-op (alreadyLinked: true); the same type with a different lag is refused with the existing edge named. The two tasks may sit in different projects: the successor is then scheduled after the predecessor, the response carries crossProject: true, and the constraint runs one way, since the predecessor project is scheduled without reference to the successor project. rescheduled counts the tasks the link moved; in a project with automatic scheduling off it is 0 and the response carries autoScheduleOff: true, because there only Recalculate moves dates. Instead of one pair, links takes up to 50 pairs, each with its own type, lag and lagUnit, applied in order with the same checks; a pair refused (cycle, missing task, permission) is reported in results with its error while the rest land, the schedule is recalculated once at the end, and the monthly allowance counts each pair.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "link_dependency"
  }
}

Input Schema

NameRequiredDescriptionDefault
lagNoLag amount in lagUnit. Default 0. Negative for lead time.
typeNoDefault FINISH_TO_START. Use FINISH_TO_FINISH for "wait for predecessor to wrap before declaring this done."
linksNoUp to 50 pairs in one call, in place of predecessorId and successorId. Each item takes the same fields as a single link.
dryRunNoPreview only: report the would-be link (type, lag) plus wouldCreateCycle / alreadyExists flags, without committing. Writes nothing. With links, each pair is checked against the links that exist now.
lagUnitNoUnit for lag: days (default), hours, or minutes.
successorIdNoTask that depends on the predecessor.
predecessorIdNoTask that must complete (or start, depending on type) first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / dryRun / description
      Previous value: -"Preview only: report the would-be link (type, lag) plus wouldCreateCycle / alreadyExists flags, without committing. Writes nothing."New value: +"Preview only: report the would-be link (type, lag) plus wouldCreateCycle / alreadyExists flags, without committing. Writes nothing. With links, each pair is checked against the links that exist now."
    • addedInput schema / properties / links
      Added value: +{
      +  "description": "Up to 50 pairs in one call, in place of predecessorId and successorId. Each item takes the same fields as a single link.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "lag": {
      +        "type": "number"
      +      },
      +      "lagUnit": {
      +        "enum": [
      +          "days",
      +          "hours",
      +          "minutes"
      +        ],
      +        "type": "string"
      +      },
      +      "predecessorId": {
      +        "type": "string"
      +      },
      +      "successorId": {
      +        "type": "string"
      +      },
      +      "type": {
      +        "enum": [
      +          "FINISH_TO_START",
      +          "START_TO_START",
      +          "FINISH_TO_FINISH",
      +          "START_TO_FINISH"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "predecessorId",
      +      "successorId"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 50,
      +  "type": "array"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "predecessorId",
      -  "successorId"
      -]
  2. Changed2 schema fields changed
    • changedInput schema / properties / lag / description
      Previous value: -"Integer days. Default 0. Negative for lead time."New value: +"Lag amount in lagUnit. Default 0. Negative for lead time."
    • addedInput schema / properties / lagUnit
      Added value: +{
      +  "description": "Unit for lag: days (default), hours, or minutes.",
      +  "enum": [
      +    "days",
      +    "hours",
      +    "minutes"
      +  ],
      +  "type": "string"
      +}
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare the write/destructive/idempotent profile; the description supplies the substance behind them — cycles and self-links rejected, oversized graphs rejected, cross-project links schedule one-way, rescheduled counts moved tasks and is 0 with autoScheduleOff, and bulk pairs land partially with per-pair errors. The no-op idempotency (alreadyLinked: true) is spelled out concretely, which is exactly the kind of context annotations cannot convey.

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?

The core purpose is front-loaded and almost every sentence carries non-obvious behavioral information rather than restating the schema. It is still a single dense block of prose that would scan far better as short grouped sentences, and a few clauses (monthly allowance counting) are tangential to invocation.

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?

For a destructive, graph-mutating tool with 7 parameters and no output schema, the description covers the failure modes, scheduling side effects, cross-project semantics, and partial-failure behavior an agent needs before calling it. Nothing material is left to guesswork.

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%, so the baseline is 3; the description earns above that by adding semantics the schema lacks, notably that hours/minutes lags are stored to the minute but applied at whole-day resolution, that negative lag means lead time, and that `links` applies up to 50 pairs in order under the same checks. It does not cover dryRun or the interaction between a top-level `type`/`lag` and the `links` array.

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?

Opens with a specific verb+resource: "Create a dependency between two tasks," then immediately enumerates the four dependency types, which makes the tool's scope unmistakable. It never names or distinguishes itself from siblings like propose_dependency, update_dependency or unlink_dependency, so an agent must infer the boundary from context.

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

Usage Guidelines3/5

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

The description gives rich conditional guidance about what will succeed or be refused (same type twice refused, same type with different lag refused, self/cyclic links rejected) and explains when to use the batch `links` form instead of a single pair. It does not, however, say when to use this tool rather than propose_dependency or update_dependency, nor does it mention dryRun, which lives only in the schema.

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.