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

huly-mcp-selfhost

by JoKeks2023
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

release_issue

Clear an agent claim on a Huly issue so another agent can take it, specified by workspace and issue identifier.

Instructions

Release an agent claim

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>"
    },
    "name": "release_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNo
workspaceYes
identifierYesIssue id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.5.1

TDQS

C2.2/5.0
Behavior2/5

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

Annotations only declare destructiveHint=false; the description does not explain whether the caller must own the claim, what happens if no claim exists, whether the agent parameter defaults to the caller, or whether the operation is idempotent. For a mutation tool, these omissions leave meaningful behavioral uncertainty.

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

Conciseness2/5

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

The single phrase is front-loaded and wastes no words, but it is under-specified rather than appropriately concise for a three-parameter mutation. It cannot carry the required operational context.

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

Completeness1/5

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

Given a mutation with three parameters, low schema coverage, no output schema, and sparse annotations, the description is far too thin. It should explain the claim-release semantics, parameter roles, and expected effect.

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

Parameters2/5

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

Schema description coverage is only 33%, with just identifier documented as "Issue id". The description adds no meaning for agent or workspace, and only loosely hints that agent relates to the claim owner.

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

Purpose3/5

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

The description contains a specific verb ("Release") and a resource ("an agent claim"), but it never states that the claim is on an issue, despite the tool name release_issue and the required identifier parameter. It is more informative than the title alone but leaves the core object of the release operation ambiguous.

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 guidance on when to call this tool versus alternatives, nor is the obvious pairing with the sibling claim_issue mentioned. An agent must infer that this reverses a claim and when such a reversal is appropriate.

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