Skip to main content
Glama

create_area

Create an area, a named group of tasks for one part of the product (e.g. Auth, Billing). Call list_areas first and reuse an existing area when one fits; create one only when the user asked for it or agreed to it. If an area with exactly this name already exists, that area is returned and nothing new is created. Any project member can create areas; the new area appears live for the team and in the activity feed. Returns the area's ID, name and colour; pass the ID as areaId on create_task or update_task to place tasks in it.

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

Input Schema

NameRequiredDescriptionDefault
nameYesShort area name — a word or two (e.g. 'Auth', 'Billing'). Max 30 characters; must not be blank.
colorNoOmit to get the palette colour other areas use least. Set only when the user asks for a colour: pick the closest of #6366f1, #f97316, #22c55e, #ec4899, #06b6d4, #f59e0b, #8b5cf6, #14b8a6, #f43f5e, #3b82f6, avoiding one another area already uses (list_areas shows them), unless they give an exact 6-digit hex.
contextYesExplain 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."
projectIdYesThe project ID
descriptionNo1–2 short sentences on what this area groups.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Short area name — a word or two (e.g. 'Auth', 'Billing'). Max 30 characters."New value: +"Short area name — a word or two (e.g. 'Auth', 'Billing'). Max 30 characters; must not be blank."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior not in the annotations: any project member may create, the area appears live for the team and in the activity feed, and a name collision returns the existing area rather than creating a duplicate. The last point sits in mild tension with idempotentHint=false, but it is a name-dedup rule rather than a claim that repeated identical calls are side-effect free, so it reads as clarification rather than contradiction.

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?

Front-loaded with the definition, then the decision rule, then behavioral facts, then the return value — a sensible ordering with no filler sentences. It is on the long side for a create call, but each sentence carries distinct information.

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?

Covers definition, prerequisite list-and-reuse step, dedup semantics, permissions, team visibility, and what is returned, so the absence of an output schema is compensated. For a five-parameter create tool with full schema coverage this leaves nothing an agent needs missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all five parameters in detail and the baseline is 3. The description still adds cross-tool meaning by explaining that the returned ID should be passed as areaId on create_task or update_task, which the schema alone does not convey.

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?

Opens with a specific verb+resource ('Create an area') and immediately defines the resource as 'a named group of tasks for one part of the product (e.g. Auth, Billing)'. The sibling landscape (list_areas, update_area, delete_area, create_task) is implicitly distinguished by the definition plus the explicit routing to create_task at the end.

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?

Gives an explicit precondition ('Call list_areas first and reuse an existing area when one fits') and a gating rule ('create one only when the user asked for it or agreed to it'), naming the alternative tool. This is when/when-not/alternative guidance in three clauses.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources