List properties (RESO Property resource) from Qobrix CRM. Core tool for the Listing Lifecycle — use to browse active inventory, track status changes, or audit listings. Returns { data: [...], pagination: { count, current_page, has_next_page, has_prev_page, page_count, limit } }. RESO StandardStatus mapping: 'available' = Active, 'reserved' = Pending/Under Contract, 'sold' = Closed, 'withdrawn' = Withdrawn. Key fields (184 total): name, ref, status, sale_rent (for_sale/for_rent), property_type, property_subtype, city, country, list_selling_price_amount, list_rental_price_amount, bedrooms, bathrooms, covered_area_amount, plot_area_amount, agent (UUID → qobrix_get_agent), seller (UUID → qobrix_get_contact), project (UUID → qobrix_get_project), salesperson (UUID → user). Workflow recipes: Active inventory → search: status == "available" and sale_rent == "for_sale". Recent listings → sort: '-created'. Buyer-property match → prefer qobrix_search_properties with search + boost for free-language demand. Listing media → follow up with qobrix_list_media(related_model='Properties'). PAYLOAD DEFAULTS: expand=false and media=false — FKs come back as UUIDs and media is not inlined (set expand=true / media=true explicitly when full nested objects or media URLs are needed). Prefer include[] for surgical expansion of specific associations. Default limit 10, max 100.

Get a single property by UUID — the listing detail view in the Listing Lifecycle. Returns { data: { id, name, status, ... } }. RESO StandardStatus: 'available' = Active, 'reserved' = Pending, 'sold' = Closed, 'withdrawn' = Withdrawn. Use include[] to expand related entities inline: Verified: Agents, PropertyTypes, PropertySubtypes, PropertyViewings, Opportunities, Translations, SalespersonUsers, CreatedByUsers, LocationLocations, AgentAgents, SellerContacts, ProjectProjects. Workflow tips: include=['PropertyViewings'] → see showing history (Showing Lifecycle). include=['Opportunities'] → see interested leads (Sales Pipeline). include=['AgentAgents'] → listing agent (RESO ListAgent). include=['SellerContacts'] → seller/owner (RESO OwnerMember). FK fields: agent → Agents, seller → Contacts, project → Projects, salesperson → Users.

Highly relevant property search for free-language buyer demand (F1-optimized). TWO-TIER RECIPE: (1) search = hard DSL must-haves (server filter → precision). (2) boost[] = soft weighted nice-to-haves scored client-side over up to max_scan candidates (recall + ranking → better precision@top). (3) limit = how many ranked rows to return (default 10, max 100) — raise for more options, keep modest to avoid context overload. With boost: returns top-N with _relevance (score) and _matched (which boosts hit); pagination.mode='ranked' and pagination.scanned shows pool size. Without boost: fast path — single cached list page (pagination.mode='fast'). Call qobrix_search_dsl_help({resource:'Properties'}) before composing queries. Examples: Hard only: search='status == "available" and sale_rent == "for_sale" and city contains "Limassol"'. Demand match: search='status == "available" and sale_rent == "for_sale"', boost=[{field:'sea_view',op:'==',value:true,weight:3},{field:'bedrooms',op:'>=',value:3,weight:2},{field:'list_selling_price_amount',op:'in',value:'200000..600000',weight:2}], limit=15, max_scan=200. PAYLOAD: keep expand=false / media=false for search; when either is true, max_scan is auto-capped at 100. If a result returns status='result_too_large' with _refine_required, ask the user to narrow the query (filters, fields[], smaller limit, drop expand/media) then retry. All upstream pages are response-cached (QOBRIX_CACHE_TTL, default 300s).

Get lat/lng coordinates for properties, useful for map display. Optionally filter with a search expression to get coordinates for a subset. Returns array of { id, coordinates } objects.

Get properties explicitly linked to a lead — the 'demand-side view' in the Sales Pipeline. Shows which properties a lead/opportunity has been matched to or expressed interest in. The id parameter is the Opportunity UUID (not the property UUID). In the canonical buyer journey: after Qualification, use this to review Solution/Viewing candidates. Alternative: qobrix_get_opportunity with include=['Properties'] for inline expansion. Complement with qobrix_get_leads_by_property for the reverse (supply-side) match.

