Red Hat Lightspeed MCP

Official

Overview Schema Source Related Servers Discussions Admin

inventory__list_workspaces

Read-only

List inventory workspaces with id, name, host count, and ungrouped status. Use to show or retrieve workspaces and filter by name or type.

Instructions

List Inventory workspaces (console UI name for Inventory groups).

Call this tool whenever the user asks to list, show, or get workspaces. Do not invent workspace names such as Ungrouped Hosts without calling this API. Each result includes id, name, ungrouped, and host_count. Prefer workspace IDs in later calls; names can be duplicated.

Required permission: inventory:groups:read (Workspace viewer).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Filter workspaces by name (partial match).
`page`	No	Page number to return.
`order_by`	No	Field to sort by ('name', 'host_count', 'updated').
`per_page`	No	Number of workspaces to return per page. ALWAYS use the default value of 10 for the first call. Only increase this value if the user explicitly asks to see more workspaces at once.
`order_how`	No	Sort direction ('ASC' or 'DESC').	ASC
`group_type`	No	Workspace type to return: 'all' (default; includes Ungrouped Hosts and user workspaces), 'standard' (user-created only), or 'ungrouped-hosts'.	all

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.0.16Sep 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The readOnlyHint annotation already signals a safe read operation. The description adds value by specifying the required permission (inventory:groups:read), noting that names can be duplicated (so IDs are preferred), and specifying the returned fields. No contradictions with the annotation.

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 description contains six sentences, but each adds information: purpose, when to call, a warning, output fields, a best-practice note, and a permission requirement. It is front-loaded with the primary purpose and remains reasonably concise.

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 is a read-only list operation with all parameters optional and annotated as read-only, the description covers when to use it, permission, output structure, and potential pitfalls (duplicate names). It is complete for an agent to invoke it correctly without further investigation.

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

Parameters3/5

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

The input schema already provides full descriptions for all 6 parameters (100% coverage), so the baseline for added value is 3. The description's note to prefer workspace IDs in later calls is general advice, not parameter-specific detail, so it doesn't elevate the score further.

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 opens with a precise verb and resource: 'List Inventory workspaces', and clarifies the naming ('console UI name for Inventory groups'). It also states the trigger condition ('Call this tool whenever the user asks to list, show, or get workspaces') which distinguishes it from more specific tools like inventory__get_workspace. The purpose is immediately understandable.

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?

Explicit usage guidance is given: 'Call this tool whenever the user asks to list, show, or get workspaces.' It also warns against inventing workspace names without calling the API and specifies a required permission. While it doesn't contrast with a single-workspace tool, the instruction is clear and actionable.

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

Deploy Server