claude-projects-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_PROJECTS_BASE_URL | No | Optional base URL override for the claude.ai API. | |
| CLAUDE_PROJECTS_IMPERSONATE | No | Optional browser fingerprint to impersonate with curl_cffi. | |
| CLAUDE_PROJECTS_SESSION_KEY | Yes | A full personal claude.ai account credential (sessionKey cookie) used to authenticate. | |
| CLAUDE_PROJECTS_BACKUP_DIRECTORY | No | Optional directory where backups of overwritten/deleted documents and projects are stored. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List the claude.ai / Claude Cowork projects on this account, each tagged with the organization that owns it. Use this to find a project uuid. |
| get_projectA | Read one project: its name, description, and instructions. Only this tool returns the instructions — list_projects does not carry them. |
| create_projectA | Create a project. organization_id is needed only when the account belongs to several organizations, and the error will name them if so. A private project is visible to you alone; a normal one is visible to the whole organization. |
| update_projectA | Change a project's name, description, or instructions. Only the fields you pass are touched; the rest keep their current values. Pass an empty string to clear one. |
| delete_projectA | Delete a project and everything in it. There is no server-side undo, so confirm_name must be set to the project's exact current name. Every text document and every file uploaded through the web UI is copied to the local backup directory first; if any of that fails, nothing is deleted. An upload with no downloadable original, such as an image, or one the listing gives no size for, blocks the deletion until it is removed in the web UI. |
| list_documentsA | List the text documents in a project, and under |
| read_documentA | Read one document, by file name or uuid. If several documents share the name, the newest is returned and |
| write_documentA | Create a document, or replace one with overwrite=true. The previous content is backed up locally before any replacement. Pass expected_uuid (from read_document) to refuse the write if a teammate has saved since you read it. Refused when the write would grow the project past its search threshold or its maximum, naming the documents most worth compacting and the largest uploaded files, which only the web UI can remove; allow_search_mode=true accepts the threshold, never the maximum. Relay any |
| rename_documentA | Rename a document, by uuid or by an unambiguous file name. The content is re-created under the new name before the original is deleted, with local backups first, so nothing is lost midway. A new name already in use is refused unless overwrite=true, which replaces its holder (backed up first). Relay any |
| delete_documentA | Delete a document, by uuid or by an unambiguous file name. The content is backed up locally first. A name shared by several documents is refused: pass the uuid to say which one. |
| pull_documentsA | Copy the project's documents and uploaded files into a local folder. Uploads such as PDFs come down as bytes, and each result row says which |
| push_documentsA | Send a local folder's files into the project: a PDF, PNG, JPEG, GIF, or WebP file goes up as an uploaded file, the way the web UI adds one, and every other file, other image formats included, becomes a text document and must be UTF-8. The default pattern |
| list_scheduled_tasksA | List Cowork scheduled tasks. Pass project_id for one project's tasks, or nothing for every task on the account. Schedules are cron expressions in UTC; a task with none runs only when started by hand. If the tasks cannot be matched to the project, every task in the organization is listed and |
| get_scheduled_taskA | Read one scheduled task by its id, including the prompt it will send. |
| create_scheduled_taskA | Create a scheduled task in a project. Omit cron_expression for a task that only runs when started by hand. cron_expression is five fields in UTC, not local time — '0 0 * * 1' is Monday 00:00 UTC. The answer carries next_run_at so the schedule can be checked before it matters. Relay any |
| update_scheduled_taskA | Change a scheduled task. Only the fields you pass are touched. Pass enabled=false to pause a task without losing its prompt or schedule, which is almost always better than deleting it. A schedule cannot be removed here — pause it instead. Relay any |
| delete_scheduled_taskA | Delete a scheduled task. Unlike documents, nothing is backed up first — a task is a prompt and a schedule, not content — so prefer update_scheduled_task with enabled=false if you only want it to stop running. Relay any |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 17 tools
Every tool targets a distinct resource-action pair: projects, documents, and scheduled tasks each have separate create/read/update/delete/list or equivalent operations. Even similar-sounding tools like read_document vs list_documents have clearly differentiated behaviors, with no overlapping purposes.
All tool names follow the verb_noun snake_case pattern consistently: list_projects, get_project, update_project, read_document, write_document, push_documents, etc. The only pluralization (list_* tools take plural nouns) follows a predictable list-versus-singular convention.
17 tools is slightly above the typical well-scoped range, but the count is justified by covering three distinct resource types (projects, documents, scheduled tasks) with near-complete lifecycle operations. Each tool serves a clear need and the set remains navigable.
The tool surface is comprehensive for the domain: projects have full CRUD, documents cover read/write/rename/delete/list/pull/push, and scheduled tasks have create/read/update/delete/list. Edge cases like overwrite safety, local backups, and search threshold handling are baked into descriptions, leaving no obvious dead ends.