List contacts (RESO Contacts resource) from Qobrix CRM — the people/companies in the CRM. Core to the Lead-Contact Lifecycle: a Contact becomes a Lead when an Opportunity is created for them. RESO ContactType mapping: use opportunity.enquiry_type and property.seller FK to determine Buyer/Seller/Tenant role. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Key fields (42 total): first_name, last_name, name, email, phone, city, country, assigned_to (UUID → user, RESO OwnerMember), role, is_company, nationality, preferred_language, preferred_contact_method, consent fields, created, modified. Cross-references: property.seller → Contact UUID, opportunity.contact_name → Contact UUID, task.contact → Contact UUID, call/meeting.contact → Contact UUID. Workflow: to see a contact's full journey, search Opportunities, Tasks, Calls, and Meetings by their UUID.

Get a single contact by UUID — the person/company detail view in the Lead-Contact Lifecycle. Returns { data: { id, first_name, last_name, email, phone, ... } }. Verified include: AssignedToUsers (RESO OwnerMember), User, Language, Organizations. To build the full contact journey (canonical 360° view): 1. Leads: qobrix_search_opportunities with contact_name == '' 2. Tasks: qobrix_search_tasks with contact == '' 3. Calls: qobrix_search_calls (search by contact FK) 4. Meetings: qobrix_search_meetings (search by contact FK) 5. Seller listings: qobrix_search_properties with seller == '' This contact 360° pattern is the core of Lead-Contact Lifecycle and Follow-up workflows.

Relevance-ranked contact search (F1-optimized). TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences scored over up to max_scan candidates; limit = top-N returned. With boost: rows get _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Contacts'}) for DSL + fields. Examples: search='country == "CY"', boost=[{field:'city',op:'==',value:'Limassol',weight:2},{field:'is_company',op:'==',value:false,weight:1}], limit=10, max_scan=100. Hard-only: assigned_to == CURRENT_USER; name contains "Smith"; created >= THIS_MONTH.

List agents (RESO Member resource) — real estate brokers managing listings and leads. Agents are the central actor across all workflows: they manage the Listing Lifecycle, drive the Sales Pipeline, and own Follow-up activities. Referenced by property.agent and opportunity.agent FKs. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Verified include: PrimaryContactContacts, User, Brands, AgencyAgents (parent agency). Workflow: to see an agent's full portfolio, search Properties and Opportunities by agent == ''.

Get a single agent by UUID — resolve a RESO Member/ListAgent from a listing or lead. Returns { data: { id, ref, ... } }. Verified include: PrimaryContactContacts, User, Brands, AgencyAgents (parent brokerage). Agent 360° pattern: 1. Active listings: qobrix_search_properties with agent == '' and status == "available" 2. Active leads: qobrix_search_opportunities with agent == '' and status == "open" 3. Pipeline deals: qobrix_search_offers / qobrix_search_contracts linked to agent's opportunities 4. Activity: search Tasks, Calls, Meetings by the agent FK

Relevance-ranked agent search (F1-optimized). TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences; limit/max_scan control top-N and pool size. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Agents'}) for DSL + fields. Example: boost=[{field:'ref',op:'contains',value:'LIM',weight:2}], limit=10, max_scan=100.

List opportunities/leads from Qobrix CRM — the central entity of the Sales Pipeline and Lead-Contact Lifecycle. In Qobrix, leads ARE opportunities. Each represents a buyer/renter/investor enquiry. RESO funnel mapping: 'new' = MQL/Lead, 'open' = SQL/Active, 'won' = Closed Won, 'closed_lost' = Lost. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. IMPORTANT: Avoid include=['Locations']. Safe verified includes: ContactNameContacts, Properties, AgentAgents, PropertyTypes, ClosedLostReason, User, OwnerUsers. Key fields (77 total): status, enquiry_type (buy/rent/invest), buy_rent, contact_name (UUID → Contact), agent (UUID → Agent), owner (UUID → user), source, area_of_interest, bedrooms_from/to, price ranges, next_follow_up_date, enquiry_date. Workflow patterns: Pipeline overview: group by status to see funnel distribution. Overdue follow-ups: status == "open" and next_follow_up_date <= NOW. New leads this week: created >= THIS_WEEK and status == "new". Two-way matching: demand→supply via qobrix_search_properties with lead criteria; supply→demand via this tool with boost against a listing (or native qobrix_get_leads_by_property).

