Stele

Create a project

project

Manage projects. action = create (bootstrap a new project and its root component, owned by you). This is the first thing to call when you have no project yet; discover existing ones with list what:"projects". New projects are private unless you pass visibility:"public"; plans allow a limited number of private projects and unlimited public ones.

Input Schema

Name	Required	Description
`name`	Yes	Short display name for the project, at most 80 characters — a title, not a sentence. The project slug is derived from it and is hard to change later.
`action`	Yes	Run the create action.
`repo_url`	No	URL of the project's repository, if it has one.
`visibility`	No	Who can read this project: "private" (default) — only you and members you invite; "public" — anyone can read its graph, including everything written to it later. Plans include a limited number of private projects but unlimited public ones, so where creation fails on a plan limit, the same call as public succeeds. Which one fits is the user's call, since it decides who can read their graph.
`description`	No	One-line description of what the project is.

Output Schema

Name	Required	Description	Default
`data`	Yes	The action-specific result returned by Stele.
`action`	Yes	The action that produced this result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 22, 2026

addedInput schema / properties / description / maxLength
```
Added value: +500
```

changedInput schema / properties / name / description

Previous value: -"Project name. The project slug is derived from it and is hard to change later."New value: +"Short display name for the project, at most 80 characters — a title, not a sentence. The project slug is derived from it and is hard to change later."

addedInput schema / properties / name / maxLength
```
Added value: +80
```

Changed2 schema fields changedOct 21, 2026

changedInput schema / description

Previous value: -"action=\"create\": Create a new Stele project — a fresh knowledge-and-task graph owned by you — and return its `slug`. Use this when you have no project to work in yet (for example, the first time you connect); then pass the returned `slug` as `project_slug` on every other tool. `name` is required; `description`, `repo_url`, and `visibility` are optional. A root component is created for you automatically. Projects are private unless you pass `visibility: \"public\"`; plans allow a limited number of private projects but unlimited public ones, so if this fails on a plan limit, the error explains how to retry."New value: +"project action \"create\"."

addedInput schema / properties / action / description
```
Added value: +"Run the create action."
```

Changed2 schema fields changedOct 3, 2026

changedInput schema / description

Previous value: -"project action \"create\"."New value: +"action=\"create\": Create a new Stele project — a fresh knowledge-and-task graph owned by you — and return its `slug`. Use this when you have no project to work in yet (for example, the first time you connect); then pass the returned `slug` as `project_slug` on every other tool. `name` is required; `description`, `repo_url`, and `visibility` are optional. A root component is created for you automatically. Projects are private unless you pass `visibility: \"public\"`; plans allow a limited number of private projects but unlimited public ones, so if this fails on a plan limit, the error explains how to retry."

removedInput schema / properties / action / description
```
Removed value: -"Run the create action."
```

First observedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavior: default privacy, ownership by the caller, plan quotas on private vs unlimited public projects, and the retry-as-public workaround. It does not describe what else creation provisions beyond the root component, but that is minor given annotations.

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 action and then layers usage, alternative tool, and privacy/quota behavior without padding. The only wasted phrase is the generic "Manage projects" lead-in.

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

Completeness4/5

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

An output schema exists, so return values need no explanation, and annotations carry the mutation/safety story. The description covers when to call it, the alternative, and the main failure mode (plan limits), leaving only deeper post-creation side effects unspecified.

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%, and the `visibility` parameter's schema entry is itself highly detailed about default and plan semantics, so the description largely restates it. Baseline 3 is appropriate — the description adds no format or constraint detail beyond the schema.

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 pins the specific action (create) and resource (a project plus its root component), and explicitly contrasts with the sibling `list` for discovering existing projects. The vague opener "Manage projects" is slightly at odds with a tool whose action is a const of "create", but the operative sentence is precise.

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?

"This is the first thing to call when you have no project yet; discover existing ones with list what:\"projects\"" gives an explicit trigger condition plus the named alternative tool. It also states the fallback condition — retry as public when a private-project plan limit fails.

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

All Stele 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.