claude-projects-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
The tools fall into three clearly separated resource families—projects, documents, and scheduled tasks—each with distinct verbs. Even closely related operations like pull_documents vs. write_document or get_scheduled_task vs. list_scheduled_tasks are unambiguous.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern, with plural nouns for list operations and singular nouns for single-item operations. The naming is predictable and makes the API surface easy to navigate.
Tool Count4/5
At 17 tools, this is slightly above the ideal 3-15 range, but the size is justified by covering three distinct subdomains: projects, documents, and scheduled tasks. There is little redundancy, and each tool maps to a meaningful operation.
Completeness4/5
The set covers full CRUD-style operations for projects, documents, and scheduled tasks, including useful safeguards like backups, overwrite checks, and dry runs. The main gap is that cron-less scheduled tasks are described as running 'when started by hand,' but no explicit manual run/trigger tool is exposed.
Average 4.3/5 across 17 of 17 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds modest behavioral context by noting projects are tagged with their owning organization and scoped to 'this account,' but it does not disclose other traits like pagination, response format, or permission requirements. This is acceptable given the annotation, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the verb and resource front-loaded in the first sentence and the use case in the second. Every word earns its place; there is no fluff or repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, yet the description still leaves the organization_id parameter ambiguous. The core purpose and use case are clear, but the missing parameter semantics and lack of output format details mean the description is not fully complete for an agent to use it confidently in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter, organization_id, with 0% schema description coverage. The description fails to explain the meaning or effect of this parameter, such as whether it filters projects by organization or retrieves all projects when null. This is a significant gap since the description was the only place to clarify the parameter's semantics.
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 uses a specific verb ('List') with a clear resource ('projects') and scope ('on this account'), and further specifies the output includes the owning organization. It clearly distinguishes from siblings like get_project and list_documents, and states the intended purpose ('find a project uuid').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to find a project uuid.' This establishes when to use the tool, but it does not explicitly mention when not to use it or call out alternatives like get_project once the uuid is known. Still, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, so the description adds value by explaining when organization_id is required and the error behavior, plus the visibility semantics of private vs normal projects. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main verb, and each sentence adds distinct contextual information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key creation nuances (org_id and privacy) but omits expected behavior like return value, permission requirements, or the purpose of the 'instructions' parameter. Given the sparse schema and annotations, it is functional but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates for organization_id (needed only in multi-org accounts) and is_private (visibility), but it provides no explanation for name, description, or instructions, leaving some parameters without added meaning.
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 starts with 'Create a project,' a specific verb+resource that clearly distinguishes it from sibling tools like update_project or delete_project. It adds context about organization_id and project visibility, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating a new project and provides situational guidance for organization_id and is_private, but it does not explicitly mention when to use this tool over alternatives like update_project or list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious behavior: local files that differ are kept and not overwritten unless overwrite_local=true. This adds valuable context beyond the readOnlyHint=false annotation, though it does not cover other aspects like permissions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes only necessary behavioral detail. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core action and overwrite behavior are covered, the description does not mention return values, preconditions (e.g., destination directory must exist), or error scenarios. Given the lack of an output schema, these omissions leave the tool's full behavior incompletely specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining overwrite_local's effect. Project_id and destination_directory are only implicitly defined through the overall action, and the schema titles already make their roles clear. The description adds no further detail on formats or constraints.
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 uses a specific verb 'Copy' and resource 'project's documents' into a local folder, clearly distinguishing pull_documents from siblings like push_documents and read_document. It states the direction and scope of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action, but does not explicitly mention when to use it over alternatives like read_document for single files or push_documents for the reverse operation. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, and the description adds useful behavioral context by noting the response includes the prompt the task will send. It does not contradict annotations, though it does not mention not-found behavior or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that front-loads the action, resource, and key return detail. Every word contributes meaning, with no filler or redundancy.
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 simple read-one operation with one parameter and a readOnly annotation, the description is largely complete. It tells the agent what it reads and highlights the important return content. It could be more complete with error or not-found behavior, but this is not essential for basic correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, task_id, with no schema-level description coverage. The description's phrase 'by its id' provides minimal semantic reinforcement, but it does not elaborate on the expected format, source, or meaning of the id beyond what 'Task Id' already conveys.
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 states a specific verb ('Read'), a clear resource ('one scheduled task'), and a distinguishing detail ('by its id, including the prompt it will send'). This clearly differentiates it from list_scheduled_tasks, which lists tasks, and from create/update/delete operations on scheduled tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single scheduled task when its id is known, but it does not explicitly state when to prefer this over list_scheduled_tasks or when not to use it. Usage context is reasonable but left to inference rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true. The description adds meaningful behavior beyond that: it explains what knowledge and duplicate_file_names represent, why duplicates occur, and instructs relaying warnings verbatim. This is valuable operational context that the structured annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The core purpose is front-loaded, and each subsequent sentence explains a non-obvious part of the response or an actionable follow-up. The description is compact while carrying substantial 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 one-parameter, read-only listing tool with no output schema, the description covers the important non-obvious output fields and the required user-facing warning behavior. It does not describe error cases or the full document list shape, but those are less critical given the tool's simplicity and the readOnly annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for project_id (0% coverage). The description's phrase 'in a project' and mention of 'project's size' clarify that project_id identifies the project whose documents are listed, but it does not explicitly document the parameter's format or requiredness. This is only partial compensation for the missing schema description.
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 first sentence states a specific verb, 'List', with a clear resource, 'the documents in a project'. The rest of the description clarifies what the returned metadata fields represent, making the tool's purpose distinct from document-level siblings like read_document and write_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for inspecting project contents and even suggests write_document with overwrite=true as the follow-up when duplicate_file_names appears. However, it does not explicitly contrast list_documents with pull_documents or read_document, nor does it state when not to use it. The guidance is useful but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint, so the description does the real work here. It discloses UTC cron semantics, the manual-run implication of missing cron, the fallback to organization-wide tasks, and the warning field that must be relayed verbatim. This goes well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: action and scope first, then schedule behavior, then fallback and warning handling. Every sentence adds value and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main behavior, fallback, and warning semantics well, but is incomplete for the full input schema because organization_id is never mentioned. With no output schema, the return shape is also left implicit, though the list behavior can be reasonably inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains project_id and the no-argument case, but completely omits organization_id, which appears in the schema with no description. Since schema description coverage is 0%, the description was responsible for documenting all parameters and only covered one of two.
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 clear action ('List') and specific resource ('Cowork scheduled tasks'), and distinguishes itself from sibling tools like get_scheduled_task by describing a list operation. Also clarifies the scope options, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives practical scoping guidance ('Pass project_id for one project's tasks, or nothing for every task on the account'), but it does not explicitly route the agent to alternatives such as get_scheduled_task for a single task or explain when not to use this tool. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral detail: duplicate names resolve to the newest document, a 'warning' is emitted naming other matches, and the warning must be relayed verbatim to the user. This goes beyond annotations and provides actionable handling instructions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first leads with the core action and the second is tightly scoped to an edge case and required user-facing action. No fluff or repetition of schema fields.
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 two-parameter read tool with readOnlyHint, the description covers identifier formats and the key duplicate-name edge case with a specific instruction. It does not describe not-found behavior or return structure, but the operation is simple and the absence of an output schema lowers that requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description must compensate. It explains the 'document' parameter as accepting either a file name or uuid, which adds real meaning. However, 'project_id' is left unexplained beyond its title, so parameter semantics are only partially addressed.
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 states a specific verb and resource ('Read one document') and clarifies the identifier formats accepted (file name or uuid). The duplicate-name warning behavior further distinguishes it from sibling tools like write_document or delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single document by name or uuid but offers no explicit guidance on when to choose this over siblings such as pull_documents or list_documents. There are no exclusions or alternative routing, so the agent must infer selection from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds that the tool returns name, description, and instructions, and that instructions are unique to this tool. While it does not mention permissions or error handling, for a read-only tool with readOnlyHint this is adequate context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, front-loading the core action ('Read one project') and then adding a crucial distinguishing detail. Every sentence earns its place.
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 simple read tool with one parameter and a readOnlyHint annotation, the description covers the purpose, the returned content (name, description, instructions), and a key differentiation from list_projects. No output schema exists, but the description adequately communicates what is returned. A minor gap is the lack of error-case mention, but the core context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter project_id with 0% description coverage. The tool description does not mention project_id at all, nor does it clarify how to identify the project. Given the low schema coverage, the description needed to compensate but did not, relying on the parameter name alone.
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 uses the specific verb 'Read' with the resource 'one project' and explicitly differentiates itself from the sibling tool list_projects by noting that it is the only tool that returns instructions. This clearly states what the tool does and why it is distinct.
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?
The description explicitly provides an alternative and a condition for use: 'Only this tool returns the instructions — list_projects does not carry them.' This directly tells the agent when to choose this tool over a sibling, and implies when not to use it (for listing without instructions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses that content is backed up locally first and that ambiguous names are refused, adding safety and error-condition context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundant information; each sentence adds a distinct piece of information (action/identifiers, backup, ambiguity handling).
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?
Covers the action, identification methods, backup behavior, and ambiguity handling, but omits any explanation of the project_id parameter and does not describe success/error returns. Adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that the 'document' parameter can be a uuid or unambiguous file name, but it does not explain the 'project_id' parameter at all. With 0% schema coverage, this leaves a gap for one of the two required parameters.
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 clearly states the action (Delete a document) and the resource (document), with additional specificity about the two identifiers (uuid or unambiguous file name). This distinguishes it from sibling tools like delete_project and other document operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use uuid versus file name based on ambiguity, and notes the refusal behavior. It does not explicitly compare with alternative tools or state when not to use this tool, but it gives clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the destructiveHint annotation by explaining the safe rename sequence: content is re-created under the new name, the original is deleted only afterward, and local backups are made first. It also discloses overwrite behavior and instructs relaying warnings verbatim. This gives the agent a strong mental model of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the core operation, then explains safety behavior, overwrite behavior, and warning handling in logical order. Every sentence earns its place.
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?
The description is nearly complete for this tool: it covers how to identify the document, overwrite behavior, backup safety, and warning handling. The main gaps are no explicit mention of the project_id parameter's role and no detail about the success-return shape beyond warnings, both of which are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the bare parameter names. It adds useful meaning for 'document' (uuid or unambiguous file name) and 'overwrite' (replaces existing holder after backup), and implicitly defines 'new_file_name'. However, it does not explain 'project_id' or any file-name format constraints, leaving some parameter semantics to inference.
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: 'Rename a document'. It also clarifies the identifier forms ('by uuid or by an unambiguous file name'), making the operation unambiguous. This clearly distinguishes it from sibling tools like read_document, write_document, and delete_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operating context: when the new name is already in use, overwrite=true is required, and it explicitly says refusal happens otherwise. It does not explicitly name alternative tools or state when not to use this tool, but the rename purpose is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=false, indicating non-destructive behavior. The description adds meaningful behavioral detail beyond this: partial updates and the ability to clear fields with an empty string. It does not mention permissions, return values, or error handling, but the mutation semantics are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver all essential information with no filler. The first sentence front-loads the core purpose, and the second provides critical partial-update/clearing behavior. Every clause earns its place.
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?
The tool has no output schema, but the description covers the main contextual needs: what fields can be changed, that updates are partial, and how to clear values. It omits return value/error behavior, but given the low complexity and the presence of destructiveHint=false annotation, the description is largely complete. A more explicit mention of whether an updated project object or just a status is returned would push it to a 5.
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?
With 0% schema description coverage, the description compensates by naming the three updatable fields (name, description, instructions) and clarifying their semantics: only passed fields are changed, and empty strings clear values. The required project_id is not described, but its role is implied by the tool name and schema, and the field-level semantics for the others are well explained.
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 begins with a specific action verb and resource: 'Change a project's name, description, or instructions.' It clearly distinguishes update_project from sibling CRUD tools like create_project, get_project, and delete_project by naming the exact mutable fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: updating existing projects, with a partial-update semantic ('Only the fields you pass are touched'). It does not explicitly name alternatives or state when not to use it, but the sibling tool names and 'change' verb make the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the backup process (documents copied locally), the failure safety (nothing deleted if backup fails), and the irreversible nature (no undo). This enriches the behavioral model significantly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences front-load the main action, present a safety warning, and detail the backup mechanism. Every clause serves a purpose without redundancy.
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 tool with two parameters and no output schema, the description covers the deletion scope, undo limitation, required confirmation, pre-deletion backup, and failure behavior. It is fully self-contained and explains all critical aspects a user needs to know before invoking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameter semantics, and the description explains confirm_name (must match exact current project name), but project_id is only implied by the tool name. It adds some value but does not fully compensate for the lack of schema descriptions for both parameters.
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 clearly states the action (delete) and the resource (a project and every document in it), which distinguishes it from sibling tools like delete_document. The scope is explicit and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical usage condition: confirm_name must be set to the exact current name. It also notes the absence of server-side undo, warning the user when to be cautious. It does not explicitly name alternatives, but the destructive context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses that there is no backup, that the task is just a prompt and schedule, and that the result may contain a warning about an already-deleted task that must be relayed verbatim. This is meaningful non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences deliver the core action, the key caution, the preferred alternative, and the warning-handling requirement with no filler. The most important information is front-loaded.
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 simple one-parameter destructive tool with no output schema, the description covers the important edge case (already-deleted task), the lack of backup, and the alternative. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain task_id, its format, or how it identifies the target beyond the obvious property name. The single parameter is inferable, but the description itself adds no parameter semantics.
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: 'Delete a scheduled task.' It also differentiates itself from update_scheduled_task and document deletion, so an agent can clearly distinguish this from siblings.
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?
Explicitly tells the agent when not to use this tool: prefer update_scheduled_task with enabled=false if the goal is only to stop execution. It also notes that no backup is made, reinforcing that this is for permanent deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false as an annotation, the description carries the full behavioral burden and delivers: unchanged files are skipped, remote-only documents are never deleted (consistent with destructiveHint=false), the push stops at the first file exceeding the threshold, and already-pushed files persist on partial failure. The 'relay warning verbatim' instruction is notable behavioral disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that front-load the core action and then progress logically: sync semantics → preview → threshold/limit behavior → warning relay. Every sentence earns its place; there is no filler or repetition.
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 6-parameter tool with no output schema and no per-parameter schema descriptions, the description covers purpose, parameter semantics (except pattern), failure behavior, and hints at the result via the warning field. The only meaningful gaps are the pattern parameter and a fuller description of the return value.
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 description coverage is 0%, so the description must compensate — and it largely does: dry_run, overwrite, and allow_search_mode are all explained; project_id and source_directory are contextually implied. However, the pattern parameter (default '*.md') is never mentioned, leaving one of six parameters undocumented.
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 first sentence states a specific verb + resource ('Upload a local folder's files into the project') with unambiguous directionality. The push/pull contrast with sibling pull_documents makes it instantly distinguishable, and the sync semantics (skip unchanged, never delete remote) further sharpen scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage conditions: use dry_run=true to preview, overwrite=true for differing files, allow_search_mode=true to accept the threshold, and instructs relaying warnings. It does not explicitly name alternatives or when-not-to-use states, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the single destructiveHint=false annotation: it clarifies the cron timezone is UTC, warns against local-time assumptions, reveals that the result contains next_run_at, and instructs relaying any warning verbatim. These are genuinely useful behavioral disclosures that are not available from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover the core action, the most error-prone parameter, and a response-relay requirement without waste. The most important caveats are front-loaded, and every sentence earns its place.
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?
Despite having no output schema, the description tells the agent what key response fields to expect (next_run_at and warning) and gives enough parameter guidance to make a correct first call. The sibling tool list provides surrounding context, and nothing essential to invoking the tool 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?
With 0% schema description coverage, the description carries the parameter-explanation burden. It thoroughly explains cron_expression—its five-field format, UTC semantics, an example, and how to omit it. Other parameters like project_id, name, prompt, and model are self-explanatory from their names, though model gets no additional guidance.
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 'Create a scheduled task in a project,' naming a specific verb, resource, and scope. This cleanly distinguishes it from sibling operations like update_scheduled_task, delete_scheduled_task, and list_scheduled_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear conditional: omit cron_expression for a task that only runs when started by hand, implying the alternative is to include it for time-based schedules. It provides useful context but does not explicitly name alternative tools or state when not to use create_scheduled_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, so the description carries the behavioral burden. It clearly explains partial updates, the semantics of enabled=false as pausing, the fact that schedules cannot be removed here, and instructs the agent to relay any warning from the result verbatim. This is rich, useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each carrying distinct value: partial-update semantics, pause-vs-delete guidance, schedule-removal limitation, and warning handling. The most important behavior is front-loaded, and there is no filler.
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 six-parameter mutation tool with no output schema, the description covers the critical behavioral nuances and post-call responsibility (relaying warnings). It does not describe the full success return shape, but the warning instruction addresses the main non-obvious part of handling the result.
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 description coverage is 0%, so the description must compensate. It adds important meaning to enabled=false as pausing, explains that unspecified optional fields are left untouched, and warns that cron_expression cannot be used to remove a schedule. The remaining parameters (name, model, prompt, task_id) are self-explanatory enough from their names, though not individually documented.
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 states a specific action and resource: 'Change a scheduled task.' It adds the crucial partial-update semantic ('Only the fields you pass are touched') and implicitly differentiates this from the delete_scheduled_task sibling by explaining that pausing via enabled=false is preferable to deletion.
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?
The description gives explicit when-to-use guidance: use enabled=false to pause instead of deleting, and do not attempt to remove a schedule through this tool—pause it instead. This directly addresses the main alternative and limitation, leaving no ambiguity about the key decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotations (only destructiveHint=false), the description discloses backup-before-replace, optimistic concurrency refusal via expected_uuid, refusal conditions for search threshold/maximum, the exact allow_search_mode semantics, and the need to relay any warning. This is exceptionally transparent for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: core action first, then safety, concurrency, refusal conditions, and result handling. It uses efficient semicolon-separated clauses rather than padded prose, and the most important usage information is front-loaded.
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?
With no output schema, the description still tells the agent how to handle a key part of the result ('Relay any warning in the result to the user verbatim') and enumerates all refusal modes. For a 6-parameter mutation tool, this covers the non-obvious behavior an agent needs to call it successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the semantic load. It does: overwrite is defined as replace behavior, expected_uuid is explained as a concurrency guard, and allow_search_mode is precisely distinguished (accepts threshold, never maximum). Even the file-name-without-extension warning adds parameter-adjacent meaning beyond the schema titles.
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 precise verb and resource: 'Create a document, or replace one with overwrite=true.' It clearly separates create vs replace and stands apart from siblings like read_document, rename_document, and delete_document by describing the write/update action. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear when-to-use context (create a new document, or replace an existing one) and even points to read_document for expected_uuid. It stops short of explicitly contrasting with alternatives such as rename_document or delete_document or stating when not to use this tool, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![claude-projects-mcp-server MCP server](https://glama.ai/mcp/servers/Attacktive/claude-projects-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Attacktive/claude-projects-mcp-server)

Score Badge

Copy to your README.md:

[![claude-projects-mcp-server MCP server](https://glama.ai/mcp/servers/Attacktive/claude-projects-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Attacktive/claude-projects-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Attacktive/claude-projects-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server