Skip to main content
Glama

roadmap_link_task

Attach an existing canonical task to a roadmap outcome using their IDs, connecting work items to outcomes without duplicating tasks.

Instructions

Link one existing canonical task to a Roadmap outcome.

Use this to attach a task to an outcome; use roadmap_transition to change the outcome's status.

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": {
      "roadmap_id": "<roadmap_id>",
      "task_id": "<task_id>"
    },
    "name": "roadmap_link_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesId of an existing canonical task in this repository; an already-linked task is not duplicated.
roadmap_idYesRoadmap outcome id in the form RM-YYYY-NNNNN, e.g. RM-2026-00001.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.67
    • addedInput schema / properties / roadmap_id / description
      Added value: +"Roadmap outcome id in the form RM-YYYY-NNNNN, e.g. RM-2026-00001."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of an existing canonical task in this repository; an already-linked task is not duplicated."
  2. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds that only an existing 'canonical' task can be linked, which implies no task creation, but says nothing about idempotency or what happens if the outcome is already linked; the idempotency note lives in the schema instead.

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?

Two short sentences with the purpose front-loaded and no filler. The second sentence is useful routing but slightly tangential since roadmap_transition is a different operation, not a substitute for linking.

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

Completeness4/5

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

For a two-parameter linking tool with annotations covering the safety profile and a fully documented schema, the description supplies enough for correct invocation. It lacks only a note about idempotency or the result of a link, which a caller might want given there is no output schema.

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 description coverage is 100%, with task_id and roadmap_id fully documented, including the RM-YYYY-NNNNN format. The description adds only the 'existing canonical task' qualifier and no further parameter meaning, so the baseline of 3 applies.

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 and resource: 'Link one existing canonical task to a Roadmap outcome,' with the scope narrowing to a single task. That distinguishes it from creation tools, though it does not distinguish it from the similarly named needfix_link_existing_task in the sibling set.

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?

The second sentence gives explicit usage ('Use this to attach a task to an outcome') and routes status changes to roadmap_transition. It does not mention prerequisites or clarify the relationship to needfix_link_existing_task, so it falls short of a full when/when-not treatment.

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

Deploy Server

Other Tools