Skip to main content
Glama

create_project

Use this tool to create a new project for organizing content and context into a workstream. Projects group related documents and can include project-specific context items.

Workflow:
1) Provide a name for the project.
2) Optionally set visibility to "team" or "private" (default: team).
3) Optionally create a project brief at the same time — two ways:
   - `project_brief_content`: supply the FINISHED brief text directly. It is saved as the project brief document as-is. NO Studio Credits used.
   - `project_brief_instructions`: supply a PROMPT describing the brief; the AI generates the brief document for you. Uses Studio Credits (charged when the brief completes, at the model's cost: 1 credit = 5¢, rounded up; typically 1-2) — if the team is out of credits this returns an `insufficient_credits` error (code 402) and the project is NOT created; pass `project_brief_content` instead.
   If both are supplied, `project_brief_content` wins (no AI). When a brief is created, the response includes a `project_brief` object containing the brief's `content_id` — use that with `update_content` / `get_content` later.
4) Use the returned `project_id` with `create_content` to associate new content with this project.

**Links:** present `link_url` to the user exactly as returned — copy it character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

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

Input Schema

NameRequiredDescriptionDefault
nameYesThe project's display name, shown in the project list and used to label it everywhere. Required and must be non-empty (surrounding whitespace is trimmed); there is no length limit. If you also pass project_brief_instructions, this name is inserted into the AI prompt used to write the brief, so a descriptive name produces a better brief.
visibilityNoWho on the team can see the project. "team" (the default when omitted) makes it visible to team admins and editors as well as anyone added to the project; "private" limits it to people explicitly added as project members — the creator is added automatically. Set "private" only when the work should not be browsable by the wider team; these are the only two accepted values.
project_brief_contentNoFinished brief text to save DIRECTLY as the project brief (no AI, no Studio Credits). Takes precedence over project_brief_instructions.
project_brief_instructionsNoPrompt describing the brief to AUTO-GENERATE with AI (uses Studio Credits). Mutually exclusive with project_brief_content, which takes precedence.

Output Schema

NameRequiredDescriptionDefault
nameYesProject name.
link_urlYesDirect URL to view/open this project in Marcora.
project_idYesProject identifier.
project_briefNoPresent (non-null) only when `project_brief_content` or `project_brief_instructions` was supplied. Pass `content_id` to update_content / get_content later.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the rest and does: credit consumption with per-unit cost, the 402 insufficient_credits failure mode and the crucial fact that the project is NOT created in that case, precedence when both brief params are supplied, and the response shape (project_id, project_brief.content_id).

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?

The numbered workflow is well organized and front-loaded, and every clause about credits and precedence earns its place. The opening "Use this tool to..." is mildly redundant with the title, and the trailing **Links** paragraph concerns output formatting rather than creation, which slightly dilutes focus.

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 four-parameter creation tool with an output schema, the description covers creation, visibility defaults, both brief modes with cost implications, error behavior, and how to chain the returned IDs into create_content/update_content. Nothing an agent needs 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 the baseline is 3; the description still adds value by explaining the credit/AI distinction between project_brief_content and project_brief_instructions, the "content wins" precedence, and the default visibility of "team". The link-handling instruction is about output rather than parameters, so it does not add to this dimension.

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 new project") and immediately defines what a project is ("organizing content and context into a workstream", grouping documents and context items). It also distinguishes itself from data-manipulation siblings by naming create_content, update_content and get_content as follow-on tools.

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?

Provides an explicit numbered workflow with when-to-use guidance for the two mutually exclusive brief options, including the tradeoff (no credits vs. AI generation) and the fallback when credits are exhausted ("pass project_brief_content instead"). An agent has no ambiguity about which parameter path to take.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources