Skip to main content
Glama

Opus Growth, Ad Platforms MCP Connector

Deploy Site From ZIP

deploy_site_zip
Destructive

Deploy an ENTIRE website from a .zip onto the user's AI Server in one step. Give the zip as zip_base64 (a file the user dropped into chat — base64-encode it; only practical up to a few MB) OR zip_url (a public link, fetched SERVER-SIDE with no chat cost — the way to do LARGE files up to 300 MB). zip_url accepts a Google Drive or Dropbox SHARE link directly (the file must be shared 'anyone with the link'); it is auto-converted to a direct download and Drive's large-file confirmation is handled — so the user just uploads to Drive and pastes the link. It uploads the zip to the user's own isolated server, unzips it and PUBLISHES it live at /data/site over HTTPS.

If the zip is ALREADY a static site (index.html at the root) it is published as-is — instant, no build. If it is a source project it is BUILT on the server and the static output is published: Next.js → STATIC EXPORT (output:'export' is injected automatically) from out/; Vite → dist/; Create-React-App → build/. Sites are served statically: NO Node/SSR process runs at runtime, so Next.js features that REQUIRE a live server are NOT supported (getServerSideProps/SSR, API routes /api/*, ISR/revalidate, middleware, Server Actions, next/image default optimization). If the project needs those, the static build fails and this returns a clear explanation; the fix is to make the app statically exportable or use a runtime host. Everything under /data/site is REPLACED (a version snapshot is taken first, so site_restore can undo it). Build cap ~10 min, zip ≤ 300 MB (for anything above a few MB use zip_url — a 300 MB base64 will not fit the chat context).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNo
serverNo
zip_urlNo
zip_base64No

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. Added
  6. Removed
  7. Added
  8. Removed
  9. Added
  10. Removed
  11. Added
  12. Removed
  13. Added
  14. Removed
  15. Added
  16. Removed
  17. Added
  18. Removed
  19. Added
  20. Removed
  21. Added
  22. Removed
  23. Added
  24. Removed
  25. Added
  26. Removed
  27. Added
  28. Removed
  29. Added
  30. Removed
  31. Added
  32. Removed
  33. Added
  34. Removed
  35. Added
  36. Removed
  37. Added
  38. Removed
  39. Added

TDQS

A4.3/5.0
Behavior4/5

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

Far beyond the annotations: it discloses that /data/site is fully REPLACED with a version snapshot taken first (matching destructiveHint=true), that site_restore can undo it, the ~10 min build cap, the 300 MB limit, the server-side fetch behavior, and the Google Drive/Dropbox share-link auto-conversion. It does not state required permissions or where the success/failure result surfaces, so not a 5.

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 paragraph is long but front-loaded with the core action, then the input-mode tradeoff, then build behavior and constraints. Nearly every sentence adds decision-relevant information; the unsupported-Next.js-feature list is lengthy but justified given the failure mode it prevents.

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?

For a destructive deploy tool with an output schema (so return values need no explanation), it covers inputs, side effects, rollback, size/time limits, and build semantics. The remaining gap is the undefined `site` and `server` parameters, which an agent cannot infer.

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 coverage is 0%, so the description must carry all parameter meaning. It explains zip_url and zip_base64 in depth (formats, size limits, share-link conversion), but never mentions the `site` or `server` parameters at all, leaving half the inputs ambiguous.

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 first sentence names a specific verb and resource ('Deploy an ENTIRE website from a .zip onto the user's AI Server in one step') with a clear scope marker ('ENTIRE'). It is easily distinguished from the many site siblings (add_site, create_trial_site, scaffold_site, site_rebuild) by its ZIP-in, publish-to-/data/site flow.

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 explicit selection criteria between the two input modes: zip_base64 for small chat-dropped files, zip_url for large files up to 300 MB because it is fetched server-side. It also states when the tool is NOT appropriate (projects needing SSR/API routes/ISR) and what the fix is.

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.