nukez-mcp

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

No annotations are supplied, so the description carries the full burden. It discloses the server-side SHA-256 hash computation, the need for a payer-signed locker:write envelope, the two-phase keyless envelope spec flow, the request-path streaming for synchronous confirms of large objects, and the async finalize job with terminal statuses (complete, partial, failed).

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

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

The description is dense and front-loaded with the core action, and split into understandable chunks (normal flow, large files, keyless vs signer mode). It could be more readable, and the embedded strings are a bit noisy, but every clause earns its place and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complex multi-path behavior (keyless sign-verify flow, large-file jobs, payment envelope requirement) is fully covered in the description; the output schema exists and would document return values, so no gap there. An agent working without annotations still knows the full call sequence, required envelope semantics, and what terminal statuses to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description fully explains envelope and use_job and provides the job_id and receipt_id context. It explains that the batch spec returned by nukez_store is also accepted in envelope, that two args are actually mutually required in practice, and describes the job lifecycle. This compensates completely for the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('Confirm a file upload'), and orients the agent by referencing the specific prior step ('after executing the curl command returned by nukez_store in sandbox mode'). It also distinguishes itself from the broader upload flow by highlighting the SHA-256 hashing and the large-file async path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to call this tool and how: after the sandbox curl, with a payer-signed locker:write envelope, covering both signer-mode and keyless clients. It also spells out the large-file alternative (use_job=true, resumable upload) and the keyless signing/polling loop until terminal job status, effectively routing around sibling tools like nukez_store and nukez_upload_chunk.

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

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

With no annotations, the description carries the full disclosure burden and does so thoroughly. It explains the keyless signing flow, that calls without an envelope return action_required='sign_envelopes', how to sign and re-call, the 307-redirect to GCS, that bytes never transit the MCP server, and that one file per call is allowed in envelope mode.

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

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

The description is longer than a trivial tool description, but the added length is justified by the non-obvious direct-upload and signing flows. It is front-loaded with the core result and every sentence adds a distinct decision or behavioral fact rather than repeating schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully accounts for the important runtime context: upload URL generation, finalization via nukez_confirm, byte passthrough, large-vs-small file routing, and keyless authentication. Since an output schema exists and no annotations are present, this is a complete description for correctly selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description gives strong semantics for envelope, including the exact signed spec and the re-call requirement, which goes meaningfully beyond the schema. However, it does not explicitly explain content_type or receipt_id, and the schema itself provides no descriptions, so the description only partially compensates for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: create a file entry and receive upload_url + confirm_url for direct upload. It clearly distinguishes this tool from nukez_confirm and nukez_store by defining its role in the upload flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this for large files from local/external sources against Cloud Run and gives a concrete alternative: use nukez_store with data_b64 for small inline content under 4KB. It also describes the expected client-side follow-up steps: PUT bytes to upload_url, then call nukez_confirm.

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

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

With no annotations to describe safety or behavior, the description carries the full burden and does it well. It explicitly warns that deletion is permanent and irreversible, states that existing attestation is invalidated, and explains the keyless server's returned action_required flow. These are the critical behavioral details an agent needs before invoking a destructive tool.

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

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

The description is dense but every sentence earns its place: the main operation, the destructive warning, the attestation invalidation, and the separate envelope-mode workflow are all packed into a compact block with important caveats front-loaded. There is no filler or repeated schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no annotations, the description covers the main protocol sufficiently: how deletion works, the two call modes, and how to proceed after signing. The main gap is the receipt_id parameter, which is left entirely unexplained. Output schema presence lowers the need to describe return values, so overall the description is complete enough for normal invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the text must carry meaning normally provided by parameter docs. It does add meaningful semantics for filenames and envelope, including the constraint 'one file per call in envelope mode' and the requirement to pass the signed result through envelope. However, receipt_id is never explained, leaving one parameter completely underrepresented in both the schema and the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Delete files from your Nukez locker'), making the tool's purpose immediately clear. The warning about permanence and attestation invalidation further differentiates it from sibling storage/verification tools. No other sibling tool covers deletion, so confusion is unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly tells an agent when to use the tool (to delete files) and walks through the keyless hosted-server workflow: call without an envelope, receive a signable spec, sign it, then re-call with the envelope. It does not explicitly list exclusions or alternative tools, but the context is clear and actionable.

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

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

