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; 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 | Upload a local folder's text files into the project. Unchanged files are skipped, differing ones need overwrite=true, and remote documents missing locally are never deleted; the project's uploaded files are untouched and cannot be pushed. Use dry_run=true to preview. Stops at the first file that would grow the project past its search threshold or its maximum (allow_search_mode=true accepts the threshold); files already pushed stay. Relay any |
| 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
Each tool targets a distinct resource (projects, documents, scheduled tasks) and action (list, get, create, update, delete, etc.). There is no ambiguity between tools within the same resource group, and cross-resource tools are clearly separated by naming.
All tool names follow a consistent verb_noun pattern (e.g., list_projects, create_project, read_document, delete_scheduled_task). The naming is predictable and adheres to the same convention throughout, making it easy to infer functionality.
With 17 tools, the server sits slightly above the ideal 3-15 range, but each tool serves a distinct and necessary purpose within the three resource domains (projects, documents, scheduled tasks). The count is justified and not bloated.
The tool surface provides full lifecycle coverage for all three resource types: projects have complete CRUD operations, documents support list/read/write/rename/delete plus sync operations (pull/push), and scheduled tasks have full CRUD. There are no obvious gaps that would hinder agent workflows.