Reel-E

Start a new listing

start_listing

DestructiveIdempotent

Starts a NEW listing video. Takes the address (or a name for a listing with no public address) and, when the person has one, their public listing page link (Zillow, Redfin or a brokerage page), whose photos and facts Reel-E imports. An idempotencyKey, reused on retry, returns the same draft every time. Next come add_listing_photos, optionally set_listing_basics, then start_video. Photos come from the person: attached in the chat where the app supports it, imported from the listing link, or added at addPhotosUrl from the result, a Reel-E page where they drop photos from their computer or phone; get_listing_status then shows the count.

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": {
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "start_listing"
  }
}

Input Schema

Name	Required	Description
`beds`	No	Number of bedrooms.
`name`	No	Only for a listing with no public address.
`sqft`	No	Interior square feet.
`baths`	No	Number of bathrooms; halves allowed, like 2.5.
`price`	No	List price in dollars, a plain number like 1200000.
`address`	No	The property's address.
`description`	No	The listing description, in the person's words.
`listingLink`	No	An https link to the public listing page to import.
`idempotencyKey`	Yes	8 to 128 letters, digits, dots, dashes, underscores or colons. Reuse it on retry.

Output Schema

Name	Required	Description	Default
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedNov 10, 2026
- addedInput schema / properties / address / properties / city / description
```
Added value: +"City or town."
```
- addedInput schema / properties / address / properties / country / description
```
Added value: +"Country, when outside the United States."
```
- addedInput schema / properties / address / properties / state / description
```
Added value: +"State or province, like 'TX'."
```
- addedInput schema / properties / address / properties / street / description
```
Added value: +"Street number and name, like '12 Oak Lane'."
```
- addedInput schema / properties / address / properties / unit / description
```
Added value: +"Unit, apartment or suite, when there is one."
```
- addedInput schema / properties / address / properties / zip / description
```
Added value: +"ZIP or postal code."
```
- addedInput schema / properties / baths / description
```
Added value: +"Number of bathrooms; halves allowed, like 2.5."
```
- addedInput schema / properties / beds / description
```
Added value: +"Number of bedrooms."
```
- addedInput schema / properties / description / description
```
Added value: +"The listing description, in the person's words."
```
- addedInput schema / properties / price / description
```
Added value: +"List price in dollars, a plain number like 1200000."
```
- addedInput schema / properties / sqft / description
```
Added value: +"Interior square feet."
```
First observedNov 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true, openWorldHint=true and destructiveHint=true; the description adds real value on top by explaining that a reused idempotencyKey returns the same draft on retry and that the listingLink triggers an outbound import of photos and facts. It also explains the photo-collection paths, including an addPhotosUrl returned in the result that is a Reel-E page for uploads. It doesn't explain why a create is marked destructive (credits, side effects), which is the one behavior an agent would still want.

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?

Purpose and inputs are front-loaded, then the follow-up workflow, with no filler sentences. The final sentence about photo sources is a long run-on that packs several distinct facts (chat attachments, link import, addPhotosUrl, get_listing_status) and would read better as a short list.

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 9-parameter create tool with a nested address object and an output schema, the description covers the inputs that matter, the idempotency contract, and the downstream steps an agent must take. Return values are covered by the output schema, so nothing essential 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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: name is only for listings with no public address, listingLink is an https page whose photos and facts get imported, and idempotencyKey is meant to be reused on retries to get the same draft. Those are semantic constraints the schema's terse per-property text does not convey.

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 first sentence names a specific verb and resource ('Starts a NEW listing video') and immediately bounds the inputs (address, or a name when there's no public address, plus an optional public listing link). It is clearly distinguishable from start_video and add_listing_photos because it describes itself as the first step that those later tools build on.

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

Usage Guidelines4/5

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

The description lays out the workflow order explicitly: this tool first, then add_listing_photos, optionally set_listing_basics, then start_video, and points to get_listing_status for photo counts. It also gives the conditional rule for name vs address. It does not state when NOT to use it (e.g., how to find or resume an existing listing), so it stops short of full routing guidance.

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

All Reel-E 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?