Get a single lead/opportunity by UUID — drill into a pipeline deal in the Sales Pipeline workflow. Returns { data: { id, ref, status, enquiry_type, contact_name, agent, ... } }. RESO mapping: status 'new' = Lead, 'open' = Active/SQL, 'won' = Closed Won, 'closed_lost' = Lost. Verified include: ContactNameContacts (the person), Properties (linked listings), AgentAgents (assigned broker, RESO ListAgent), PropertyTypes, ClosedLostReason, User, OwnerUsers. Canonical deal drill-down pattern: 1. Get the lead with include=['ContactNameContacts','Properties','AgentAgents'] 2. Check showing history: qobrix_list_viewings (search by related property) 3. Check offers: qobrix_search_offers for this lead 4. Check activity: search Tasks, Calls, Meetings linked to this opportunity FK: contact_name → Contacts, agent → Agents, owner → Users.

Relevance-ranked lead/opportunity search (F1-optimized) — primary pipeline filter AND supply→demand matching. TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences scored over max_scan candidates; limit = top-N. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Opportunities'}) for DSL + buyer-criteria fields. Pipeline recipes: status == "open"; created >= THIS_WEEK and status == "new"; next_follow_up_date <= NOW and status == "open". Supply→demand (who wants this listing?): search='status in ["new","open"] and buy_rent == "buy"', boost=[{field:'area_of_interest',op:'contains',value:'Limassol',weight:3},{field:'bedrooms_from',op:'<=',value:3,weight:2},{field:'list_selling_price_to',op:'>=',value:400000,weight:2}], limit=15, max_scan=200. Works for projects too (native by-property does not).

Get matching leads for a property — the 'supply-side matching' tool in the Sales Pipeline. Answers: 'Who is interested in this listing?' by returning leads whose criteria match the property. This is the canonical buyer-property matching pattern (RESO Prospecting). Use after listing a new property to find potential buyers in the existing lead database. Complement with qobrix_get_lead_properties for the reverse (demand-side) match, or qobrix_search_opportunities with boost for ranked matching (incl. projects). The propertyId is the Property UUID. Returns paginated results.

Get properties linked to a lead — the 'demand-side matching' tool in the Sales Pipeline. Answers: 'What properties does this buyer want?' by returning properties attached to an opportunity. This is the canonical property suggestion pattern (RESO Demand/Solution matching). Reverse of qobrix_get_leads_by_property (which finds leads for a property). For free-language / ranked demand→supply (incl. projects), use qobrix_search_properties / qobrix_search_projects with search+boost derived from the lead's criteria. In the 8-stage buyer journey, use at the Solution/Viewing stage to prepare showing candidates. The id is the Opportunity UUID.

List property viewings (RESO ShowingAppointment) — the Showing/Viewing Lifecycle tool. Viewings are the pivot between Follow-up and Active Sales: the first viewing marks a lead as actively engaged. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Each viewing links a property, a contact, and an agent/creator. Verified include: PropertyViewingViewing. Workflow patterns: This week's viewings: search with created >= THIS_WEEK. Property's showing history: qobrix_get_property with include=['PropertyViewings']. Meetings linked to viewings: qobrix_list_meetings with include=['ViewingPropertyViewings']. After a showing, the next pipeline step is Offer → Contract → Close.

Get a single viewing by UUID — the showing detail view in the Showing Lifecycle. Returns { data: { id, ... } }. Verified include: PropertyViewingViewing. After retrieving, use the property and contact FKs to trace back to the listing and lead.

Relevance-ranked viewing search (F1-optimized). TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences; limit/max_scan for top-N and pool. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'PropertyViewings'}) for fields. Example: search='created >= THIS_WEEK', boost=[{field:'created',op:'>=',value:'2026-01-01',weight:1}], limit=10.

List tasks — the operational backbone of all canonical workflows: Follow-up, Pipeline Management, and Listing Checklists. Tasks drive daily agent cadence: overdue follow-ups, listing prep, closing steps, payment tracking. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Include: AssignedToUsers (task owner), ContactContacts (related person), Properties (listing), RelatedOpportunityOpportunities (lead), RelatedAgentAgents, RelatedContractContracts, TaskStatus, TaskTypes, CreatedByUsers, ModifiedByUsers. Canonical patterns: My open tasks: search with assigned_to == CURRENT_USER and status != "completed". Overdue: search with due_date <= NOW and status == "pending". Tasks for a lead: search with related opportunity FK. Listing checklist: search tasks linked to a property UUID.

