Skip to main content
Glama

group_query

Read-onlyIdempotent

Find rooms, floors, zones, homes and device groups, with their members and supported controls.

Returns canonical IDs, names, etags, spatial roles, parent paths, children, member devices, controllers and providers. Call it without arguments first to load full context and follow every paginationContext.nextToken; filter with query only when the account is large.

Controllers are the endpoints that can act on the group, with the message IDs that accept it: to clean a room, call control on the controller endpoint with one of those message IDs and payload {"groupIds": []}.

Messages are message IDs the group itself accepts: send one with control, using the group ID as id. Port OS uses a native group only when it respects effective membership; otherwise it dispatches equivalent actions to individual members or returns unsupported. Disabled provider routes are never control candidates. Room cleaning is not a group message; use the controller as above. If two groups match a spoken room name, ask the user which one, naming each group's parentPath.

Pass id to read one group; a merged group ID resolves to the surviving group and reports redirectedFrom.

To show a room map or let someone pick rooms, call endpoint_show on the vacuum (controller) with primary house-map; never draw a map yourself from spatial geometry.

Expand accepts capability names as in endpoint_query (for example ["speaker","media-player"]); forceDeviceAttributeQuery refreshes those observations. Read route attribute status before trusting a value: omitted or failed fresh values are unavailable.

Each route's membershipComplete is provider-declared: false means incomplete or unreported, and absent means unknown. members lists resolved endpoints, so an empty list does not prove a provider group has no members.

Disabled groups are hidden unless enablement is DISABLED or *; they cannot be targeted, and group_manage SET_ENABLEMENT enables them again. Copy group IDs and etags verbatim into control and group_manage.

Input Schema

NameRequiredDescriptionDefault
idNoReturn one group by its full group ID. Cannot be combined with query, maxResults or nextToken.
queryNoOptional field-first filter. Omit it to load full context; filter only when the account is large. Each key is a field or a combinator, and all keys of one object must match: {"role": {"eq": "ROOM"}, "name": {"like": "kitchen"}}. Combinators: {"and": [query, ...]}, {"or": [query, ...]}, {"not": query}. Text operators: eq (exact), in (any of a list), like (case-insensitive substring), lt and gt (lexical order). List operators: has (contains the exact value), like (some value contains the substring, case-insensitive). Fields: id (text) full group ID; name (text) group name; role (text) spatial role a provider declares: HOME, FLOOR, ROOM or ZONE; parentGroupId (text) ID of the containing group; ownerId (text, eq only at the top level) principal whose groups to list; defaults to the caller; children (list) IDs of contained groups; members (list) member endpoint IDs; controllers (list) IDs of endpoints that can act on the group, such as a robot that cleans the room; messages (list) full message IDs the group itself accepts; providers (list) names of the plugins that report the group.
expandNoSelect declared capabilities whose route observations to return, for example ["speaker", "media-player"]. Requires id. This adds state readings to the selected group; it does not expand group membership or send commands. Expanding spatial returns raw room geometry for reading only. To show a map or let someone pick rooms, call endpoint_show on the vacuum with primary house-map; never draw one yourself.
nextTokenNoOpaque cursor returned by a previous group_query call with the same query and maxResults.
enablementNoFilter by ENABLED (default), DISABLED, or * for both. This filter is preserved by pagination; id reads ignore it.ENABLED
maxResultsNoMaximum number of groups (default 25, maximum 100).
forceDeviceAttributeQueryNoRequires id and nonempty expand; refresh provider state before returning route observations.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish readOnly, idempotent, non-destructive behavior, and the description adds substantial operational context: pagination behavior, merged-ID redirects, controller versus message semantics, disabled-group visibility, and membershipComplete caveats. No behavior contradicts the annotations.

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?

The purpose is front-loaded and the description is organized by operational concern. It is dense and lengthy, but most sentences carry useful guidance for a complex query tool, with only minor repetition of schema details.

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 the tool's complexity, rich schema, annotations, and output schema, the description covers the important call patterns, caveats, and sibling handoffs. An agent has enough information to invoke group_query correctly without opening other definitions first.

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 coverage is 100%, but the description still adds meaningful semantics beyond the schema, including that id reads one group, merged IDs report redirectedFrom, expand requires id, forceDeviceAttributeQuery refreshes observations, and enablement survives pagination. These details help an agent choose parameters correctly.

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?

Starts with a specific verb and resource list: find rooms, floors, zones, homes, and device groups, plus their members and controls. It distinguishes the tool from group_manage and control by explaining query versus management/action semantics.

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?

Explicitly says to call without arguments first to load full context, follow pagination tokens, and filter with query only when the account is large. It also routes related needs to siblings, such as endpoint_show for maps and group_manage SET_ENABLEMENT for disabled groups.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources