Skip to main content
Glama
Sign In
huly-mcp-selfhost

huly-mcp-selfhost

by JoKeks2023
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

remove_relation

Destructive

Unlink two issues by removing the "related" link between them, given the workspace and both issue IDs. Use it to correct mistaken or outdated issue relations.

Instructions

Remove the "related" link between two issues

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": {
      "workspace": "<workspace>",
      "identifier": "<identifier>",
      "relatedTo": "<relatedTo>"
    },
    "name": "remove_relation"
  }
}

Input Schema

NameRequiredDescriptionDefault
relatedToYesRelated issue id
workspaceYes
identifierYesIssue id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

B3.3/5.0
Behavior3/5

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

The destructiveHint annotation already flags this as a removal operation. The description adds useful scope clarification — only the link between two issues is removed, not the issues themselves — but says nothing about idempotency, behavior when the relation does not exist, or permission requirements.

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

Conciseness5/5

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

A single, front-loaded sentence with no filler. The verb and the scope constraint appear immediately, and no sentence is wasted.

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?

For a simple two-endpoint removal tool with a destructiveHint annotation and no output schema, the description is just barely sufficient. It omits what happens on a missing relation, whether the call is idempotent, and what the workspace parameter governs.

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 67%, with relatedTo and identifier already described. The phrase "between two issues" adds a small amount of relational meaning (the two parameters identify the endpoints of the link) but the workspace parameter's role is undocumented in both schema and description.

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 (Remove) and resource type (the "related" link between two issues). The word "related" implicitly separates it from remove_blocked_by/add_blocked_by, which handle different link types, but the description never explicitly contrasts with those siblings.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no reference to alternatives such as add_relation or remove_blocked_by. The agent must infer the usage context entirely from the tool name and the one-line purpose statement.

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