Get a single task by UUID — task detail for pipeline management and follow-up audit. Returns { data: { id, ... } }. Include: AssignedToUsers (who), ContactContacts (for whom), Properties (which listing), RelatedOpportunityOpportunities (which deal), RelatedAgentAgents, TaskStatus, TaskTypes.

Relevance-ranked task search (F1-optimized) — daily ops for pipeline and follow-up. TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences; limit/max_scan for top-N and pool. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Tasks'}) for fields. Recipes: search='assigned_to == CURRENT_USER and status != "completed"', boost=[{field:'due_date',op:'<=',value:'2026-12-31',weight:3}], limit=15, max_scan=100. Overdue hard filter: due_date <= NOW and status == "pending".

List media items (RESO Media resource) — photos, documents, floor plans attached to any entity. Core to the Media Lifecycle: every listing needs photos and floor plans; projects need brochures. NOTE: Returns { data: [...] } WITHOUT pagination metadata (unlike other endpoints). Must provide BOTH related_model AND related_id together, or omit both for global media. Listing media: related_model='Properties', related_id=''. Contact documents: related_model='Contacts', related_id=''. Project brochures: related_model='Projects', related_id=''. Alternative: qobrix_list_properties with media=true (default) embeds media in property responses. Each item has: id, media_type, reference_id, display_order, category, created.

Get a single media item by UUID — media detail view in the Media Lifecycle. Returns media metadata including URL/path. Optionally specify size variant for images: 'thumbnail', 'medium', 'large'. Use 'thumbnail' for preview grids, 'large' for full-resolution display.

List projects (property developments/complexes) — RESO Project equivalent for off-plan and new-build listings. Projects group multiple property units under one development, relevant in the Listing Lifecycle for new-builds. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Properties reference their project via the 'project' FK. Verified include: Agents, Developer, Translations, LocationLocations, Assignee, Recommended, Favorites. Workflow: to see units in a project, qobrix_search_properties with project == ''.

Get a single project by UUID — development detail view for off-plan/new-build listings. Returns { data: { id, ... } }. Verified include: Agents, Developer, Translations, LocationLocations, Assignee, Recommended, Favorites. To see project units: qobrix_search_properties with project == ''. To see project media: qobrix_list_media with related_model='Projects' and related_id=.

Highly relevant project (development) search for free-language demand (F1-optimized). TWO-TIER RECIPE: (1) search = hard DSL must-haves (server filter → precision). (2) boost[] = soft weighted nice-to-haves scored over up to max_scan candidates (recall + ranking). (3) limit = how many ranked rows to return (default 10, max 100). With boost: top-N with _relevance and _matched; pagination.mode='ranked'. Without boost: fast path single cached page; pagination.mode='fast'. Call qobrix_search_dsl_help({resource:'Projects'}) for DSL + field cheatsheet. Example: search='city contains "Paphos"', boost=[{field:'starting_price_from',op:'<=',value:400000,weight:2},{field:'construction_stage',op:'==',value:'under_construction',weight:1}], limit=10, max_scan=150. When expand=true or media=true, max_scan is auto-capped at 100. If status='result_too_large' with _refine_required, ask the user to narrow then retry. All upstream pages are response-cached.

Get lat/lng coordinates for projects, useful for map display. Optionally filter with a search expression.

List offers (RESO TransactionManagement) — the 'Decision Making' stage of the Sales Pipeline. An Offer formalizes a buyer's intent: it links an Opportunity (the lead) to a Property (the listing) with a price. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Include: OpportunityOpportunities (the lead), PropertyProperties (the listing), CreatedByUsers, ModifiedByUsers. Canonical transaction chain: Lead → Viewing → Offer → Contract → Close. After an offer is accepted, the next step is Contract creation (qobrix_list_contracts).

Get a single offer by UUID — offer detail view in the Transaction Lifecycle. Returns { data: { id, ... } }. Include: OpportunityOpportunities (the lead/buyer intent), PropertyProperties (the listing), CreatedByUsers, ModifiedByUsers. Use to trace the deal chain: Offer → Opportunity → Contact + Property → Contract.

