Kleap

Publish Website

publish_app

Destructive

Use this to take a website LIVE at its public URL. Publishing is VERIFIED-LIVE: the app is only reported published once the new version is provably serving — otherwise it reports 'not confirmed live', never a false 'it is online'. Publishing also AUDITS the built site: every internal link on every page (menu entries to a page never written are the #1 case), pages whose content contradicts the link leading to them, and JSON-LD/sitemap/robots coverage. Most deploys land in under a minute, so this call WAITS a bounded time and returns that report here when it does — read it before calling the launch a success, and if it lists findings, FIX THEM (write the missing page, or remove the dead link) before you answer, as you would a build error. On a slower deploy it returns 'publishing' with no report; then do not poll get_publish_status in a loop inside one turn — check once when the user asks again.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`app_id`	Yes	The app ID to publish
`context`	Yes	Why this call, in one short sentence. Used to improve the connector; never include credentials or personal data.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`app_id`	No
`report`	No
`status`	No
`poll_url`	No
`deploy_key`	No
`production_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 23, 2026
- addedOutput schema / properties / production_url
```
Added value: +{}
```
- addedOutput schema / properties / report
```
Added value: +{}
```
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 already signal mutation and destructiveness, but the description adds substantial non-obvious behavior: verified-live confirmation, no false-positive reporting, built-site auditing, bounded waiting, and the slow-deploy fallback. This goes far beyond the structured annotations and prevents agent misjudgment.

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?

The description is long but densely packed with operational instructions that earn their place. It is front-loaded with the primary purpose and then structured around critical behaviors. Slightly verbose, but the length is justified by the high-stakes, multi-step behavior it must communicate.

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?

For a publish action with an output schema, the description fully covers what the agent needs: the verified-live guarantee, audit findings, bounded wait, slow-deploy behavior, and follow-up actions. Business-specific rules like fixing broken links are included, leaving no major operational gap.

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% and both parameters are already self-explanatory in the schema. The description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.

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 opens with a specific verb-resource pair: 'take a website LIVE at its public URL.' It clearly distinguishes this tool from its sibling get_publish_status by describing the end-to-end publish action versus a status check.

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 explicitly says when to use the tool (to go live), what to do after calling it (read the returned report and fix findings), and how to handle slower deploys without abusing get_publish_status. The instruction 'do not poll get_publish_status in a loop' gives concrete negative guidance.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?