Plane MCP

create_project

Create a new project in a Plane workspace by providing a name and unique identifier, with options for visibility, description, and assigned members.

Instructions

Create a project. identifier is the short code (e.g. 'WEB'), uppercase and unique in the workspace. network: 0=secret, 2=public.

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": {
      "name": "<name>",
      "identifier": "<identifier>"
    },
    "name": "create_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`network`	No
`identifier`	Yes
`description`	No
`project_lead`	No
`default_assignee`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 6, 2026

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context by stating that identifier must be uppercase and unique in the workspace and that network values map to 0=secret and 2=public. However, it omits information about authentication, idempotency, failure behavior, or side effects, leaving notable gaps.

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 is concise and front-loaded, using only two sentences to state the purpose and key parameter constraints. Every sentence provides value without unnecessary repetition.

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

Completeness2/5

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

Given the tool has six parameters, no annotations, and no usage guidance, the description is not complete enough for an AI agent to confidently invoke it. Although an output schema exists, the lack of guidance on when to use the tool and insufficient parameter semantics for half the parameters make this description inadequate.

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 0%, so the description must compensate. It clearly explains the identifier format/uniqueness and the network value mapping, which are the least obvious parameters. However, it leaves description, project_lead, and default_assignee with only their titles, so the compensation is partial.

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?

The description explicitly states 'Create a project', which is a specific verb and resource, making the tool's purpose clear. Although it doesn't explicitly differentiate from sibling tools like create_work_item or update_project, the resource name itself provides that distinction.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus alternatives such as update_project or find_project. The description only provides parameter constraints, with no mention of use cases, prerequisites, or exclusions.

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