Relevance-ranked offer search (F1-optimized). TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences; limit/max_scan for top-N and pool. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Offers'}) for fields. Example: search='created >= THIS_MONTH', boost=[{field:'created',op:'>=',value:'2026-01-01',weight:1}], limit=10, max_scan=100.

List contracts (RESO TransactionManagement close) — the 'Deal Signing / Payment / Close' stage of the Sales Pipeline. A Contract finalizes the transaction: it links the Property, buyer/seller Contacts, and the Opportunity. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Verified include: Contacts, PropertyIdProperties, OpportunityIdOpportunities, PaymentInstallments (payment schedule), ContractParties (all signatories), CreatedByUsers. Canonical chain: Offer → Contract → Payment → Close. After contract signing, the property status moves to 'reserved' (Pending), then 'sold' (Closed).

Get a single contract by UUID — the deal close detail view in the Transaction Lifecycle. Returns { data: { id, ... } }. Verified include: Contacts (buyer/seller), PropertyIdProperties (the listing), OpportunityIdOpportunities (the lead), PaymentInstallments (payment schedule), ContractParties (all signatories), CreatedByUsers. Use include=['PaymentInstallments'] to audit the payment timeline.

Relevance-ranked contract search (F1-optimized). TWO-TIER: search = hard must-haves; boost[] = soft weighted preferences; limit/max_scan for top-N and pool. With boost: _relevance + _matched; pagination.mode='ranked'. Call qobrix_search_dsl_help({resource:'Contracts'}) for fields. Example: search='contract_type == "cos" and contract_status == "agreed"', boost=[{field:'final_selling_price_amount',op:'>=',value:300000,weight:2}], limit=10, max_scan=150. Prefer qobrix_deals for common closed-deal questions.

List call records — part of the Activity Tracking / Follow-up workflow. Calls are touchpoints in the Lead-Contact Lifecycle; zero tolerance on missed follow-ups. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Include: ContactContacts (who was called), AssignedToUsers (who made the call), RelatedOpportunityOpportunities (which lead), RelatedAgentAgents, RelatedContractContracts. Workflow: use with qobrix_list_meetings and qobrix_list_email_messages for a complete activity timeline. To audit a contact's engagement: search calls, meetings, and emails by their contact UUID.

Get a single call record by UUID — call detail in the Activity Tracking workflow. Returns { data: { id, ... } }. Include: AssignedToUsers, ContactContacts, RelatedOpportunityOpportunities, RelatedAgentAgents, CreatedByUsers.

List meetings — bridges the Activity Tracking and Showing Lifecycle workflows. Meetings can wrap property viewings (RESO Showing ↔ Meeting). Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Include: ContactContacts, ViewingPropertyViewings (linked showings), AssignedToUsers, RelatedOpportunityOpportunities, RelatedAgentAgents, CreatedByUsers, ModifiedByUsers. Workflow: include=['ViewingPropertyViewings'] to see which meetings are property showings vs general meetings. The first meeting/showing is the canonical trigger that moves a lead from follow-up to active sales.

Get a single meeting by UUID — meeting detail in the Activity/Showing Lifecycle. Returns { data: { id, ... } }. Include: AssignedToUsers, ContactContacts, ViewingPropertyViewings (if it wraps a showing), CreatedByUsers.

List email messages — part of the Activity Tracking / Follow-up workflow and marketing campaigns. Emails are touchpoints in the Lead-Contact Lifecycle for nurturing and communication. Returns { data: [...], pagination: { count, current_page, has_next_page, ... } }. Include: ContactContacts (recipient/sender), Properties (listing references), Campaign (marketing campaign), RelatedOpportunityOpportunities, RelatedAgentAgents. Use with qobrix_list_calls and qobrix_list_meetings for a complete contact engagement timeline.

Get a single email message by UUID — email detail in the Activity Tracking workflow. Returns { data: { id, ... } }. Include: Properties, ContactContacts, RelatedOpportunityOpportunities, Agent, Campaign.

Get the full field schema for any CRM resource — the Schema Discovery tool. CALL THIS FIRST when unsure about field names for search, fields[], or sort. Returns every field with name, type, label, and validation rules (RESO Data Dictionary equivalent). Resources (case-sensitive): Properties, Contacts, Opportunities, Agents, Tasks, PropertyViewings, Projects, Offers, Contracts, Calls, Meetings, EmailMessages, Media, PropertyTypes, PropertySubtypes, PropertyFeatures, Locations. Canonical use: before building search expressions for any workflow (Listing, Sales Pipeline, Follow-up), call this to discover the correct field names. The schema is the source of truth. Pair with qobrix_get_field_options to see allowed enum values for dropdown fields. For search grammar, prefer qobrix_search_dsl_help.