With no annotations, the description fully discloses behaviors: the server is keyless, pre-flight checks for Solana SPL, error handling with structured WRONG_DESTINATION error, indeterminate fall-through, and that the quote remains valid on failure. This is comprehensive and goes beyond basic expectations.

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

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

The description is a single dense paragraph containing all necessary information without redundancy. Every sentence adds value, but it could be more structured (e.g., bullet points) for easier parsing. It is appropriately sized for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (payment recording with pre-flight checks, error handling), no annotations, and 0% schema coverage, the description covers purpose, usage, parameters, and behaviors thoroughly. An output schema exists, so return value details are not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage, so the description must add meaning. It explains all four parameters: tx_sig (pass the signature), pay_req_id (auto-resolved from state), chain and pay_asset (identify the rail with examples, defaults to quote's choice). It does not explicitly map to property names but context is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Record an externally-executed on-chain payment' with a specific verb ('record') and resource ('on-chain payment'). It also positions itself as 'Step 2' in a sequence, distinguishing it from sibling tools like nukez_quote and nukez_confirm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: after executing a transfer yourself, pass the signature. It mentions auto-resolution from nukez_quote and defaults. However, it does not explicitly mention when not to use this tool or compare it to alternatives like nukez_verify.

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

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

No annotations provided, so description carries full burden. It discloses two modes, returns receipt_id and hint, and mentions rehydration without re-paying. However, it lacks details on side effects, permissions, and error conditions.

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

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

Two sentences with compact information, conveying both modes and parameter usage. Slightly long second sentence but no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity (6 params, two modes, output schema exists), the description covers main use cases and return values. Lacks error scenarios but sufficient for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. The description explains 4 of 6 parameters (pay_req_id, tx_sig, envelope, receipt_id) with context, but omits chain and pay_asset. Adds significant meaning but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for confirming payment and provisioning a storage locker, describing two modes of operation. It is specific about the action but does not explicitly differentiate from sibling tools like nukez_setup or nukez_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides good usage guidance by explaining two modes with parameter combinations. It tells when to use each mode but does not explicitly state when not to use or contrast with alternatives.

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

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

With no annotations, the description provides extensive behavioral context: it returns a price breakdown and payment methods with detailed instructions on destination_kind and spl_transfer blocks. It does not explicitly state read-only status, but the quoting nature implies no side effects. The level of detail is high.

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

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

The description is longer but front-loaded with the main purpose. It includes step-by-step instructions and technical details. Some redundancy exists (e.g., listing payment methods twice), but every sentence contributes to understanding the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters and a complex output (payment options with nested blocks), the description covers providers, destination handling, and workflow connection to nukez_pay. It does not detail the 'units' parameter or the exact format of the price breakdown, but an output schema exists to fill that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It mentions defaults and providers for the 'provider' parameter, lists pay_asset and pay_network as nullable with defaults, but does not explain 'units' or the semantics of pay_asset/pay_network in depth. The description adds value beyond bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is 'Step 1' for getting storage pricing and payment options, explicitly distinguishing it from sibling tools like nukez_pay (step 2). It describes the output as 'price breakdown and every available payment method' with specific asset lists.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description positions the tool as the first step in a workflow, instructing users to 'pick one, then sign+submit externally and call nukez_pay'. It lists providers but does not explicitly state when not to use the tool or compare with alternatives. The context is clear for a sequential workflow.

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

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

Without annotations, the description should disclose behavioral traits like read-only safety, but it does not state that the tool is non-destructive or any authentication requirements. It implies a read operation but with no explicit safety declaration.

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

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

The description is brief and front-loaded with the main purpose. The note about envelope is separate but not excessive. Every sentence serves a purpose, though the clarity of the second sentence could be improved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 optional parameters, no annotations, and a complex operation, the description lacks completeness. It omits details about the limit parameter, the optional nature of receipt_id, and any prerequisite or output structure hints despite the presence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain all 8 parameters. It covers key, namespace, tags, query, prefix, envelope, and receipt_id, but misses the limit parameter entirely, and the explanation of receipt_id is contradictory. Envelope is mentioned only to say it's not needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for searching and retrieving memory records, with two modes and return types. However, it doesn't differentiate from the sibling tool nukez_retrieve, leaving potential ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description outlines two modes but offers no guidance on when to use this tool vs alternatives. The statement 'Just pass receipt_id' is misleading because receipt_id is optional in the schema.

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

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

With no annotations, the description fully discloses behavior: it re-downloads every file, scales with total locker bytes, returns match=True/False, and requires payer authorization via signed envelopes. It also details the action_required='sign_envelopes' response for keyless deployments, going well beyond a simple read-only label.

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

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

The description is dense but efficiently organized: the first sentence defines the core operation, the second covers cost and comparison, and the third handles authorization. Every sentence adds essential context without unnecessary filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with no annotations, the description covers purpose, usage conditions, cost, authorization flow, and key return outcomes. It leverages the output schema for detailed return structure while mentioning the critical match=True/False cases. The only minor omission is receipt_id semantics, but overall it is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains the envelope parameter thoroughly, especially in the keyless deployment flow ('re-call with envelope=<signed result>'), but does not explain receipt_id. With two parameters and one unexplored, the description leaves a notable semantic gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function as a byte-level integrity proof: it re-downloads files, recomputes hashes, rebuilds the Merkle tree, and compares against the persisted attestation. It also explicitly distinguishes itself from nukez_verify by noting it is slower and for different use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Slower than nukez_verify — reach for this only on audits, post-migration sanity checks, or when you suspect drift' and 'For routine integrity checks, nukez_verify is the right tool.' It also explains the authorization flow for signer-mode vs keyless deployments, which directly informs when each approach is relevant.

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

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

No annotations are present, so the description carries the full burden. It discloses that memories are indexed for search and requires two envelopes, but omits critical details: idempotency, overwrite behavior on duplicate key, error conditions, auth requirements, and what 'locker:write' implies. This is a significant gap for a mutation tool.

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

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

The description is reasonably concise but could be more structured. It front-loads the main purpose but includes envelope details in a dense block. At 4 sentences, it is efficient but could be improved with clear bullet points for param explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 0% schema coverage, and an output schema, the description is incomplete. It does not explain return values (a receipt? status?), nor does it cover all parameters. For a tool of this complexity, the description falls short of providing a complete picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains key, content, summary, and namespace, but fails to describe tags, receipt_id, supersedes, and the envelope parameter structure (despite mentioning envelopes in the description, the parameter type is not clarified). Several parameters are left undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'Store a structured memory record in your Nukez locker' and mentions indexing for recall, distinguishing it from siblings like nukez_recall. The verb 'store' combined with the resource 'memory record' provides clear purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Some guidance is provided: namespaces for organization, required parameters, and envelope construction. However, it lacks explicit when-to-use vs alternatives like nukez_store, and does not mention scenarios where this tool should be avoided.

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

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

There are no annotations, so the description bears the full burden of behavioral disclosure. It clearly reveals the keyless authentication flow, the action_required='sign_envelopes' response, and the required permission scopes. It does not describe failure conditions, but the critical authorization behavior is transparent.

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

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

The description is compact and every sentence carries useful information: the core operation, the no-arg list mode, filename mode, and the keyless envelope handshake. The behavior is front-loaded and the details are structured clearly without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the normal list and download workflows well, including keyless specifics and the envelope re-call pattern. However, receipt_id and encoding are never mentioned, and since all parameters are optional with no schema descriptions, an agent may not know when or why to use those parameters. This is effective but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for all parameter meaning. It usefully explains filenames and envelope, but it never explains receipt_id or encoding. Because two of the four parameters remain semantically unexplained, parameter coverage is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the operation ('list files or download content') and the resource ('your Nukez locker'), and it distinguishes list mode from download mode. It does not explicitly differentiate from sibling tools like nukez_recall, so it falls just short of full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit usage conditions: call with no filenames to list, call with filenames to download, and for keyless servers, call first without envelope then re-call with signed envelope. It does not discuss when to prefer an alternative sibling tool, but the primary usage guidance is concrete and actionable.

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

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

No annotations are provided, so the description must fully disclose behavior. It reveals the multi-step process (wallet check, purchase, provisioning) and lists providers and payment chains. However, it omits details on error handling, destructiveness, idempotency, or cost implications, which would help the agent assess risk.

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

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

The description is concise at four sentences, front-loaded with the core purpose, then usage modes, then configuration details. Every sentence adds value without repetition or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multi-step setup, multiple providers, payment chains, two modes), the description covers essential aspects adequately. The presence of an output schema reduces the need to detail return values, but mentioning the output type (e.g., receipt_id) would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains 'provider' by listing options and 'receipt_id' by describing its role in rehydration. However, 'units' and 'envelope' are not explained beyond their names, leaving their purpose ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Set up Nukez storage' with a specific verb and resource, and distinguishes it from sibling tools like nukez_provision and nukez_pay by combining wallet check, purchase, and provisioning in a single call. It also explains two distinct usage modes: no-args full flow and receipt_id rehydration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool ('Call with no args' or 'Call with receipt_id'), and lists supported providers and payment chains, aiding decision-making. However, it does not explicitly state when not to use it or compare to alternatives like nukez_provision for partial setup.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It states it works at any stage but does not explicitly say it is read-only, lacks side effects, or mention authentication requirements or rate limits. The minimal behavioral information is insufficient.

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

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

