Orivox AI Website Builder

request_image_upload_link

Get a browser link the user opens to upload real image FILES to their site -- the reliable way to add actual photos, drawings, logos, or several images at once, and the tool to reach for the INSTANT a user pastes, attaches, uploads, or mentions an image they want used.

Call this and hand the user the link ANY time they have an image -- they have no other way to know the upload option exists, so always surface it; do not try to ingest a pasted/attached image yourself. You cannot carry image bytes yourself -- a tool call is text you have to type out, so a real photo either will not fit or arrives corrupted. This returns an upload_url instead: give that link to the user, tell them it works from their phone too and is valid for about an hour. On that page they can upload their own files, pick from images they already uploaded, or search a free stock photo gallery -- all without leaving the browser.

KEEP the returned token_id. When the user says they are done, call check_upload_link(token_id) to get back the EXACT images they chose and place those hosted URLs on the site with apply_dom_ops. role="logo" tags the link for a logo upload; "content" (default) for any other image. Requires an existing project_guid -- create_project first if there is no project yet.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`role`	No		content
`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"
-]New value: +[
+  "project_guid"
+]

First observedAug 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations to fall back on, the description carries the full burden of explaining behavior. It discloses the actual return value (upload_url), the limitation that tool calls cannot carry image bytes, the one-hour validity of the link, and the fact that token_id must be kept for later use. It also explains what the user can do on the upload page, which makes the tool's behavior much more predictable.

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 front-loaded with the core action and then gives a complete workflow, but it is somewhat wordy and repeats the same directive multiple times. It could be tightened without losing important context, but the structure moves logically from purpose to behavior to next steps, so the length still earns its place.

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?

The description fully covers the minimal but critical context for this tool: how to call it, what the response contains, what to do with the response, how to finish the workflow, and what prerequisites must exist. The existence of an output schema reduces the need to enumerate return fields further, and nothing important is missing.

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

Parameters5/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 resolve any ambiguity about parameters. It explicitly describes both: project_guid must reference an existing project, and role='logo' is for logo uploads while the default 'content' is for any other image. This adds real meaning beyond the raw 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?

The description clearly states what the tool does: it returns a browser link the user opens to upload real image files, rather than trying to ingest image bytes. It distinguishes itself from the broader site-building flow and explicitly frames itself as the reliable upload path for photos, drawings, logos, or multiple images.

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 explicit when-to-use guidance: call it anytime a user has an image, never try to handle attached images directly, and surface the link because the user has no other way to see the upload option. It also explains prerequisites and next steps: need an existing project_guid, then check_upload_link, then apply_dom_ops.

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?