Get dropdown/enum field options — discover valid values for status fields, types, and categories. Essential for building correct search expressions in any workflow. Returns { data: [...], pagination: { ... } }. Each item has: id, resource, field, label, value. Key examples for canonical workflows: Listing statuses: search='resource == "Properties" and field == "status"' → available/reserved/sold/withdrawn. Lead statuses: search='resource == "Opportunities" and field == "status"' → new/open/won/closed_lost. Property types: search='resource == "Properties" and field == "property_type"'. Task types: search='resource == "Tasks" and field == "task_type"'. Pair with qobrix_get_schema for complete field discovery.

Return the full Qobrix Search Expression DSL reference so you can build correct search strings and boost[] clauses for ANY qobrix_search_* tool (properties, projects, contacts, agents, opportunities, viewings, tasks, offers, contracts). Includes operators, functions, date helpers, association paths, and the two-tier relevance recipe (hard search filter + soft boost ranking + limit/max_scan). Optional resource (e.g. 'Properties', 'Opportunities', 'Contacts') appends a field cheatsheet and live schema field names (schema fetch is response-cached). Call before composing free-language queries.

Count records matching a search expression — returns just the total count, no data payload. Faster and lighter than fetching records when you only need a number. Example uses: Total active sale listings: resource='properties', search='status == "available" and sale_rent == "for_sale"'. Q1 closed-won opportunities: resource='opportunities', search='status == "closed_won" and last_status_change >= "2026-01-01" and last_status_change < "2026-04-01"'. Contacts created this month: resource='contacts', search='created >= THIS_MONTH'.

Aggregate records by a field and return the top N most-frequent values with counts. This tool paginates through all matching records server-side — no client-side scripting needed. Caps at 20,000 records for safety; use a search filter to narrow large datasets. Example uses: Top listing developers: resource='properties', field='developer_id', search='status == "available" and sale_rent == "for_sale"', resolve=true. Lead sources: resource='opportunities', field='source', search='created >= "2026-01-01"'. Agent workload: resource='opportunities', field='owner', search='status == "open"', resolve=true. Property type mix: resource='properties', field='property_type', search='status == "available"'. Set resolve=true to convert UUIDs (developer_id, agent, owner, etc.) to human-readable names.

Top-N rows of any resource sorted by a numeric or ISO-date field. Paginates server-side (cap 20,000 rows), sorts in-process, and resolves common FK fields (property_id, agent, owner, assigned_to, commission_to, commission_to_2, contact_name, salesperson, seller, project, developer_id, campaign_id) into readable names so the agent doesn't have to chain lookups. Use this for full-dataset top-N, or when list/search sort returns no rows on a nullable/computed field (e.g. opportunities.budget). For a single page of highest list prices, prefer qobrix_list_properties / qobrix_search_properties with sort='-list_selling_price_amount'. Example uses: Top 2026 closed sales: resource='contracts', sort_by='final_selling_price_amount', search='contract_type == "cos" and contract_status == "agreed" and date_of_contract >= "2026-01-01" and date_of_contract < "2027-01-01"'. Largest active listings (full scan): resource='properties', sort_by='list_selling_price_amount', search='status == "available" and sale_rent == "for_sale"'. Most recently modified leads: resource='opportunities', sort_by='modified'.

Sum / avg / min / max / count of a numeric field across all matching records — optionally grouped by another field (top-N buckets). Paginates server-side (cap 20,000 rows) and computes in-process, which is how to get totals on Qobrix fields the API won't sort. Example uses: Total 2026 closed-sale volume: resource='contracts', field='final_selling_price_amount', op='sum', search='contract_type == "cos" and contract_status == "agreed" and date_of_contract >= "2026-01-01" and date_of_contract < "2027-01-01"'. Agent leaderboard by volume: same search, group_by='commission_to_2', top=5. Average list price by property type: resource='properties', field='list_selling_price_amount', op='avg', group_by='property_type', search='status == "available"'.

