Frostbyte

list_areas

Read-onlyIdempotent

List every area in a project (areas group tasks by part of the product, such as Auth or Billing), sorted by name. Returns each area's name as a link, its ID and its colour, or "No areas found." since areas are optional. Call it to resolve an area the user names before setting areaId on create_task, update_task or list_tasks, to check for an existing area before create_area, and to get the ID for update_area or delete_area. Read-only. Use list_tasks with areaId to see an area's tasks.

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": "list_areas"
  }
}

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, from list_projects or the repo's .frostbyte.json

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / projectId / description

Previous value: -"The project ID"New value: +"The project ID, from list_projects or the repo's .frostbyte.json"

First observedNov 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the read-only and non-destructive annotations, it discloses name-based sorting, the returned fields and link formatting, and the exact empty-result message. It also explains that an empty result is normal because areas are optional, while the brief 'Read-only' statement merely reinforces the annotations.

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?

The description front-loads the operation and scope, then efficiently covers output behavior, invocation scenarios, and the relevant alternative. Although detailed, each sentence provides actionable information with negligible redundancy.

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?

For a simple two-parameter read tool, it covers scope, domain meaning, ordering, returned data, empty results, and relationships to all relevant siblings. The return-value details are especially valuable because no output schema is supplied.

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%, including projectId sourcing and detailed requirements for context, so the baseline applies. The description clarifies the project-scoped operation and downstream uses of area IDs but adds little direct meaning about either input parameter beyond the schema.

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 clearly states the verb, resource, and scope: listing every area within a project, sorted by name. It also defines what an area represents with concrete examples and distinguishes area listing from task listing and area-management siblings.

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 explicit workflows for resolving a user-named area before supplying areaId to create_task, update_task, or list_tasks, checking for duplicates before create_area, and obtaining IDs for update_area or delete_area. It also directs agents to list_tasks with areaId when the goal is to inspect an area's tasks.

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?