Skip to main content
Glama

Publish an app

publish_app
Destructive

Publish source as an app: a process Valet builds from your files and runs behind its own URL. Use it when the work needs a server, a background process, or a database. A Procfile at the root says how to start each process type; the web type serves the app's URL and must listen on $PORT, which Valet sets. Node, Python, and Go are supported. Apply the governance skill before calling.

title and description are required and a call missing either is refused: Valet writes the app's valet.yaml from them, and any valet.yaml in files is replaced. Content is text: source files, lockfiles, Procfile, configuration. Images and other binary assets are not supported on this surface. Dependencies are installed during the build from the manifest you publish: package.json, with its lockfile when you have one; requirements.txt; or go.mod, where go.sum is optional and the build completes it. Do not include installed packages.

Publishing to a name that exists replaces its source with these files, so read get_source first when the app is not yours. The publish returns a build id. Poll get_build until deploy_state is up or crashed; the first deploy can take a few minutes. A build that succeeded is not yet live: its processes still have to start on the new release. On crashed, a web process that had a running release keeps serving it, so a working URL does not prove the new release is live; other crashed processes are down until fixed. Read each crashed process's state_reason: if it is the app's own output, fix the code and publish again; if it names a platform or configuration failure, fix that or publish again. The first publish creates the app, so set environment variables and attach resources after it: set_env_vars and attach_resource each restart the app with its new variables. Write the app to start without them and serve a page saying what is missing, never exiting, and give the user the URL once its resources are attached. A new app is private: only members of the organization that owns it can open it, after signing in to Valet. Use set_service_access to make it public or password-protected. Requires connecting a Valet account.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesRequired. The app's name, which becomes the first label of its URL. Naming an app that exists republishes it.
filesYesRequired. The app's files, [{path, content}]. A Procfile at the root is required.
titleYesRequired. What the app is called, written for a person.
org_nameNoThe Valet organization to publish into. Omit to use the organization the account joined first.
descriptionYesRequired. One sentence saying what the app does.
discard_draftNoSet true to discard an open draft on this app that another session left. Omit to be told about it instead.
idempotency_keyNoAn opaque key of your choosing. Repeating a call with the same key returns the first call's result instead of starting a second build. Use a new key for new files: a repeated key returns the earlier result even when the files changed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"Required. The app's name, which becomes the last segment of its URL. Naming an app that exists republishes it."New value: +"Required. The app's name, which becomes the first label of its URL. Naming an app that exists republishes it."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (destructive, open-world, non-idempotent) only flag the risk surface; the description goes far beyond, disclosing overwrite semantics ('Publishing to a name that exists replaces its source'), the refused-call condition, binary-asset limits, build-time dependency installation, the crashed-process behavior (a running release keeps serving, so a live URL does not prove the new release is live), and default privacy.

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?

Four dense paragraphs, all front-loaded with the core definition before operational detail. Nearly every sentence carries unique operational value, though the crashed-process and environment-variable guidance could be tightened. Long but not padded.

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?

With no output schema, the description must explain returns and post-call workflow, and it does: it returns a build id, you poll get_build, and deploy_state gates liveness. It also covers account requirement, first-publish app creation, and access defaults, leaving no structural gap for a 7-parameter mutation tool.

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?

Schema coverage is already 100%, setting a baseline of 3, but the description adds real semantic weight: the Procfile must be at root, its web type must listen on $PORT which Valet sets, valet.yaml is written from title/description, dependencies come from the published manifest, and the idempotency-key caveat about changed files.

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?

States a specific verb+resource ('Publish source as an app') and immediately defines what an app is ('a process Valet builds from your files and runs behind its own URL'), which cleanly separates it from publish_site and publish_skill in the sibling list. An agent can tell the three apart without opening any schema.

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 when-to-use conditions ('when the work needs a server, a background process, or a database'), a prerequisite ('Apply the governance skill before calling'), and an ordering of alternatives ('read get_source first when the app is not yours', then set_env_vars/attach_resource/set_service_access after). It even routes the agent to get_build for status.

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.

Resources