deploy_appDeploy a completed PromptUI build to a live URL. The first deploy of each app is charged; redeploying that same app is free.
| Name | Required | Description | Default |
|---|---|---|---|
| buildId | Yes | The buildId of a completed build | |
| _confirmed | No | Set to true only after the user has explicitly approved this exact write or credit-spending action. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / _confirmedAdded value: +{
+ "default": false,
+ "description": "Set to true only after the user has explicitly approved this exact write or credit-spending action.",
+ "type": "boolean"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include idempotentHint=true, which the description reinforces by stating redeploys are free—adding cost context beyond the structured hints. The description also discloses the paid action ('first deploy charged') which is critical behavioral information. A slight lack: it doesn't describe what happens to the previous deployment or whether the tool waits for success, but the 'charged' disclosure is valuable.
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, both informative and front-loaded with the core action. The cost note is relevant context and earns its place. Slightly more could be said about the 'confirmed' parameter, but the description remains tight and focused.
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?
With a simple 2-parameter schema, no output schema, and annotations already carrying safety hints, the description covers the key behavior: deploy, cost, and idempotency. It's missing guidance on what constitutes 'completed' (e.g., build status check) and any note on expected response or failure modes, but for a simple deployment tool the essentials are present.
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 100%, so the schema already documents both parameters. The description does not add extra meaning beyond the schema's 'completed build' context, but the base rate is 3 because the schema handles it. The description's phrase 'completed PromptUI build' clarifies that buildId must reference a finished build, which is a small addition.
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 specific action—deploying a completed PromptUI build to a live URL—with enough clarity to identify the tool's primary function. It distinguishes itself from build_app (which builds) and gtm_publish_content (which publishes content) through the explicit 'completed PromptUI build' and 'live URL' phrasing, though it doesn't name siblings directly.
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 implies usage context: it must be a completed build, and the first deploy is charged while redeploys are free. This gives an implicit condition for when to use the tool (after a build completes) and hints at cost considerations, but it doesn't explicitly state alternatives or when not to use it beyond the implicit 'completed build'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct action/resource: build lifecycle (build/deploy/status/list), GTM content workflow (generate/list/publish/analytics), and utility helpers (echo/shadcn_ui/web_scout) are clearly separated. Even closely related tools like get_build_status and list_builds differ in specificity.
Most tools follow a snake_case verb_noun pattern like build_app, deploy_app, and gtm_publish_content. Echo, shadcn_ui, and web_scout break the pattern but remain recognizable and do not create confusion.
11 tools cover the build workflow, GTM workflow, and a few support utilities without redundancy or bloat. The count is well within the ideal range and each tool earns its place.
The main build and GTM workflows are represented, but there is no tool to respond when get_build_status returns needs_clarification, leaving a potential dead end. Content editing/deletion and build deletion are also absent, though this may be acceptable if drafts and builds are treated as immutable.