agent-ready-kit

Get Customer Files (ZIP, base64)

get_customer_files

Read-onlyIdempotent

Use this when an agent needs to hand a downloadable ZIP to its end user. PAYWALL: without a valid bundle_key, the ZIP contains only the two free starter files plus a teaser README pointing to /talk. With a valid bundle_key, the ZIP contains the full surface plus the deploy README. ZIP is base64-encoded in the response — agents decode and offer as a download.

Input Schema

TableJSON Schema

Name	Required	Description
`phone`	No
`domain`	Yes	Domain only, no protocol
`category`	No
`delivery`	No	Paid only. Which delivery artifact to package: 'files' = drop-in web-root files (default, any host); 'cloudflare' = a Cloudflare edge Worker (domain on Cloudflare → Level 5, zero origin files); 'wordpress' = a self-contained WordPress plugin.
`siteName`	No
`bundle_key`	No	Customer bundle key issued after payment. Without it, only the 2 free starter files are packaged.
`description`	No
`primaryToolName`	No
`primaryToolDescription`	No

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No	Full base64-encoded ZIP. Present only when transferEncoding=inline (payload <= 8KB).
`tier`	No
`bytes`	No
`chunks`	No	Array of base64 fragments. Present only when transferEncoding=chunked (payload > 8KB). Concatenate in order to reconstruct the full base64 ZIP.
`status`	Yes
`message`	No
`encoding`	No
`filename`	No
`fileCount`	No
`paid_path`	No
`contentType`	No
`totalChunks`	No	Length of chunks[] for client validation. Present when transferEncoding=chunked.
`humanFollowupUrl`	No	URL a calling agent can show its user for the human-rendered version of this tool's output.
`transferEncoding`	No	If 'inline', data field holds the full base64 ZIP. If 'chunked', read chunks[] and concatenate in order.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context beyond this: the paywall logic (free vs. full files based on bundle_key) and the base64 encoding of the ZIP, which is crucial for the agent to decode and present to the user.

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?

The description is four sentences, each providing critical information: use case, paywall behavior, and encoding. There is no redundancy or wasted words. It is front-loaded with the primary use case, making it easy to scan.

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?

The output schema exists, so return values are documented elsewhere. The description covers the core purpose, the paywall distinction, and the encoding requirement. It does not explain the optional parameters' effects, but given the output schema and the simplicity of the core behavior, the description is sufficiently complete for the agent to use the tool correctly.

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

Parameters2/5

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

Schema coverage is only 33% (domain, delivery, bundle_key have descriptions). The description only elaborates on bundle_key (explaining the paywall effect) but leaves the six undocumented parameters (phone, category, siteName, description, primaryToolName, primaryToolDescription) unexplained. With low schema coverage, the description should compensate, but it does not.

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 clearly states the tool's purpose: 'Use this when an agent needs to hand a downloadable ZIP to its end user.' It specifies the resource (customer files) and output format (ZIP, base64), and distinguishes itself from siblings by emphasizing the PAYWALL and bundle_key mechanism, which is unique to this tool.

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?

The description explicitly provides a when-to-use scenario ('when an agent needs to hand a downloadable ZIP to its end user') and clarifies the impact of having or lacking a bundle_key. It does not explicitly name alternative tools or exclusions, but the context is clear enough for an agent to decide.

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

All agent-ready-kit 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

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, with descriptions that prevent confusion. Tools like scan_site and run_site_audit are differentiated by their focus on AI-readiness vs. site quality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, with clear action words like 'scan', 'create', 'get', 'verify'. Even longer names like 'summarize_scan_for_humans' maintain consistency.

Tool Count4/5

22 tools is slightly above the ideal range but justified by the comprehensive scope of the server, covering scanning, analysis, quoting, file delivery, and verification. Some tools like generate_files and get_customer_files could overlap but serve different contexts.

Completeness5/5

The tool surface covers the entire workflow from site scanning to deployment verification, with no obvious dead ends. All necessary operations for making a site agent-ready are present, including edge cases like x402 validation and credential verification.

Get Customer Files (ZIP, base64)

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources