AgentParcel MCP Server

Overview Schema Source Related Servers Discussions Admin

Split a .zip into smaller standalone zips

split_zip

Splits an oversized .zip into smaller, individually valid zip parts under a chosen size limit for upload, returning each part’s path and byte size so all parts can be sent.

Instructions

Use when a .zip is too big to upload/attach. Splits it into parts named _part01.zip, _part02.zip ... each <= max_mb, and each a complete, valid zip that opens on its own (files are never cut unless a single file is bigger than a part; such files become .001/.002 pieces). Returns absolute paths and byte sizes of every part: upload all of them. Never overwrites anything. The original can be rebuilt exactly (SHA-256 verified) with the rebuild tool or the AgentParcel apps. For anything that is not a .zip (folders, logs, videos...) use split_files.

Input Schema

Name	Required	Description
`path`	Yes	Absolute path of the .zip to split.
`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.
`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.6/5.0

Behavior5/5

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

Goes well past the annotations: it guarantees no data loss ('files are never cut unless a single file is bigger than a part'), specifies the naming scheme and the .001/.002 fallback, states 'Never overwrites anything', and describes exact rebuildability via SHA-256 with the rebuild tool. It is consistent with destructiveHint=false and readOnlyHint=false (files are created, nothing is destroyed).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the trigger, then the output contract, then the rebuild and sibling routing. Every sentence carries distinct information, though the parenthetical about single-large-file .001 pieces and the rebuild note make it denser than strictly needed.

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 an output schema and full param coverage, the description still covers what an agent most needs to know: how many files come back, that all must be uploaded, that the original is exactly recoverable, and that nothing is overwritten. No meaningful gap remains for an 8-param tool.

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 100% and the preset enum is documented param-by-param with byte values, so the schema already carries the semantics. The description only reinforces the max_mb-per-part constraint and part naming, adding little beyond structured fields; baseline 3 applies.

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 ('Splits it into parts named <name>_part01.zip...') and immediately bounds scope by excluding non-zip inputs in favor of split_files. An agent can distinguish it from split_files and split_any_file without opening a schema.

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?

Gives the triggering condition ('Use when a .zip is too big to upload/attach') and an explicit exclusion with the alternative named ('For anything that is not a .zip ... use split_files'). It also warns the recipient-side requirement ('upload all of them'), which shapes how the caller should proceed.

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

Deploy Server