Orivox AI Website Builder

copy_website_rebuild

Rebuild a copied website from a completed copy_website_extract job (step 2 of 2). This does NOT generate the site itself -- it returns the extracted content and YOU rebuild it via create_new_site. Follow this protocol:

Call this with the job_guid from copy_website_extract. It returns design_mode and, per source page, {source_url, title, is_index, text, text_truncated, images:[absolute URLs]}, ordered index page first.
Study every page's content, structure, and image URLs. Recreate the site as ONE complete, well-designed HTML document ( through ) that PRESERVES each source page's content and page purpose. Honour design_mode: "improve_original" -> stay close to the original's structure and refine it; "new_design" -> keep the content and purpose but redesign freely. Use the provided image URLs directly in -- they are already hosted; do not invent new ones.
Submit that single document via create_new_site in ONE call (pass this same project_guid).
Then work create_new_site's needs_attention worklist exactly as the normal build flow does: fix every "blocking" item with apply_dom_ops before telling the user the site is done.

The same steps are echoed in the response's rebuild_instructions field. This call is NOT metered; create_new_site is.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`job_guid`	Yes
`project_guid`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed3 schema fields changedAug 24, 2026

addedInput schema / properties / project_guid
```
Added value: +{
+  "type": "string"
+}
```
removedInput schema / properties / project_id
```
Removed value: -{
-  "type": "string"
-}
```

changedInput schema / required

Previous value: -[
-  "project_id",
-  "job_guid"
-]New value: +[
+  "project_guid",
+  "job_guid"
+]

First observedAug 4, 2026

TDQS

A4.7/5.0

Behavior4/5

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

The description reveals important behavioral traits beyond what any annotations provide: it does not build the site itself, it returns design_mode plus per-page extracted content in source page order, it echoes the same steps in rebuild_instructions, and it is not metered. Without annotations, the description carries the burden of behavioral disclosure and mostly meets it, but it does not explicitly address side effects, authentication, or failure behavior.

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?

The description is long but densely useful and well-structured. The purpose gets front-loaded in the first sentence, followed by a numbered protocol that earns its length toward the workflow. Nothing is filler; every sentence supports selection or correct invocation.

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?

Given output schema exists and annotations are absent, the description covers prerequisites, input parameter meanings, return shape and order, design_mode semantics, image handling, downstream integration with create_new_site, and the 'reported' field behavior. It is complete enough for an agent to invoke the tool correctly and continue the overall build process.

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 description coverage is 0%, so the description must compensate. It does: job_guid is defined as the value from copy_website_extract, and project_guid is identified as the same one that must be passed to create_new_site. It gives contextual meaning, though it lacks a clean standalone definition for each parameter.

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 states the exact action: 'Rebuild a copied website from a completed copy_website_extract job (step 2 of 2)'. It further clarifies that the tool itself does NOT generate the site, but returns extracted content for the agent to rebuild via create_new_site. This clearly distinguishes it from copy_website_extract and create_new_site.

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?

The description gives an explicit numbered protocol: call it only after copy_website_extract, with job_guid from that job, then submit the rebuilt HTML via create_new_site with the same project_guid, then handle create_new_site's needs_attention worklist. It also provides a practical cost/behavior distinction: 'This call is NOT metered; create_new_site is.'

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

All Orivox AI Website Builder tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation4/5

Most tools pair a distinct action with a distinct resource and long descriptions make intent clear. Still, `search_domains` already provides exact-domain checks, overlapping with `check_domain`, and the `create_project` vs `create_new_site` vs `create_page` cluster takes careful reading.

Naming Consistency5/5

The vast majority are snake_case verb_noun: list_projects, create_project, delete_page, get_preview_url, write_asset, query_database, publish_website. The only visible outlier is whoami, but it is standard enough that it does not disrupt predictability.

Tool Count2/5

At 36 tools this is meaningfully heavier than the rubric's 'too many' threshold, even though the scope spans websites, backends, domains, gallery images, and databases. It makes selection harder and a sizeable portion of the surface is niche or lifecycle internal.

Completeness4/5

The core site lifecycle is well covered: project, htmlmanag, assets, preview/publish, validation, deletion, uploaded images, backend files/logs, database reading, domain search and purchase linking. Workable non-critical gaps exist, e.g. no separate project metadata rename and no direct way to delete database rows or a database outside of deleting the project.

Resources

Need Help?