Skip to main content
Glama

endpoint_show

Read-onlyIdempotent

Show Port OS devices with their supported controls.

To show a device, always call this tool: the widget it opens is the device's UI, so never render a second card, map or controls for it; answer in a sentence or two.

Uses the same selection, expansion and pagination arguments as endpoint_query. A single matching device opens its full view with now playing, transport, volume and other controls; several matches open only a list of names to choose from, so pass one full endpoint ID (or a query matching one device) to control a device. Showing a device does not start live video or send a control command.

Pass primary to choose which card leads, one of the device's card ids (every result lists them as cardIds; an unknown id is rejected with the available ones). The device's usual card and every other card stay behind the details toggle. Examples: "what's the battery on the vacuum" -> primary battery; "turn the thermostat fan on" -> primary fan; "how open are the blinds" -> primary closure; "show me the camera on the roborock" -> primary camera. "where is my phone" or "show its location" -> primary location; "show the roborock's map" or "pick a room to clean" -> primary house-map. Every result already includes the cached readings of the cards it lists (cardIds), so you can answer without a second call; pass expand to choose different capabilities. primary refreshes that card's readings from the device, so the answer is current. Always state the value in words: a FRESH reading is current; a STALE reading is the last known value, so say it is last known and give its age.

Input Schema

NameRequiredDescriptionDefault
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: {"name": {"like": "living"}, "type": {"in": ["LIGHT", "SWITCH"]}}. 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 endpoint ID; name (text) endpoint name; type (text) effective endpoint type, including customer overrides, such as LIGHT, SWITCH, PLUG or ROBOT_VACUUM; manufacturer (text) manufacturer name; model (text) model name; ownerId (text, eq only at the top level) principal whose endpoints to list; defaults to the caller; interfaces (list) full capability interface namespaces; messages (list) full message IDs the endpoint accepts; controllableGroups (list) IDs of groups the endpoint can act on, such as rooms a vacuum can clean (needs group:read).
expandNoSelect observations to add to each device result, for example ["power", "connectivity"] or ["battery"]. Use capability names or full namespaces declared by the device. This reads attributes; it does not send commands or broaden the device search. Short names use port1/systems/zero/capability-interfaces. endpoint_show already includes cached readings for the cards it lists; expand replaces that selection.
primaryNoThe card to lead with, one of the device's card ids (shown as cardIds in the result), for example battery, fan, closure, thermostat, camera or remote; house-map for a vacuum's map or room picking (never draw your own map). Needs endpointId. Every other card stays behind the details toggle.
nextTokenNoOpaque cursor returned by a previous endpoint_query call.
enablementNoFilter by ENABLED (default), DISABLED, or * for both. This filter is preserved by pagination.ENABLED
endpointIdNoReturn one endpoint by its full Port OS identifier. Cannot be combined with other filters or pagination. Results advertise its declared command and outbound message IDs.
maxResultsNoMaximum number of results (default 10, maximum 100).
forceDeviceAttributeQueryNoRead selected attributes from devices instead of cache. Requires nonempty expand. Failed reads remain unavailable.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/no-destruction, yet the description adds substantive behavior: single match vs multi-match results differ, results carry cached card readings so no second call is needed, primary refreshes that card's readings, unknown card ids are rejected with the valid list, and FRESH vs STALE readings must be reported with age. These are exactly the traits an agent cannot infer from the schema.

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?

Purpose and the 'never render a second card' rule are front-loaded, then argument guidance, then fresh/stale reporting. Every paragraph carries load, but sentences are long and multi-clause, and the primary examples block is dense enough to slow scanning.

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?

For an 8-parameter, nested-schema, output-schema-bearing read tool, the description covers everything that matters operationally: multi-match degradation, cached vs refreshed readings, card selection, and the UI/rendering constraint. Return values are already in the output schema, so nothing is missing.

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 100%, so baseline is 3; the description earns above that by adding decision-level meaning for primary (which card ids exist, what each is for, requires endpointId, unknown ids rejected), expand (replaces the default cached selection, short names use capability-interfaces), and the single-device requirement for query. nextToken, enablement and maxResults are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Show Port OS devices with their supported controls', and clarifies it opens the device's canonical widget UI. It distinguishes itself from endpoint_query (shares the same selection/expansion/pagination arguments) and from control ('Showing a device does not start live video or send a control command'), though the query-vs-show split is implied rather than stated outright.

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 explicit operating instructions: always call this tool to show a device, never render a second card or map, pass one full endpoint ID (or a query matching one device) to get controls, otherwise you get only a name list. It maps common user intents to primary card ids via worked examples. It stops short of saying when endpoint_query is the better choice instead.

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