Marcora

update_project

DestructiveIdempotent

Use this tool to update mutable fields on an existing Marcora project.

To set or change the project's brief, pass an existing content UUID as `project_brief_id` - the tool resolves it to the appropriate document wrapper internally. **If the content isn't already attached to the project, this tool will attach it for you AND set it as the brief in one call** — you don't need to add the content separately first.

**To READ the existing brief instead of replacing it, do not come here.** `get_project` returns the brief as a `project_brief` block with an excerpt, and `get_content` with that block's `content_id` returns the full body. Read it before you change it — the brief is the project's authoritative statement of premise and structural decisions, and overwriting it blind discards them.

Important notes:
- Only fields you pass are updated (PATCH semantics). Omit a field to leave it unchanged.
- `visibility` must be exactly `team` or `private`.
- `status` must be exactly `active` or `archived`.
- `name` must be non-empty when provided.

Common use cases:
- "Set the brief on the Acme Launch project to <content>" -> call with project_id and project_brief_id (works whether or not the content is already in the project).
- "Rename the project" -> call with project_id and name.
- "Make the project private" -> call with project_id and visibility="private".
- "Archive the project" -> call with project_id and status="archived".

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": {
      "project_id": "<project_id>"
    },
    "name": "update_project"
  }
}

Input Schema

Name	Required	Description
`name`	No	New project name. Must be non-empty when provided. Omit to leave unchanged.
`status`	No	New project status. "active" for ongoing work; "archived" to hide from the active list while preserving content. Setting to "active" requires available active-project usage. Omit to leave unchanged.
`project_id`	Yes	UUID of the project to update. Get from list_projects or get_project.
`visibility`	No	New visibility setting. "team" makes it visible to all team members; "private" restricts to the creator and explicit project members. Omit to leave unchanged.
`project_brief_id`	No	UUID of an existing content item to set as this project's brief. If the content isn't already attached to the project, this tool will attach it AND set it as the brief in one call.

Output Schema

Name	Required	Description
`message`	No	Human-readable status message.
`project`	No	The updated project record.
`success`	Yes	True if the update applied successfully.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, and the description adds real value on top: PATCH omit-to-leave-unchanged semantics, the non-obvious side effect that passing `project_brief_id` will attach unattached content, and an explicit warning that overwriting the brief discards premise/structural decisions. It stops short of describing error behavior or what a successful response returns, but the output schema covers returns.

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?

Well front-loaded: purpose, then the riskiest parameter, then constraints, then use cases. There is noticeable redundancy, though — the 'attaches it AND sets it as the brief in one call' behavior appears in both the description body and the schema, and the bolded emphasis is heavy for a tool definition.

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 destructive five-parameter mutation with an output schema and full annotation coverage, the description supplies everything an agent needs: validation rules, PATCH semantics, the attach-as-side-effect gotcha, and a read-before-write safeguard. Nothing material about invoking it 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, and the description earns the extra point by explaining the resolution semantics of `project_brief_id` (UUID of existing content, resolved to a document wrapper) and by restating the enum whitelists for `visibility` and `status` in a usage-oriented frame. Some of that duplicates the schema, which keeps it from 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?

Opens with a precise verb+resource+scope: 'update mutable fields on an existing Marcora project', which names both the action and its boundary (only mutable fields). It also explicitly distinguishes itself from the read path by naming `get_project` and `get_content` as the tools for reading the brief.

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 it ('To READ the existing brief instead of replacing it, do not come here') and names the exact alternatives. Four concrete use-case examples map natural-language requests to specific parameter combinations, so an agent can route unambiguously.

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

All Marcora 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?