Kleap

Create Website

create_app

Use this when the user wants a complete, hosted website or web app built from a text description (e.g. 'build me a website for X'). Kleap's AI builds AND auto-deploys the whole site; this takes a few minutes (typically 5 to 15 min). Returns a build_url instantly so the user can watch it build live. In a widget client (ChatGPT Apps) the preview above shows real-time progress and reveals the final live URL by itself, so you do NOT need to block or keep polling check_task. With NO widget (CLI, script, scheduled or one-shot run) nobody sees that preview and the site does not exist yet: call check_task with the returned task_id about every 30 seconds and stop only on completed (deployment_status deployed) or failed, then get_app for the live URL. Prefer this over write_files for full-site creation.

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": {
      "prompt": "<prompt>",
      "context": "<context>"
    },
    "name": "create_app"
  }
}

Input Schema

Name	Required	Description	Default
`prompt`	Yes	Detailed description of the website to build
`context`	Yes	Why this call, in one short sentence. Used to improve the connector; never include credentials or personal data.
`visibility`	No	Controls discovery listing: public = discoverable, personal = unlisted. Both may be deployed to a publicly reachable URL; personal does not add access control.	personal

Output Schema

Name	Required	Description	Default
`name`	No
`app_id`	No
`status`	No
`task_id`	No
`build_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only tell the agent this is a non-read-only, non-destructive, open-world operation. The description adds genuine behavioral context beyond that: build latency (5-15 min), that a build_url is returned instantly, that the site does not exist until the build finishes in non-widget contexts, the polling interval, and the terminal states to watch for.

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?

It is long, but the length is justified by a genuinely multi-path workflow, and the trigger condition is front-loaded before the widget/no-widget branches. A few sentences are dense run-ons ('In a widget client... do NOT need to block or keep polling'), but almost every clause carries actionable information.

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?

An output schema exists so return values need not be detailed, yet the description still names the key return artifact (build_url/task_id) exactly where the agent needs it. Combined with the polling workflow and the sibling preference, nothing required to call this correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description reinforces that 'prompt' is a detailed text description of the site but says nothing about 'context' or the visibility enum that the schema does not already cover, so it adds little beyond structured fields.

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 states the specific verb+resource ('build a complete, hosted website or web app from a text description') and gives a concrete triggering utterance. It explicitly distinguishes itself from the nearest sibling by adding 'Prefer this over write_files for full-site creation.' An agent can identify the tool without opening the 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?

It splits the decision by client type: with a widget preview, polling is unnecessary; without a widget (CLI, script, scheduled run), the agent must poll check_task every ~30s with defined stop conditions (completed/deployed or failed) and then call get_app. The alternative (write_files) is named with the condition that selects this tool instead.

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

All Kleap 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?