Frostbyte

task_add_blocker

Record blocker metadata on an active task without changing its To Do or In Progress status. task_start clears the blocker when work resumes.

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>",
      "taskId": "<taskId>",
      "reason": "<reason>",
      "context": "<context>"
    },
    "name": "task_add_blocker"
  }
}

Input Schema

Name	Required	Description
`reason`	Yes	Short prose explaining what is blocking the task
`taskId`	Yes	The task ID or number (FB-360 or 360)
`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/5.0

Behavior4/5

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

Adds real value beyond the annotations: annotations only say it's a non-destructive, non-idempotent write, while the description discloses that status is left untouched and that task_start clears the blocker, which is lifecycle information not encoded anywhere else. What it does not disclose is what happens on a second call for the same task — relevant given idempotentHint=false.

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?

Two short sentences, zero filler, and the most decision-relevant fact (status is not changed) is front-loaded. Nothing could be removed without losing meaning.

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 four-parameter, fully-documented write tool with no output schema, the description covers purpose, scope, and lifecycle adequately. The only meaningful gap is duplicate-blocker behavior and whether blockers are visible elsewhere (e.g. tasks_list_blocked), which would help an agent reason about follow-up calls.

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 every parameter (reason, taskId, projectId, context) is already documented, and the description adds no format or constraint detail beyond that. Baseline 3 is appropriate when the schema carries the burden.

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 and resource ('Record blocker metadata on an active task') and immediately clarifies the non-effect ('without changing its To Do or In Progress status'), which separates it from task_start and status-mutating siblings. It names task_start's role, though it does not mention tasks_list_blocked, which is the read counterpart an agent might otherwise reach for.

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 clear context for use: only on tasks that are active (To Do or In Progress), and it explains that the blocker is resolved via task_start. It does not state explicit exclusions (e.g. don't use on completed tasks) or whether repeated calls stack, but the when-to-use context is unambiguous.

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?