nukez-mcp

nukez_store

Store files in your Nukez locker. ALWAYS BATCH: pass ALL the files you want to upload in a SINGLE call, as a list under files. Do NOT loop over your file list and call nukez_store once per file — that triggers one on-chain attestation per file (slow + costs SOL fees per push). One nukez_store call with N files triggers exactly ONE attestation for the whole batch. Each list item: {name, , content_type?, expected_size_bytes?, expected_sha256?, large?}. UPLOAD PATH PRIORITY: 1. source_url — if the file is available at a public HTTPS URL, pass it and the server fetches directly (fastest, zero token cost). 2. sandbox_path — if you have compute/bash access and the file is on disk, pass the absolute path. 3. local_path — if the file exists on local disk (desktop/CLI environments). 4. data_b64 — LAST RESORT for small content only (<4KB). Sends bytes through your context window. Accepts both base64-encoded binary and plain UTF-8 text. 5. nukez_upload_chunk — if sandbox_path curl failed (HTTP 000 / network blocked), upload in 4KB chunks with sha256 verification. Run the prep script from the response, then call nukez_upload_chunk for each chunk. NEVER base64-encode files >4KB in one call. Upload path is auto-selected based on size and runtime environment. HARD SIZE LIMITS per path: the sandbox curl proxies through the gateway and is capped at 32 MiB (the platform rejects larger request bodies); the chunked ingest pipeline caps at 20 MiB per file. LARGE FILES (>= 32 MiB, any size up to terabytes): pass expected_size_bytes (and ideally the file's expected_sha256) with sandbox_path, or set large=true — the response then returns a resumable direct-to-provider upload session (action_required='execute_upload') with a session-open command and a stdlib-only transfer script that uploads in 8 MiB chunks and resumes after interruptions. Bytes go straight to the storage provider, so the sandbox needs outbound access to the session URI's host. After the transfer, confirm with nukez_confirm(use_job=true). KEYLESS (hosted) SERVER: this server holds no signing key. A call without envelope returns action_required='sign_envelopes' with the exact spec to sign (method, path, ops, body); sign it with your wallet and re-call with envelope=. One file per call in envelope mode.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`files`	Yes
`envelope`	No
`receipt_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedAug 23, 2026

addedInput schema / $defs / FileItem / properties / expected_sha256

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Hex SHA-256 of the file's bytes (with or without a 'sha256:' prefix). Optional pre-commitment for the resumable path: the confirm refuses to record a stored object whose hash differs.",
+  "title": "Expected Sha256"
+}

addedInput schema / $defs / FileItem / properties / expected_size_bytes

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Declared size of the file in bytes (sandbox_path mode). At or above 32 MiB this selects the resumable direct-to-provider upload; the gateway binds it as a pre-commitment and the confirm refuses a stored object of a different size.",
+  "title": "Expected Size Bytes"
+}

addedInput schema / $defs / FileItem / properties / large

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Force the resumable direct-to-provider upload path for a sandbox_path file regardless of declared size.",
+  "title": "Large"
+}

First observedJul 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and it does so well: it discloses one attestation per batch, SOL fee implications, size caps (32 MiB sandbox curl, 20 MiB chunked ingest), base64 versus path behaviors, resumable session behavior, and the keyless signing requirement. This surfaces behavioral nuances far 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.

Conciseness4/5

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

The description is long, but nearly every sentence carries critical execution detail: cost, thresholds, fallback paths, ordering, and follow-up actions. It is structured with numbered priority and batching guidance, though some duplication (e.g., chunk and size details repeated) slightly hurts conciseness.

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?

Given the tool's complexity, rich nested schema, multiple upload modes, size limits, and no annotation, the description is unusually complete: an agent knows exactly how to invoke it, when to follow up with nukez_confirm or nukez_upload_chunk, and what to expect from the response. The output schema is available, so return values do not need to be re-spelled.

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?

Top-level schema description coverage is 0%, so the description fully compensates. It explains each FileItem field in context, defines the allowed data sources, adds priority ordering, clarifies expected_size_bytes and expected_sha256 for large files, and documents the envelope restriction. The description adds meaning that the bare parameter names would not provide.

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-resource pairing ('Store files in your Nukez locker') and immediately establishes core behavior (batch upload). It is clearly distinguishable from sibling tools like nukez_retrieve or nukez_recall, and there is no ambiguity about what nukez_store does.

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?

Provides explicit, actionable guidance: batch all files, never call once per file because of on-chain attestation cost, and follow a numbered upload path priority. It also explains when to use alternatives (nukez_upload_chunk, nukez_confirm), large-file resumable flows, and the keyless envelope signing flow. There is no guesswork left for the agent.

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

All nukez-mcp tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation3/5

Some tools have overlapping boundaries: nukez_store, nukez_create_file, and nukez_upload_chunk all handle file ingestion, while nukez_verify and nukez_recompute_verify both verify locker integrity. The descriptions do clarify when each should be used, but an agent could still mis-select between upload paths or verification levels. nukez_setup also overlaps conceptually with the quote/pay/provision workflow.

Naming Consistency4/5

All tools share the nukez_ prefix and use lowercase snake_case, which creates a strong sense of consistency. Most follow a verb or verb_noun pattern, but a few like nukez_setup, nukez_status, and nukez_recompute_verify deviate from the dominant verb_noun structure. There is no convention mixing, so the naming remains predictable.

Tool Count4/5

At 15 tools, the server is at the upper edge of a well-scoped set, and the count is largely justified by the multi-stage storage workflow: quote/pay/provision, file upload paths, memory recall, and integrity verification. Some tools are very specialized, such as nukez_confirm and nukez_upload_chunk, but they support real necessary flows. It is slightly heavy because a few could be consolidated, but not bloated for the domain.

Completeness5/5

The server covers the full storage lifecycle: setup and status, payment steps, file store/create/upload/confirm/retrieve/delete, memory remember/recall, and both structural and byte-level verification. There are redundant paths but no obvious dead ends. The workflow from first purchase through provisioning, mutating storage, and later proving integrity is well covered.

Resources

Need Help?