Frostbyte

release_read_active

Read-onlyIdempotent

Read the project's active release (a project has at most one): its name as a link, its ID, and how many of its tasks are done, as a count and a percentage. Returns "No active release." when none is active. Use it to answer how the current release is going, or to get its ID for list_tasks or create_task. Read-only. dashboard_snapshot already shows the active release with its done count, so skip this after it; an unfiltered first page of list_tasks names the active release and its ID when any tasks are active, but not its progress. Use get_release for its task list, dates and notes, and list_releases for the others.

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": {
      "projectId": "<projectId>",
      "context": "<context>"
    },
    "name": "release_read_active"
  }
}

Input Schema

Name	Required	Description	Default
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`projectId`	Yes	The project ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, yet the description still adds value: the cardinality invariant (at most one per project), the exact returned fields, and the literal empty-state string "No active release." that an agent must recognize. It also discloses that progress is absent from list_tasks output, which affects when this call is actually needed.

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?

Content is front-loaded with purpose and return fields before the routing guidance, and nearly every clause carries information. The standalone "Read-only." sentence is redundant with readOnlyHint=true and slightly pads an already dense block, which keeps it from a 5.

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

Completeness5/5

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

With no output schema, the description takes on the burden of describing return values and does so precisely, including the empty result case. For a two-parameter read tool it covers purpose, output, deduplication against dashboard_snapshot, and sibling routing without gaps.

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%, so both projectId and the required context parameter are already documented in the schema. The description implies that the project is the scope but adds no format, constraint, or edge-case detail for either parameter. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

The description uses a precise verb+resource ("Read the project's active release") and immediately constrains scope with "a project has at most one," then enumerates exactly what comes back: name as a link, ID, done count and percentage. It is clearly distinguishable from get_release and list_releases by scope and payload.

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

Usage Guidelines5/5

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

It gives positive triggers (answering how the current release is going, getting the ID for list_tasks/create_task), an explicit when-not (skip after dashboard_snapshot, which already shows the active release and done count), and routes to specific alternatives (get_release for task list/dates/notes, list_releases for other releases). Even the partial-coverage case of an unfiltered list_tasks page is covered.

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

All Frostbyte tools Inspect

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

Need Help?