AskRentAI

List Property Groups

list_property_groups

Read-onlyIdempotent

List the Property Groups saved inside Rent Manager (Properties → Property Groups), with each group's member properties.

These are RM-native, user-created groups — distinct from the dash-prefix portfolios returned by list_portfolios. Pass embeds="" to skip resolving member properties for a faster, names-only listing.

``location`` (optional): a Rent Manager Location ID, a comma-separated
list, or ``"all"`` to run across every Location on this connection (see
``list_locations``). Blank = all Locations if the connection has several,
else its only Location. Output is labelled per Location; a Location that
can't be reached is listed as skipped. IDs (property, tenant, ...) belong
to one Location, so pass that Location when you filter by one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_property_groups"
  }
}

Input Schema

Name	Required	Description	Default
`embeds`	No		Properties
`location`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / location

Added value: +{
+  "default": "",
+  "title": "Location",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile needs no restating. The description adds real behavioral context beyond that: output is labelled per Location, an unreachable Location is listed as skipped, and embeds="" trades member resolution for speed. It stops short of describing pagination or error behavior.

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?

Front-loads the core purpose and sibling distinction in the first sentence, then layers the embeds tip and location semantics. The location paragraph is dense but every clause carries actionable meaning, with no filler.

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?

An output schema exists, so return-value details are not required. Both parameters are meaningfully documented, the sibling relationship is explicit, and edge behavior (skipped Locations) is noted, leaving little an agent would need to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the params, and it largely does: location is documented (optional, single ID, comma-separated list, or "all", blank meaning, per-Location labeling, skipped Locations) and embeds is described by effect. Only minor gaps remain, such as embeds' default value and accepted values.

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 and resource ('List the Property Groups saved inside Rent Manager') and immediately names the sibling it is distinct from, noting these are RM-native user-created groups rather than the dash-prefix portfolios returned by list_portfolios. An agent can differentiate it from sibling list tools without opening any schema.

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?

Gives a concrete operational condition: pass embeds="" to skip resolving member properties for a faster, names-only listing, and explains the location scoping (comma-separated, "all", blank default, and the rule that IDs belong to one Location). It covers the alternative (list_portfolios) but does not state explicit when-not-to-use conditions, so it falls just short of 5.

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

All AskRentAI 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?