The description is extremely concise: two sentences, each adding essential information without redundancy. Front-loaded with the core action, it wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and a simple parameter set, the description omits any explanation of parameters. It does not guide the agent on how to use envelope or receipt_id, leaving ambiguity. The tool's purpose is clear, but parameter usage is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no explanation for the two parameters (envelope, receipt_id). Schema coverage is 0%, so the description must compensate, but it offers no guidance on their purpose or when to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and specifies the resources: wallet balance, locker state, and lifecycle stage. It distinguishes itself from sibling tools like nukez_confirm or nukez_provision by indicating it is a read-only status check that works at any stage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that it 'Works at any stage — no active locker required,' providing clear context for when to use the tool. However, it does not mention specific alternatives or when not to use it, though the sibling list implies other tools for other actions.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries full burden and reveals substantial behavior: cheap sub-second reads, push=True triggers a fresh on-chain attestation via Cloud Tasks with server-side polling and a 202 fallback after 90 seconds. It also discloses the gateway's auto-reattest behavior, making the tool's semantics transparent.

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

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

The description is front-loaded with the core purpose and uses detailed prose for push behavior. While longer than necessary, every sentence provides useful context; slight redundancy in the auto-reattest explanation could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the primary purpose, return values, performance profile, push behavior, and alternatives, which is strong for a tool with no annotations. However, the unexplained optional parameters and reliance on the output schema for full return structure prevent a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains memory_key and push semantics, but envelope, filename, and receipt_id remain unexplained beyond their names, leaving a gap for three of five parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Fast structural verification of locker state,' giving a specific verb and resource. It clearly states the return value includes merkle root and attestation status, and explicitly differentiates from nukez_recompute_verify for byte-level proofs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance: warns against repeated push calls after every store/delete, explains when push=True is appropriate, and directs users to nukez_recompute_verify for byte-level proof. This directly addresses alternatives.

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