Skip to main content
Glama
duckAsteroid

brindley

by duckAsteroid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

set_dependencies

Add or remove dependency links. Dependencies are the links under an initiative's ## Dependencies heading (blocking); ## Related links are non-blocking.

Instructions

Add or remove dependency links. Dependencies are the links under an initiative's ## Dependencies heading (blocking); ## Related links are non-blocking. Adds a bullet with a relative link (and optional why); removes the bullet(s) linking to the target — bullets only: a link inside a paragraph is left in place and reported with its line, to edit by hand. Refuses unknown initiatives and cycles.

Input Schema

NameRequiredDescriptionDefault
addNo
refYesInitiative (ticket/issue): "collection#n" (e.g. "lgm#22"), a bare number, or a path.
whyNoWhy the added dependency is needed (appended to each new bullet)
removeNo
collectionNo
related_addNo
related_removeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.0
    • changedInput schema / properties / ref / description
      Previous value: -"Initiative: \"collection#n\", a bare number, or a path."New value: +"Initiative (ticket/issue): \"collection#n\" (e.g. \"lgm#22\"), a bare number, or a path."
    • addedInput schema / properties / why
      Added value: +{
+  "description": "Why the added dependency is needed (appended to each new bullet)",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses side effects (adds a bullet with relative link and optional why), removal limits (bullets only; paragraph-embedded links are left in place and reported with their line), and error conditions (refuses unknown initiatives and cycles). This is exactly the behavioral context an agent needs for a mutating tool.

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?

Front-loads the core action, then layers the essential distinctions and limits. It is dense with parentheticals and long clauses but nearly every sentence carries behavioral weight, so waste is minimal.

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 7-parameter mutation tool with no annotations and no output schema, the description covers side effects, partial-failure reporting, and refusal cases thoroughly. The main gap is the undocumented `collection` parameter, which leaves an agent guessing at one input's role.

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 low (29%), so the description must compensate, and it does add meaning for add/remove/why and the related_* semantics via the blocking/non-blocking framing. However, parameters like `collection` and the exact roles of `related_add`/`related_remove` are never explained in prose.

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 pair and resource: 'Add or remove dependency links,' and immediately defines what a dependency is versus a non-blocking `## Related` link. An agent can tell what the tool operates on, though it never names a sibling alternative to distinguish itself from tools like `update` or `graph`.

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?

Usage is implied rather than stated: the Dependencies-vs-Related distinction helps an agent choose the concept, and the bullet-vs-paragraph rule scopes when removal will work. But there is no explicit 'use this instead of X' guidance against the many sibling mutation tools.

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