ShapelessAI

Record a product demo

demo_page

A real browser opens a URL and performs the steps you name (type, click, hover, scroll, wait); returns an MP4 media key drawn like a screen-recorded demo, with a cursor and camera that follow each action. A page behind a login demos as its login wall. Free: nothing is charged. Needs the write scope.

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": {
      "url": "<url>",
      "steps": "<steps>",
      "name": "<name>"
    },
    "name": "demo_page"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The absolute URL of the page to demo.
`name`	Yes	A 2-6 word filename for the clip, e.g. "analyze flow demo".
`zoom`	No	Ease the camera onto each element touched. On by default; off shows the whole page.
`steps`	Yes	One step per line or semicolon: "type acme.com into the URL field; click Analyze; wait 2; hover the first result; scroll to Pricing". Add "for 2s" to hold a step longer.
`aspect`	No	The clip's shape. 9:16 by default so it fills a reel behind a cutout speaker.
`viewport`	No	Which screen to demo on. mobile by default for a 9:16 clip (the page fills the reel), desktop otherwise or when the reel shows the desktop product.
`budgetUsd`	No	Optional: the most this call may spend, in dollars, default 2, max 10.
`browser_bar`	No	Draw a browser bar with the address above the page. On by default.

Output Schema

Name	Required	Description
`tool`	Yes
`media`	Yes
`output`	No	The tool's own result, shaped by the tool.
`chargedUsd`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 8, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses real-browser execution, the MP4 return type, the login-wall limitation, and the required write scope — meaningful context for a non-read-only, open-world tool. One flaw: it asserts "Free: nothing is charged" while the schema exposes budgetUsd with a default of 2 and a max of 10, a cost inconsistency the agent must resolve.

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?

Four compact sentences, front-loaded with the mechanism and the return artifact, with caveats after. Some phrasing is soft ("drawn like a screen-recorded demo", "Free: nothing is charged") but nothing is genuinely wasteful for a tool of this complexity.

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

Completeness4/5

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

An output schema exists, so the return shape needs no prose, and the description covers execution model, auth scope, and the login-wall failure mode. The only real gap is the unresolved tension between "Free" and the budgetUsd parameter, plus no note on step-count or runtime limits.

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 every parameter including zoom, aspect, viewport, browser_bar, and budgetUsd is already documented in the schema. The description's step verb list (type, click, hover, scroll, wait) largely restates the steps parameter description rather than adding syntax or edge-case meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb+resource: a real browser opens a URL, executes named steps, and returns an MP4 media key. That output detail separates it from still-image siblings like screenshot_page or read_page. It never names record_page or other adjacent capture tools, so an agent must infer the boundary rather than read it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the mechanism (a real browser driving a scripted flow) and the login-wall caveat tells the agent one situation where the result will be wrong. There is no explicit when-to-use versus record_page/screenshot_page/edit_footage guidance and no statement of when not to call it.

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

All ShapelessAI 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.