Kaiku

Create project

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

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.
`openSourceRepo`	No	Optional: the address of the public repository this is the open source project of, e.g. 'https://github.com/owner/repo' or a GitLab project's address. The host is asked without a token whether it is public; a private or missing one refuses the project. Being open source opens nothing by itself — set_project_public does, and needs it.
`projectTypeKey`	No	Jira project type: 'software' (the default), 'business' or 'service_desk'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / openSourceRepo

Added value: +{
+  "default": null,
+  "description": "Optional: the address of the public repository this is the open source project of, e.g. 'https://github.com/owner/repo' or a GitLab project's address. The host is asked without a token whether it is public; a private or missing one refuses the project. Being open source opens nothing by itself — set_project_public does, and needs it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false) by disclosing idempotent retry semantics (same key+name returns created:false), key-collision refusal that names the conflicting project, refusal of taken keys instead of auto-suffixing, and that openSourceRepo is host-verified without a token. The auth model for workspace admins and parent-subproject leads is spelled out.

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-loads the authorization constraint and the key-immutability warning before the idempotency and subproject details. It is dense and fairly long, but every sentence carries a distinct operational fact; no filler.

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?

A mutating, 7-parameter tool with no output schema needs to explain the return and failure modes, and it does: created:false on retry, refusal with the conflicting project's name, and host-verification failure for openSourceRepo. Nothing an agent needs in order to call this correctly is 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 baseline is 3; the description still adds real meaning beyond the schema — that the key is always caller-supplied and never generated, that the lead defaults to the caller and is required for later configuration, and that parentKey implies inherited access so only non-inherited people need adding.

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?

States a specific verb and resource ("create a project") and enumerates what gets created — a key, a starter board, a wiki space — which distinguishes it immediately from create_issue, create_project_rule and create_wiki_page. The scope (workspace-level project provisioning) is unmistakable.

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?

Explicitly gates usage on role ("Administrators only", plus parent lead for subprojects) and explains that deletion is not available here, which routes the agent away from using this tool as a lifecycle manager. It does not name a concrete alternative for removal, so it stops short of full when/when-not/alternatives coverage.

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

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?