Skip to main content
Glama

nukez_upload_chunk

Upload a file in chunks when sandbox curl/network is blocked. PREPARATION — run this bash script first to split and hash: python3 -c " import base64, hashlib, os, json, math path = '' CHUNK = 4096 size = os.path.getsize(path) n = math.ceil(size / CHUNK) os.makedirs('/tmp/nkz', exist_ok=True) hashes = [] with open(path, 'rb') as f: for i in range(n): raw = f.read(CHUNK) h = hashlib.sha256(raw).hexdigest() b = base64.b64encode(raw).decode() open(f'/tmp/nkz/{i:04d}.b64','w').write(b) open(f'/tmp/nkz/{i:04d}.sha','w').write(h) hashes.append(h) print(json.dumps({'chunks':n,'bytes':size,'hashes':hashes})) " Then for each chunk: read the .b64 file, read the .sha file, and call this tool: cat /tmp/nkz/0000.b64 → data_b64 cat /tmp/nkz/0000.sha → sha256 nukez_upload_chunk(filename=..., data_b64=..., sha256=..., part_no=0) Set is_last=True on the final chunk. Server verifies sha256 — hash mismatch means token corruption, retry by re-reading. Always use 4KB chunks (CHUNK=4096). Do not use larger chunks. STATELESS RELAY: part_no=0 returns job_id and file_id. Pass both back on every subsequent chunk (required when each chunk is a separate MCP session).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idNo
sha256No
file_idNo
is_lastNo
part_noYes
data_b64Yes
filenameYes
receipt_idNo
content_typeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Discloses stateless relay, SHA256 verification, hash mismatch handling, and the return of job_id/file_id from first chunk. No annotations exist, so description carries full burden; covers critical behavior but lacks error recovery details.

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?

Well-structured with a purpose statement, code block for preparation, and bullet points for chunk upload steps. Slightly verbose due to embedded script, but necessary for completeness.

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 full chunk upload workflow, error handling (hash mismatch), and stateless relay requirements. Output schema exists for return values. Minor gaps: does not explain optional parameters like receipt_id.

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 coverage, description explains 6 of 9 parameters (data_b64, sha256, part_no, is_last, job_id, file_id) and their roles in the workflow. Remaining parameters (filename, receipt_id, content_type) are less explained but filename is self-explanatory.

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?

Clearly states it uploads files in chunks when sandbox curl/network is blocked, with a specific procedure. Distinguishes itself from sibling tools by its unique chunked upload functionality.

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?

Provides explicit when to use (network blocked) and detailed step-by-step instructions including a bash preparation script. Lacks explicit mention of when not to use or alternatives, but the context is strong.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources