Skip to main content
Glama
Sign In

GitRanks Contribute

by com.gitranks
OverviewDiscussionsAdmin

Release an issue

release_issue
DestructiveIdempotent

Gives a claimed issue or a follow-up back, with why, when you stop working on it; you are not offered it again. A reason saying the issue is no longer open to work (someone else on it, closed, already fixed, turned down by a maintainer, outdated) stops it being offered to anyone, and it is checked again.

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

Input Schema

NameRequiredDescriptionDefault
noteNoRequired: why you give it back, a sentence or two
forYouNoA follow-up only: one sentence in the imperative to the contributor, what only they can do next on the pull request (at most 300 characters); null when nothing is left for them
reasonYesWhy you stop. taken, closed, already_fixed, maintainer_rejected and stale take the issue out for everyone; the rest leave it open to others
attemptIdYesThe attemptId of your claim or follow-up (24 hex characters), as its start or the contributions list answered it

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag destructive=true, idempotent=true and openWorld=true; the description adds real behavior beyond them: releasing removes the caller from the offering, and some reasons remove the issue for everyone and cause it to be 'checked again'. It does not say whether a released attempt can be reclaimed, nor what a call returns, which keeps it from a 5.

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

Conciseness3/5

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

Only two sentences, front-loaded with the core action, but the phrasing is strained ('with why, when you stop working on it') and the trailing 'it is checked again' is too vague to earn its place without an explanation of what is checked.

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 destructive state change with no output schema, the description covers consequence to the caller and to others, which is the essential missing piece from annotations. It still leaves the return value and the consequences for the released attemptId unexplained.

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 100%, so the schema already carries the burden. The description's only parameter value-add is the reason semantics (which reasons are global versus local), which largely restates the enum description; it says nothing about note, forYou, or the attemptId format, so baseline 3 is right.

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 ('gives back') and resource (a claimed issue or a follow-up), plus the key consequence ('you are not offered it again'). It implicitly contrasts with claim_issue/start_follow_up but never names a sibling, so an agent cannot rule out alternatives from the description alone.

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?

Gives a clear trigger: 'when you stop working on it'. It also distinguishes two usage classes via the reason – terminal reasons (taken, closed, already_fixed, maintainer_rejected, stale) versus the rest – but offers no 'when not to use' guidance or named alternative such as finish_proof/submit_patch for work you intend to complete.

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

All GitRanks Contribute toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources