Dezrez Rezi MCP server

Property events

get_property_events

Read-onlyIdempotent

Retrieve a property's event timeline—viewings, offers, notes, appointments—and filter by date range, event type, branch, and cancelled status.

Instructions

The timeline of one property: viewings, offers, notes, appointments and other events, newest to oldest as the API returns them, with dates, status, prices, the groups and people attending (names only by default), notes and negotiators. Filter by date range, event type(s), category, branch, and whether cancelled events are included. Uses GET /api/property/{id}/events.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Only events up to this date/time (API parameter `to`, ISO 8601). A date alone means the end of that day, UTC (2026-09-30 is sent as 2026-09-30T23:59:59Z).
`from`	No	Only events from this date/time (API parameter `from`, ISO 8601). A date alone means the start of that day, UTC (2026-09-01 is sent as 2026-09-01T00:00:00Z).
`page`	No	API page number to start from (1-based, as this server assumes; use next_page from a previous call)
`types`	No	Only these event types, as Rezi system names (API parameter `type`, repeated). The swagger does not list the values.
`branch_id`	No	Only events in this branch (API parameter `branchId`)
`max_results`	No	Most records to return in this call; whole API pages only, so fewer may come back with a next_page to continue from
`property_id`	Yes	Property ID (a positive whole number)
`excluded_types`	No	Every type except these (API parameter `excludedTypes`, repeated)
`show_cancelled`	No	Include cancelled events (API parameter `showCancelled`; the API's default is false)
`event_category_type`	No	Only this event category (API parameter `eventCategoryType`)
`include_contact_details`	No	Include attendees' and negotiators' email addresses and phone numbers, and stop redacting emails and phone numbers from notes, names and descriptions. Off by default.
`include_only_original_notes`	No	Skip note editions and return only original notes (API parameter `includeOnlyOriginalNotes`; the API's default is true)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 28, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: newest-to-oldest ordering, page-based pagination with whole-page returns and next_page continuation, contact details redacted by default, and the API's showCancelled=false default. It does not mention rate limits or auth, keeping it short of a 5.

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 dense but front-loaded paragraph: returned content first, then filtering, then the backing endpoint. No filler, though the enumeration of returned fields is long enough to be slightly heavy for a one-paragraph description.

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?

For a 12-parameter read tool with no output schema, the description usefully describes what comes back (fields, ordering) and how pagination works, complementing the annotations. It could say more about redaction/auth prerequisites, but nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the schema already documents all 12 parameters in detail (including defaults and the 'names only / redaction' semantics). The description's 'filter by date range, event type(s), category, branch, and cancelled' summary adds marginal value but no syntax or meaning beyond the schema, warranting the baseline 3.

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?

States a specific verb (get/retrieve the timeline) and resource (events for one property), enumerating the event kinds (viewings, offers, notes, appointments). An agent can distinguish it from get_group_events and list_offers without inspecting the schema.

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?

The description implies when this tool is relevant (fetching one property's event history) and lists the filter conditions, but it never names an alternative sibling or states when NOT to use it (e.g., vs get_group_events or get_property). Usage is implied rather than explicit.

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

Deploy Server

Property events

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools