Skip to main content
Glama

manus_website_publish

Deploy a website checkpoint to production asynchronously. Use with status polling to confirm publish completion or failure.

Instructions

Deploy the latest checkpoint of a website. Async — poll manus_website_status until publish_status becomes 'published' or 'failed', or use manus_website_publish_and_wait for an all-in-one call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idNo
website_idNo
visibilityNo

Implementation Reference

  • Handler function for the 'manus_website_publish' tool. It takes a WebsitePublishRequest (containing optional task_id, website_id, and visibility), calls POST /v2/website.publish via ctx.client.call, and returns a WebsitePublishResponse. This is an async operation — the tool description advises polling with manus_website_status or using the composite manus_website_publish_and_wait.
    @manus_tool(
        name="manus_website_publish",
        description=(
            "Deploy the latest checkpoint of a website. Async — poll manus_website_status until "
            "publish_status becomes 'published' or 'failed', or use manus_website_publish_and_wait "
            "for an all-in-one call."
        ),
        input_schema=WebsitePublishRequest,
        output_schema=WebsitePublishResponse,
    )
    async def website_publish(req: WebsitePublishRequest, ctx: ToolCtx) -> WebsitePublishResponse:
        return await ctx.client.call(
            "POST",
            "/v2/website.publish",
            json_body=req,
            response_model=WebsitePublishResponse,
            rate_limit_key="website.publish",
        )
  • Input and output schemas for the 'manus_website_publish' tool. WebsitePublishRequest inherits from _WebsiteTarget (exactly one of task_id or website_id required) and adds an optional visibility field. WebsitePublishResponse extends ResponseEnvelope with website_id and version_id.
    class WebsitePublishRequest(_WebsiteTarget):
        visibility: WebsiteVisibility | None = None
    
    
    class WebsitePublishResponse(ResponseEnvelope):
        website_id: str
        version_id: str
  • Base helper model enforcing that exactly one of task_id or website_id is provided. Used by WebsitePublishRequest and other website schemas.
    class _WebsiteTarget(ManusModel):
        """Helper: exactly one of task_id / website_id must be provided."""
    
        task_id: str | None = None
        website_id: str | None = None
    
        @model_validator(mode="after")
        def _one_of(self) -> _WebsiteTarget:
            if (self.task_id is None) == (self.website_id is None):
                raise ValueError("Exactly one of task_id or website_id must be provided")
            return self
  • The @manus_tool decorator registers 'manus_website_publish' in the global registry (_REGISTRY dict in registry.py). The decorator creates a ToolDef with name, description, input_schema, output_schema, and the handler function.
    @manus_tool(
        name="manus_website_publish",
        description=(
            "Deploy the latest checkpoint of a website. Async — poll manus_website_status until "
            "publish_status becomes 'published' or 'failed', or use manus_website_publish_and_wait "
            "for an all-in-one call."
        ),
        input_schema=WebsitePublishRequest,
        output_schema=WebsitePublishResponse,
    )
    async def website_publish(req: WebsitePublishRequest, ctx: ToolCtx) -> WebsitePublishResponse:
        return await ctx.client.call(
            "POST",
            "/v2/website.publish",
  • The decorator function that registers tools. When @manus_tool(name='manus_website_publish', ...) is applied to website_publish, this function creates a ToolDef entry in _REGISTRY with the tool's metadata and handler.
    def manus_tool(
        *,
        name: str,
        description: str,
        input_schema: type[TIn],
        output_schema: type[TOut],
        rate_limit_key: str | None = None,
    ) -> Callable[
        [Callable[[TIn, ToolCtx], Awaitable[TOut]]], Callable[[TIn, ToolCtx], Awaitable[TOut]]
    ]:
        """Decorator registering `handler` as a tool with the given metadata."""
    
        def wrap(
            handler: Callable[[TIn, ToolCtx], Awaitable[TOut]],
        ) -> Callable[[TIn, ToolCtx], Awaitable[TOut]]:
            if name in _REGISTRY:
                raise RuntimeError(f"Duplicate tool name: {name}")
            _REGISTRY[name] = ToolDef(
                name=name,
                description=description,
                input_schema=input_schema,
                output_schema=output_schema,
                handler=handler,
                rate_limit_key=rate_limit_key,
            )
            return handler
    
        return wrap
    
    
    def all_tools() -> list[ToolDef[Any, Any]]:
        """Return a stable-ordered copy of every registered tool."""
        return sorted(_REGISTRY.values(), key=lambda t: t.name)
    
    
    def clear_registry() -> None:
        """Test helper."""
        _REGISTRY.clear()
Behavior4/5

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

Describes async behavior and polling needed, plus the statuses to check. However, with no annotations, it lacks details on destructive effects, auth requirements, or side effects, but the main behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no unnecessary words. Front-loaded with purpose, then async guidance. Extremely efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite clear purpose and usage, the description omits parameter documentation and return value info. With no output schema and three undocumented params, the tool is not fully specified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any of the three input parameters (task_id, website_id, visibility). Schema coverage is 0%, and the description fails to compensate, leaving the agent unaware of parameter meanings.

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 clearly states 'Deploy the latest checkpoint of a website', using a specific verb and resource. It distinguishes from sibling tool manus_website_publish_and_wait by noting the async nature.

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?

Explicitly tells when to use: async deployment requiring polling, and provides an alternative: manus_website_publish_and_wait for an all-in-one call. Also instructs to poll manus_website_status.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aruxojuyu665/Manus-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server