Flexible 'deals' tool over the Contracts table — covers sales, rentals, listing agreements, and pipeline reservations in a single call. Defaults: kind='sale', contract_statuses=['agreed'] (so a no-arg call still means 'closed sale contracts'). Every default is overridable via kind / contract_types / contract_statuses / include_reserved / date_field / min_price / max_price / party filters / raw search. Sorts in-process across the matching set (for a single page of highest prices you can also use list/search with sort='-final_selling_price_amount') and resolves property_id, agent, commission_to, lawyers, bank, etc. to readable names. Example uses: Best 2026 closed sales: { year: 2026, top: 5 }. Best 2026 rentals: { kind: 'rental', year: 2026, top: 5 }. Under-contract pipeline value: { contract_statuses: ['reserved'], year: 2026 }. My deals: { assigned_to: 'CURRENT_USER', year: 2026 }. All revenue deals >€1M last 90 days: { kind: 'any_revenue', since_days: 90, min_price: 1000000 }. Agent leaderboard (by commission): { year: 2026, by: 'commission', top: 10 }.

Time-bucketed metric (count / sum / avg / min / max) over any resource. Paginates once over the window, buckets in-process by day/week/month/quarter/year (default 'month'). Per-resource default date_field: contracts→date_of_contract, opportunities/properties/calls/etc.→created. Use search to filter (e.g. only closed sales). Set compare_to_prior=true to also fetch the prior identical-length window for YoY %. Example uses: Monthly 2026 closed-sale volume with YoY: resource='contracts', metric='sum', field='final_selling_price_amount', year=2026, search='contract_type == "cos" and contract_status == "agreed"', compare_to_prior=true. Weekly lead intake last 90 days: resource='opportunities', bucket='week', metric='count', since_days=90. Quarterly listing additions 2026: resource='properties', bucket='quarter', year=2026, metric='count'.

Days-on-market analytics. Joins Contracts to Properties on property_id and computes the (close_date - listing_date) duration in days, then aggregates count / mean / median / p75 / p90 / min / max. Defaults: kind='sold' (cos + agreed), listing_date_field='listing_date' with per-row fallback to website_listing_date then created. Use group_by to break down by property_type, city, agent, or commission_to_2 (broker). Set include_outliers=true for the 5 longest and 5 shortest deals. Example uses: Overall DOM for 2026 sales: { kind: 'sold', year: 2026 }. DOM by property type: { kind: 'sold', year: 2026, group_by: 'property_type' }. DOM by city (with outliers): { year: 2026, group_by: 'city', include_outliers: true }. Reservation cycle: { kind: 'reserved', year: 2026 }.

Canonical sales funnel in one call. Six stages with conversion %: Leads (opportunities created in window) → Qualified (status in [open,won]) → Viewing (property-viewings created in window) → Offer (offers created in window) → Reserved (contracts with contract_status=reserved) → Closed (contracts cos + agreed). Each stage is scoped by the same date window and (optional) assigned_to / agent. Use stage_overrides to substitute a tenant-specific definition for any stage. Example uses: 2026 funnel: { year: 2026 }. My funnel last 90 days: { assigned_to: 'CURRENT_USER', since_days: 90 }. Agent Vera's funnel: { agent: '', year: 2026 }.

Win-rate analytics over opportunities. Globally returns counts of new / open / won / closed_lost plus win_rate_pct = won / (won + closed_lost). Optional group_by slices by source, enquiry_type, owner, agent, or closed_lost_reason_id (multi-dim arrays supported). Window applied to last_status_change (fallback modified). Set include_top_losses=true to also receive the 10 most-recent closed_lost opportunities with reason labels and details. Example uses: Overall 2026 win rate: { year: 2026 }. Win rate by lead source: { year: 2026, group_by: 'source' }. Top loss reasons last 90 days: { since_days: 90, group_by: 'closed_lost_reason_id' }. My win rate: { assigned_to: 'CURRENT_USER', year: 2026 }. Forensic loss review: { year: 2026, include_top_losses: true }.

Find live opportunities (default status in [new,open]) that have no recent activity. An opportunity is 'stale' when no call/meeting/email/task touched it within since_days AND the opportunity itself wasn't modified within that window. Sorted oldest-modified first. Example uses: Silent leads (default, 30d): {}. Aggressive cadence: { since_days: 7 }. My silent leads: { assigned_to: 'CURRENT_USER' }.

