Reel-E

Contact card

set_contact_card

Destructive

The end contact card: on or off, the agent's details, and the line above the name (prefix: default presented_by, none removes the line).

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": {
      "listingId": "<listingId>"
    },
    "name": "set_contact_card"
  }
}

Input Schema

Name	Required	Description
`prefix`	No	The line above the name, like presented_by or listed_by; none removes it.
`enabled`	No	Show (true) or hide (false) the end contact card.
`agentName`	No	The agent's name.
`brokerage`	No	The brokerage's name.
`listingId`	Yes	Listing id from list_listings.
`agentEmail`	No	The agent's email address.
`agentPhone`	No	The agent's phone number.
`agentTitle`	No	The agent's title, like 'Realtor'.
`licenseNumber`	No	The agent's license number, where it must be shown.

Output Schema

Name	Required	Description	Default
`status`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 10, 2026
- addedInput schema / properties / agentEmail / description
```
Added value: +"The agent's email address."
```
- addedInput schema / properties / agentName / description
```
Added value: +"The agent's name."
```
- addedInput schema / properties / agentPhone / description
```
Added value: +"The agent's phone number."
```
- addedInput schema / properties / agentTitle / description
```
Added value: +"The agent's title, like 'Realtor'."
```
- addedInput schema / properties / brokerage / description
```
Added value: +"The brokerage's name."
```
- addedInput schema / properties / enabled / description
```
Added value: +"Show (true) or hide (false) the end contact card."
```
- addedInput schema / properties / licenseNumber / description
```
Added value: +"The agent's license number, where it must be shown."
```
- addedInput schema / properties / prefix / description
```
Added value: +"The line above the name, like presented_by or listed_by; none removes it."
```
First observedNov 9, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare this a non-read-only mutation with destructiveHint=true, so the description need not restate that. It does add one genuinely useful behavioral detail not in the schema — the default prefix value of presented_by — but it is silent on the thing that matters most for a destructive setter: whether omitted fields are cleared, whether existing card values are overwritten, and whether partial updates are supported.

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?

A single sentence with no wasted wording, and the resource is stated first. The telegraphic list style ('on or off, the agent's details, and the line above the name') is slightly compressed but readable.

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

Completeness3/5

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

With nine parameters, an output schema, and annotations present, the infrastructure carries most of the load. Still, for a destructive mutation the description leaves out overwrite/partial-update semantics and any permission or listing-state prerequisites, which an agent would want before calling it.

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 the schema already documents all nine parameters, including the prefix enum and the 'none removes it' behavior. The description only contributes the default value for prefix, which is a marginal addition over what the schema provides.

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 names the concrete resource (the end contact card) and the three things it controls: visibility on/off, the agent's details, and the prefix line above the name. That is specific enough for an agent to distinguish it from sibling setters like set_headshot or set_title, though it never explicitly contrasts itself with them.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, no prerequisites (e.g. that a listing must exist), and no mention of alternatives or ordering relative to other set_* tools. Usage is only implied by the resource name.

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?