AgentParcel MCP Server

Overview Schema Source Related Servers Discussions Admin

Zip files/folders and split into parts

split_files

Packs large files or folders into size-capped ZIP parts for uploads, preserving folder structure and returning each part's path and size.

Instructions

Use when files or folders that are not a .zip are too big to upload (a big log, video, dataset, project folder, several files). Packs the inputs into <archive_name>.zip (folders keep their structure) and splits it into standalone zip parts <= max_mb, in one step, without writing the full zip anywhere permanent. A single file bigger than a part is cut into .001/.002 pieces inside consecutive parts. Returns every part's absolute path and size. Rebuild with the rebuild tool (extract=true gives the files back as a folder).

Input Schema

Name	Required	Description
`paths`	Yes	Absolute paths of files and/or folders to include.
`max_mb`	No	Max size of each part in MiB (1 MB here = 1,048,576 bytes). Default 19.5. If your upload limit is in decimal MB (e.g. 20 MB = 20,000,000 bytes) pass max_bytes or a smaller max_mb.
`preset`	No	Pick the part size from a platform cap. custom (default) uses max_mb/max_bytes. chatgpt-dot: 19,000,000 bytes (under a 20,000,000 byte ChatGPT Dot cap). chat-512: 500,000,000 bytes (under a 512,000,000 byte chat cap; products differ). discord: 24,000,000 bytes for the free 25 MB limit (Nitro is higher and is not this preset). email: 24,000,000 bytes under a common 25 MB attachment cap (other providers differ). github-release: 1,900,000,000 bytes under GitHub's 2 GB release-asset limit. A named preset sets the part size. max_mb is ignored. max_bytes together with a named preset is an error. These limits can change; confirm the current one before a large send.
`max_bytes`	No	Exact max size of each part in bytes. Overrides max_mb. Do not combine with a named preset.
`output_dir`	No	Absolute folder to write into. A new sub-folder '<name>_split' (or ' (2)', ' (3)'... if taken) is created inside it. Default: the folder of the input.
`archive_name`	No	Name for the archive and parts (default: the single input's name, or 'files').
`include_apps`	No	Also write AgentParcel-apps.zip (AgentParcel for Windows, Mac and Linux, about 0.35 MB; not a part) so a human recipient can rebuild.
`unpack_inner`	No	Unpack zips found inside so their files can be spread over parts and opened directly; rebuild puts the inner zips back (same files, verified).
`create_output_dir`	No	Create output_dir if it does not exist (otherwise that is an error).

Output Schema

Name	Required	Description	Default
`ok`	No
`parts`	No
`set_id`	No
`max_bytes`	No
`output_dir`	No
`part_count`	No
`how_to_rebuild`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (not read-only, non-destructive, non-idempotent, closed-world), so the description's added value is the behavior: no permanent full zip is written, folders keep structure, an oversized single file is cut into .001/.002 pieces inside consecutive parts, and every part's absolute path and size is returned. It could have noted that repeat runs land in numbered '<name>_split (2)' folders, which is idempotency-relevant, but that is covered in 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?

Front-loaded with the usage trigger, then output shape, then the edge case, then the rebuild path. Four dense sentences with no filler; every clause carries information the agent needs.

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 9-parameter mutation tool with annotations and an output schema, the description covers the trigger, the archive/parts output contract, single-file splitting, and the recovery tool. Nothing an agent needs to select or invoke 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 a 3 is the baseline. The description still adds meaning by tying archive_name to the '<archive_name>.zip' output naming and by explaining how max_mb interacts with a single oversized file (split into .001/.002 pieces inside consecutive parts), which the per-property text does not spell out.

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 ('Packs the inputs into <archive_name>.zip ... and splits it into standalone zip parts') and scopes it precisely with 'files or folders that are not a .zip', which cleanly separates it from split_zip and split_any_file. An agent can pick it without opening the schema.

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?

'Use when files or folders that are not a .zip are too big to upload' gives a concrete trigger, and 'Rebuild with the rebuild tool (extract=true gives the files back as a folder)' points to the reverse operation. The exclusion is expressed as a condition rather than by naming split_zip, so the sibling routing is implied rather than explicit.

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

Deploy Server