Skip to main content
Glama
arctop

Seamless

by arctop
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

project_create

Idempotent

Create a named project before any data is written, so auto-registered slugs get a proper name and description. Call project_list first to avoid duplicate slugs.

Instructions

Register a project up front, with a human-readable name and an optional description. You rarely need this: any durable write naming an unknown project slug (memory_write, notes_create, tasks_add, capture_url, trial_record) already registers that project, and a git repo maps itself to one on its first session. Reach for this only to give a project a proper name and description BEFORE anything is written into it, or to create one you will not write to yet -- an auto-registered project is named after its own slug until someone fixes it. Call project_list first: coining a near-duplicate of an existing slug is the failure mode here. To divide an existing project into children, use gardener_split rather than creating them by hand. The slug defaults to a slugified name; "global" and "all" are reserved, and an existing slug is an error, not an update -- this never renames or edits a project.

Input Schema

NameRequiredDescriptionDefault
nameYeshuman-readable project name
slugNooptional explicit slug
sessionNothe session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless
isolationNooptional isolation state (open|confidential|sealed); omit for open. open shares normally. confidential means nothing leaves: agents in other projects never read this one, and agents bound to it cannot write outside it. sealed adds the inbound half -- agents here see only this project: no global memories, no family, no cross-project reads. Set it at creation for work that is sensitive from the start; there is no tool to change it afterwards, because tightening detaches family and parent links and is an owner decision, made on an owner surface. Isolation requires a standalone project, so do not create an isolated child of another project.
descriptionNooptional one-line description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.4
    • addedInput schema / properties / session
      Added value: +{
+  "description": "the session to act as: the name session_start returned, the cc/<id> or cx/<id> on your briefing's 'Seam session' line, or a session ULID. It scopes and credits this call. Defaults to this connection's session; pass it on every call when session_start reports the connection as stateless",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.4.11
    • addedInput schema / properties / isolation
      Added value: +{
+  "description": "optional isolation state (open|confidential|sealed); omit for open. open shares normally. confidential means nothing leaves: agents in other projects never read this one, and agents bound to it cannot write outside it. sealed adds the inbound half -- agents here see only this project: no global memories, no family, no cross-project reads. Set it at creation for work that is sensitive from the start; there is no tool to change it afterwards, because tightening detaches family and parent links and is an owner decision, made on an owner surface. Isolation requires a standalone project, so do not create an isolated child of another project.",
+  "enum": [
+    "open",
+    "confidential",
+    "sealed"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the safety profile (non-read-only, non-destructive, idempotent, closed-world); the description adds the semantics that matter: existing slug is an error rather than an update, this tool never renames or edits, "global"/"all" are reserved, slug defaults to a slugified name, and isolation can only be set at creation because changing it later detaches family and parent links.

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?

Five dense sentences that are front-loaded with purpose and the "you rarely need this" caveat before the caveats and constraints. Slightly long, and a few clauses (auto-registered projects are named after their slug) could be tightened, but nearly every sentence carries routing or constraint information.

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?

For a 5-parameter mutation tool with no output schema and no annotations covering behavior, the description covers when to use it, duplicate-slug failure, reserved slugs, and irreversible isolation. The only gap is that it never hints at what a successful call yields (e.g., the created project/slug), which is minor given the deliberate omission of return-value detail.

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 3 baseline applies, but the description still adds value the schema lacks: the slug default rule (slugified name), the reserved slug values, and the error-not-update behavior for existing slugs. Isolation and session semantics largely restate the already-detailed schema text, hence not a 5.

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 verb and resource ("Register a project up front") and immediately scopes it against the many siblings that auto-register projects (memory_write, notes_create, tasks_add, capture_url, trial_record). An agent can tell project_create apart from those without opening a schema.

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?

It states when NOT to use the tool ("You rarely need this"), enumerates the alternative paths that already register projects, gives the only two legitimate use cases (naming before writes, creating unused projects), prescribes a prerequisite (call project_list first, citing duplicate slugs as the failure mode), and routes the split case to gardener_split.

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

Deploy Server

Other Tools