Kaiku

create_project

Administrators only: create a project — a new key, a starter board, and its own wiki space, led by you unless you name someone else. The key is yours to choose and is never invented for you: one already taken is refused, naming the project holding it, rather than quietly becoming KEY2 — the key shows in every issue key, link and commit, and renaming it later costs more than creating the project did. Calling it again with the same key and name returns that same project with created:false, so a retry after a lost answer cannot make a second project. Deleting one is not offered here: that is a decision a person makes looking at what is inside. Who may: an administrator of this workspace, or — for a subproject — the lead of the parent, since it hands over their own project's people.

Input Schema

TableJSON Schema

Name	Required	Description
`key`	Yes	Project key, 2–10 characters: a letter followed by letters or digits, e.g. 'BGS'. Uppercased.
`lead`	No	Username or email of the project lead. Defaults to you — a project with no lead is one nobody can configure: export, colour, the bgs connection and access grants all need a lead or an admin.
`name`	Yes	Project name, e.g. 'Background agents'.
`parentKey`	No	Key of the project this one is a subproject of. Everybody who may reach the parent may reach this project too, in the role they hold there — so add only the people the parent does not already have. Leave it out for a project of its own. One level: a subproject cannot have subprojects. The key here is still an ordinary key ('KYCB2B', not 'KYC-B2B'), because it is what every issue key is built from.
`description`	No	What the project is for. Markdown.
`projectTypeKey`	No	Jira project type: 'software' (the default), 'business' or 'service_desk'.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden — and it succeeds: it discloses key-conflict refusal, idempotent retry behavior, key visibility in issue keys and commits, cost of renaming, absence of delete, and permission inheritance for subprojects.

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 long but every sentence carries a non-obvious behavioral consequence: permissions, key semantics, retry safety, deletion policy, and subproject leadership. It is front-loaded with the primary purpose and audience before diving into edge cases.

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 mutation tool with 6 parameters, no annotations, and no output schema, this description is unusually complete. It covers who may call it, side effects, idempotency, conflict behavior, and subproject role inheritance — enough for an agent to invoke it correctly and anticipate outcomes.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: the key is never auto-invented, taken keys are refused with the naming project, the lead default carries configuration implications, and parentKey grants inherited access with the parent's roles.

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 opens with a specific action and resource: 'create a project — a new key, a starter board, and its own wiki space.' It clearly distinguishes this from siblings like create_project_rule and create_wiki_page by naming the full project-scope side effects.

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?

It gives explicit audience guidance ('Administrators only', parent lead for subprojects) and explains retry behavior. It does not directly name alternatives or say 'use this instead of X', but the context is clear enough for a create-project tool.

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

All Kaiku tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?