Skip to main content
Glama
Attacktive

claude-projects-mcp-server

by Attacktive
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

push_documents

Sync a local folder into a Claude project: upload images as files, convert other UTF-8 files to text documents, with dry-run preview, overwrite protection, and backups.

Instructions

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 *.md matches no upload, so pass pattern='*' to send everything in the folder. Unchanged files are skipped, differing ones need overwrite=true (the replaced version is backed up locally first), and nothing remote that is missing locally is ever deleted. An uploaded image already in the project is left alone, since it offers no original to compare against or back up. Use dry_run=true to preview, including where the push would stop; that stop is an estimate, since a preview writes nothing to measure, and it cannot count uploads at all. 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 warning in the result to the user verbatim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
patternNo*.md
overwriteNo
project_idYes
source_directoryYes
allow_search_modeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / allow_search_mode
      Added value: +{
+  "default": false,
+  "title": "Allow Search Mode",
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Discloses the full consequence profile well beyond the single destructiveHint:false annotation: unchanged files are skipped, overwritten versions are 'backed up locally first,' nothing remote is ever deleted, and dry_run 'writes nothing to measure' so its stop and upload counts are estimates. It even flags the counterintuitive edge case that existing uploaded images are left alone. All claims are consistent with 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?

Long but every sentence earns its place: purpose, file modes, pattern gotcha, change semantics, edge case, dry-run limitation, stop thresholds, and warning relay each appear exactly once with no filler. The core purpose is front-loaded in the first sentence.

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 0% schema coverage, minimal annotations, and no output schema, the description must be self-sufficient, and it is: it covers file-type handling, overwrite/backup behavior, the no-deletion guarantee, dry_run accuracy limits, project-threshold stops, and even instructs relaying result warnings verbatim. Nothing an agent needs to invoke this correctly is left to guesswork.

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 carries the full burden, and it delivers: it explains the pattern default trap ('The default pattern `*.md` matches no upload'), the overwrite prerequisite, dry_run's estimation limits, and allow_search_mode's effect on the search-threshold stop. Every parameter except the self-evident project_id and source_directory receives direct semantic explanation.

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 specific verb and resource: 'Send a local folder's files into the project,' then details the two file-handling modes (PDF/PNG/JPEG/GIF/WebP become uploaded files; everything else becomes a UTF-8 text document). The direction and bulk scope unmistakably distinguish it from the nearest sibling pull_documents, which is the reverse operation.

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?

Gives explicit invocation guidance: 'differing ones need overwrite=true,' 'Use dry_run=true to preview,' and 'pass pattern='*' to send everything in the folder,' plus when allow_search_mode is relevant. It never names an alternative tool or a when-not-to-use condition, so it falls short of a 5, but the context for correct parameter usage is unambiguous.

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

Deploy Server

Other Tools