Skip to main content
Glama
gca-global

Qobrix CRM MCP Server

by gca-global

qobrix_list_properties

List properties from Qobrix CRM with filtering, sorting, pagination, and expansion options. Use to browse active inventory, track listing status changes, or audit property records.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (default 1). Used on the fast path (no boost). Ignored when boost is set (ranking returns a single top-N page).
sortNoSort by field name (maps to Qobrix OpenAPI sort[]). Prefix with - for descending. Comma-separated for multi-key (e.g. '-list_selling_price_amount,-created'). Examples: '-created' (newest first), 'name' (alphabetical), '-list_selling_price_amount' (highest list price first).
limitNoHow many results to return (1-100, default 10). With boost: top-N after ranking. Without boost: page size. Raise when the user wants more options; keep low to avoid context overload.
mediaNoInclude inline media (photos, floor plans, thumbnails) on each row. Default false. Each media-rich property can add 5-20 KB; only set true when the caller needs media URLs. For media alone use qobrix_list_media(related_model='Properties', related_id=<uuid>).
expandNoExpand FK references into full nested objects (developer, project, seller, location, etc.). Default false. With expand=false each FK is just a UUID string — much smaller payload. Prefer include[] for surgical expansion of specific associations.
fieldsNoLimit response to specific fields only (partial response). Reduces payload size. Example: ['id','name','status','list_selling_price_amount']. Omit to get all fields.
searchNoHard-filter Qobrix search expression (server-side precision). Operators: == != <> < > <= >=, contains, starts with, ends with, in [...], not in, ranges in a..b, and/or/not. Functions: DISTANCE_FROM, IN_POLYGON, TRANSLATED, MIN/MAX, DAYS_AGO(n), MONTHS_AGO(n), DAYS_FROM_NOW(n). Shortcuts: NOW, TODAY, THIS_WEEK, LAST_MONTH, THIS_YEAR, CURRENT_USER. Strings double-quoted; booleans true/false; association paths e.g. SalespersonUsers.Contacts.country. Example: status == "available" and sale_rent == "for_sale" and list_selling_price_amount <= 500000. For the full grammar + field cheatsheets call qobrix_search_dsl_help. For enum values call qobrix_get_field_options; for all fields call qobrix_get_schema.
includeNoAssociations to expand. Verified options: PropertyTypes, PropertySubtypes, Agents, Opportunities, PropertyViewings, Translations, SalespersonUsers, CreatedByUsers, ModifiedByUsers, LocationLocations, AgentAgents, SellerContacts, ProjectProjects
Behavior5/5

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

No annotations are provided, so the description fully carries the burden. It discloses payload defaults (expand=false, media=false, default limit 10, max 100), explains that FKs come back as UUIDs and media is not inlined, and maps RESO statuses to internal values. This adds rich behavioral context beyond the schema and covers what an agent needs to know about the response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: purpose, return shape, status mapping, key fields, workflow recipes, payload defaults, and parameter hints are all organized and front-loaded. No fluff; only high-value information is present.

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?

Given 8 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers return structure, field selection, status mapping, workflow recipes, and points to additional resources (qobrix_search_dsl_help, qobrix_get_schema) for deeper needs. It is a model of contextual completeness.

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 already covers 100% of parameters, but the description adds significant practical value: it provides search expression examples, sort syntax examples, include[] options, and guidance on when to set media/expand. It also explains the interaction between page and boost (though boost is not a parameter in this schema, the context is still useful). This goes far beyond the baseline schema descriptions.

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 description clearly states 'List properties (RESO Property resource) from Qobrix CRM' and specifies its role as the 'Core tool for the Listing Lifecycle'. It distinguishes from siblings by explicitly suggesting qobrix_search_properties for buyer-property match and qobrix_list_media for media, so the verb+resource+scope is specific and well-differentiated.

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

Usage Guidelines5/5

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

Provides explicit when-to-use context: 'use to browse active inventory, track status changes, or audit listings'. Offers concrete workflow recipes (e.g., active inventory via search, recent listings via sort) and explicitly names alternatives (qobrix_search_properties for free-language demand, qobrix_list_media for media-only needs), giving clear exclusions and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gca-global/qobrix-crm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server