Skip to main content
Glama

Just Publish

by ai.justpublish

deploy

Put a website live at a public URL. Use this when the user wants to publish, launch, or get a page online — e.g. 'I need a website', 'put up a page for my business', 'make this live'. Takes static files (HTML, CSS, JS, images) and returns a working URL anyone can open. No build step, no config. First call: omit site_id and edit_token — you get back a url, a site_id, and an edit_token. Keep the edit_token; it's the only way to change this site later. Later calls: pass site_id + edit_token to publish over the same site. deploy REPLACES the whole site — any file you leave out is DELETED. To change just one or a few files, use update_site_file instead. To see what's currently live before editing, use get_site_files first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailYesEmail to associate with the site. Captured unverified at first deploy; verification only required later for custom domains and recovery.
filesYesFiles to publish. Must include an index.html at the root.
site_idNoExisting site id to update. Omit to create a new site.
edit_tokenNoEdit token returned at create time. Required to update.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe live URL of the published site.
createdYestrue if this call created a new site; false if it updated an existing one.
site_idYesThe site's slug / id — pass back to update it later.
edit_tokenNoReturned ONLY on first create. Save it — it's the only way to update this site.
total_bytesYesTotal size of the site in bytes after this deploy.
email_maskedYesThe owner email, masked for display (e.g. 'a***@example.com').
dashboard_urlYesDeep link to this site in the owner's dashboard.
email_verifiedYesWhether the site's owner email is verified right now. New sites are always false.
files_uploadedYesNumber of files written in this deploy.
verify_requiredYestrue when the owner still needs to verify their email (keys on !email_verified).

TDQS

A4.6/5.0
Behavior4/5

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

Annotations set destructiveHint=false and readOnlyHint=false. The description adds critical behavioral context: 'deploy REPLACES the whole site — any file you leave out is DELETED.' It also explains the edit_token's role as the only way to update later. This goes beyond the annotations to inform the agent about the tool's behavior, though the annotations already provide a basic safety profile.

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 well-structured: purpose first, then usage scenarios, then detailed instructions for first/later calls, a warning about replacement, and finally alternatives. Each sentence adds value without redundancy. It is front-loaded with the primary action.

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 description covers the return values (url, site_id, edit_token) and notes the requirement for index.html. It also explains the replacement behavior. However, it could briefly mention what happens to the site during update (e.g., immediate effect) or error cases, but given the presence of an output schema, it is largely complete.

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?

The input schema has 100% description coverage. The description adds meaningful context beyond the schema: first call omit site_id and edit_token, later calls require them; keep edit_token for future changes. This helps the agent understand the lifecycle of parameters.

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: 'Put a website live at a public URL.' It specifies the verb 'put live', resource 'website', and provides concrete examples of user intents like 'I need a website'. It also distinguishes from siblings by mentioning get_site_files and update_site_file for viewing and partial updates.

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?

The description explicitly says when to use the tool (publishing, launching) and when not to (for changing a few files, use update_site_file; to see current live content, use get_site_files). It also explains the first call vs later call pattern, providing clear context 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 Just Publish toolsInspect
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.5/5.0
Disambiguation5/5

Each tool has a distinct purpose: deploy for full replacement/publishing, get_site_files for reading current state, and update_site_file for partial edits. No overlap or confusion between them.

Naming Consistency4/5

Two tools follow verb_noun pattern (get_site_files, update_site_file), while deploy is a single verb. This is a minor inconsistency, but the naming is clear and readable overall.

Tool Count4/5

Three tools is slightly small but appropriate for the specific domain of static site deployment. Each tool serves a necessary function, and the number doesn't feel inadequate.

Completeness3/5

Core operations (create/replace, read, and partial update) are covered, but there is no way to delete individual files or list multiple sites. This leaves a notable gap in the tool surface.

Resources