Pugi

Build a web app

build_app

DestructiveIdempotent

Use this when the person wants something people use: upload a photo, generate or transform pictures with AI, accounts or sign-in, saved data, a tool, a calculator, a game, bookings, a dashboard. Pass their request as they said it; never turn it into a landing page. An app that makes pictures with AI asks for the owner's own image-AI key; it never fakes results. Pass the customer's brief in the customer's own words; do not add features the customer did not ask for (no invented sign-up, accounts, subscriptions or payments). When it is built Pugi checks it for security issues, and publish waits for that check. An app that needs a server or a database moves onto Pugi's servers on its own; the person stays in this chat. In hosts that render the build card (MCP Apps or ChatGPT widget), the card tracks progress automatically: do not poll job_status. In hosts without a build card (Claude Code or API), call job_status with the job_id until the job is finished, stopped or failed. Do not use for a simple website (use build_site) or to change an app already built here (use edit).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brief": "<brief>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "build_app"
  }
}

Input Schema

Name	Required	Description
`pick`	No	Console gallery starter slug.
`brief`	Yes	The app to build, in the customer's own words.
`theme`	No	Console theme slug.
`locale`	No	Site language (legacy alias for site_language).
`logo_id`	No	Selected logo_id returned by make_logo.
`max_usd`	No	The most this build may cost in USD (default 5).
`language`	No	The language the person is writing in, as a BCP 47 tag such as "ru".
`without_logo`	No	True only when the person said this site should not use the logo they picked.
`brief_version`	No	With brief_confirmed: the version of the summary the person agreed to, as returned with that summary.
`site_language`	No	Language for the app content; independent of the chat card language.
`brandHandoffId`	No	BrandHandoff from logo.pugi.io.
`brief_confirmed`	No	True only after the person has seen the summary and agreed. In a chat, without it nothing starts and the summary comes back.
`idempotency_key`	Yes	A unique string naming this build. Reuse it only to retry the same call; it is never charged twice.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 31, 2026

changedInput schema / properties / brief_confirmed / description

Previous value: -"With logo_id: true only after the person has seen the summary from select_logo and agreed. Without it nothing starts and the summary comes back."New value: +"True only after the person has seen the summary and agreed. In a chat, without it nothing starts and the summary comes back."

changedInput schema / properties / brief_version / description

Previous value: -"With brief_confirmed: the version of the summary the person agreed to, from select_logo."New value: +"With brief_confirmed: the version of the summary the person agreed to, as returned with that summary."

Changed4 schema fields changedOct 31, 2026

addedInput schema / properties / brief_confirmed

Added value: +{
+  "description": "With logo_id: true only after the person has seen the summary from select_logo and agreed. Without it nothing starts and the summary comes back.",
+  "type": "boolean"
+}

addedInput schema / properties / brief_version

Added value: +{
+  "description": "With brief_confirmed: the version of the summary the person agreed to, from select_logo.",
+  "maxLength": 32,
+  "type": "string"
+}

addedInput schema / properties / language

Added value: +{
+  "description": "The language the person is writing in, as a BCP 47 tag such as \"ru\".",
+  "maxLength": 35,
+  "pattern": "^[a-z]{2,3}(-[A-Za-z0-9]{2,8})?$",
+  "type": "string"
+}

addedInput schema / properties / without_logo

Added value: +{
+  "description": "True only when the person said this site should not use the logo they picked.",
+  "type": "boolean"
+}

AddedOct 29, 2026
RemovedOct 28, 2026

Changed5 schema fields changedOct 27, 2026

addedInput schema / properties / brandHandoffId

Added value: +{
+  "description": "BrandHandoff from logo.pugi.io.",
+  "type": "string"
+}

addedInput schema / properties / locale

Added value: +{
+  "description": "Site language.",
+  "type": "string"
+}

addedInput schema / properties / logo_id

Added value: +{
+  "description": "Selected logo_id returned by make_logo.",
+  "type": "string"
+}

addedInput schema / properties / pick

Added value: +{
+  "description": "Console gallery starter slug.",
+  "type": "string"
+}

addedInput schema / properties / theme

Added value: +{
+  "description": "Console theme slug.",
+  "type": "string"
+}

AddedOct 26, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the async lifecycle: the build is security-checked, publish waits for that check, and server/database needs migrate to Pugi's infrastructure transparently. It also constrains feature invention (no invented sign-up/payments) and states AI-image apps require the owner's own key rather than faking results. What it omits is the cost/credit consequence of a build and what the call returns on success — the 'never charged twice' idempotency detail lives only in the schema.

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?

Front-loaded with the trigger condition and exclusion before any mechanics, which is the right order for a router-style tool. It is dense but each sentence carries an instruction; the only real waste is the near-duplicate 'Pass their request as they said it' / 'Pass the customer's brief in the customer's own words' pair.

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 13-param, asynchronous, no-output-schema tool, it covers the important unknowns: how progress is tracked per host, that a security check gates publishing, that hosting is automatic, and that builds have a USD cap. The remaining gaps — what the call returns immediately (a job_id / build card) and the credit cost — are inferable but not stated.

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 100%, so the baseline is 3, but the description adds genuine operating semantics for the two required params: the brief must be passed verbatim in the customer's words and must not be reshaped into a landing page or padded with unrequested features, and it clarifies that without brief_confirmed nothing starts and a summary comes back. It says nothing about the 13 optional presentation params (theme, pick, logo, brandHandoffId, site_language), but those are documented in the schema.

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 and resource ('build' + 'a web app') and enumerates the concrete artifact classes it covers (uploads, AI image generation, accounts, saved data, dashboards). It explicitly separates itself from build_site ('simple website') and edit ('change an app already built here'), so an agent can route without opening sibling schemas.

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?

Names both alternatives and the exact condition that selects each: build_site for a simple website, edit for modifying an existing app. It also gives host-specific instructions (don't poll in MCP Apps/ChatGPT, do poll job_status in Claude Code/API), which is real operational guidance rather than vague framing.

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

All Pugi tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?