Per-rep productivity roll-up. One call returns a wide row for a single user or a top-N leaderboard (default). Counts calls/meetings/emails/tasks/viewings/opportunities and deals closed; sums total_volume + total_commission from closed contracts. Bucketed by assigned_to across every resource. Example uses: Leaderboard 2026 by volume: { year: 2026 }. My scorecard last 30 days: { user: 'CURRENT_USER', since_days: 30 }. Top 5 by activities this quarter: { from: '2026-01-01', to: '2026-04-01', sort_by: 'activities', top: 5 }.

Find contacts that appear on multiple deals or opportunities — the 'repeat customer' report every CRM analyst gets asked for. Three modes: 'buyers' (default) walks closed contracts → opportunity_id → opportunities.contact_name to identify the buyer behind each closed sale. 'sellers' walks contracts → property_id → properties.seller. 'leads' groups all opportunities by contact_name regardless of close. Returns each repeat contact with deal_count, total_volume, total_commission, first_deal, last_deal, and a deals[] breakdown. Example uses: 2026 repeat buyers: { kind: 'buyers', year: 2026, min_count: 2 }. All-time loyal customers: { kind: 'buyers', min_count: 3 }. Recurring sellers this year: { kind: 'sellers', year: 2026 }. Frequent enquirers (any close): { kind: 'leads', since_days: 365 }.

Inspect the response cache: hits/misses, in-memory size, in-flight coalesced requests, TTL (seconds), and Redis tier status. Use to verify the cache is paying off (high hits, low misses on repeated workflows) or to diagnose why a query feels slow (cold cache, Redis degraded). Stats are process-local; restart resets them.

Invalidate cached Qobrix responses. Use this when CRM data was edited in Qobrix and you need fresh reads before the TTL (default 300s) expires. Without 'prefix': clears the whole cache (memory + Redis). With 'prefix': clears only matching keys, e.g. 'v1:request:opportunities' to refresh lead lists, or 'v1:request:properties' to refresh listings. Returns the number of cleared entries in each tier.

Retrieve audit / change-log entries for a single CRM record (Qobrix LogAudit). Calls GET /api/v2/{resource}/{id}/changes. Each row has original (before), changed (after), user_id (who), timestamp, type (create/update/delete). IMPORTANT: LogAudit.source is the resource name (e.g. 'Opportunities'), NOT the lead marketing source field. Field-level before/after for e.g. lead source are keys inside original and changed objects. For a filtered timeline of one field use qobrix_field_change_history.

Search tenant-wide audit log for a CRM resource (Qobrix LogAudit). Calls GET /api/v2/{resource}/changes. Use to find who changed what across all records. Search examples: timestamp >= DAYS_AGO(30), user_id == "", primary_key == "". Pair with qobrix_top_field_changers for leaderboards or qobrix_field_change_history for one record.

Build a chronological timeline of edits to one field on one CRM record. Paginates GET /{resource}/{id}/changes and filters rows where the field appears in original or changed. Returns [{timestamp, user_id, user_name?, type, before, after}] sorted oldest-first. Use for: 'who changed source on this opportunity and when?'

Leaderboard: which users most often edited a given field (tenant-wide audit scan). Paginates GET /{resource}/changes, counts rows where field appears in changed, groups by user_id. Returns [{user_id, user_name?, change_count, latest_change_at, sample_record_ids}]. Use for: 'who rewrites lead source to direct most often in the last 6 months?'

Start interactive Qobrix sign-in (Mode C only). When not connected, returns a Sign In to Qobrix link (or native URL elicitation) for the user to complete login + 2FA + consent. When already connected, reports the current identity. In Mode A/B this is a no-op — credentials come from env / request headers. Mode C uses a per-user encrypted session vault keyed by the chat identity (X-Chat-Platform / X-Chat-User-Id). Deliver the Sign In link only to that individual — never post it into a shared/group thread.

Sign out of Qobrix (Mode C only). Fully revokes the current user's session: calls the Authorization Server /disconnect (deletes the minted Qobrix API key and clears AS tokens/vault), then clears this user's local encrypted session vault. Other users' vaults on this MCP process are not affected. In Mode A/B there is no interactive session to clear.

Return the current Qobrix user profile, capabilities, and portals (GET /api/v2/session/). In Mode C with no session for this chat identity, surfaces a Sign In link so the user can authenticate first. Also includes the OAuth subject when available. Use to confirm which CRM identity the agent is acting as for this user.