General dashboard¶

Goal: Produce a read-only Rafay overview using rafay_list (and optional rafay_describe). Do not use rafay_get or kubectl unless the user asks.

Hard rules

Never show cluster **status** in the user-visible output. Healthy vs Unhealthy use **health** only.
User-visible deliverable: consecutive Markdown tables only (see Report format)—no extra headings, prose, bullets, or footnotes in the reply.
Omit usernames and emails unless the user asks.

Instructions¶

Step 1 — Describe resource shapes (recommended)¶

Call rafay_describe with resource_type as needed (e.g. cluster, and optionally user, sso_user, workload, namespace, blueprint) to confirm field names, pagination defaults, and list vs summary behavior.

Step 2 — List cluster summary (paginated)¶

Org-wide: omit project-name.
Single project: set project-name to that project.

# MCP: rafay_list
resource_type: cluster
summary: true
project-name: "<optional>"
limit: <number>
offset: <number>

Page with limit / offset until the last page has fewer than limit items or you can reconcile counts to count in the response; if not, set cluster_pages_complete to no in Context and note gaps in notes.

Step 3 — Optional project lists (only when `project-name` is set)¶

For each resource, paginate the same way as clusters (limit / offset).

`resource_type`	Purpose
`workload`	Condition tallies in one table; `status.published` summary in a second table (project scope).
`namespace`	Same as workload for conditions vs published (project scope).
`blueprint`	Catalog tallies (project scope).

Call rafay_list once per row above with the same project-name, limit, and offset pagination:

# MCP: rafay_list (example: workload — repeat for namespace, blueprint)
resource_type: workload
project-name: "<name>"
limit: <number>
offset: <number>

Step 4 — Local users and SSO users (paginated, org-wide only)¶

Skip when project-name is set.

# MCP: rafay_list — user
resource_type: user
limit: <number>
offset: <number>

# MCP: rafay_list — sso_user
resource_type: sso_user
limit: <number>
offset: <number>

Step 5 — Emit the report¶

Output only the tables defined below, in order (Report format). Blank lines between tables are allowed. Apply row-level rules in Table specifications.

Report format¶

Emit tables in this order. Omit a table if it has no rows, except Context (always emit).

Order	Table
1	Context — Key
2	By project — Project
3	By cluster type — Cluster type
4	By blueprint (clusters) — Blueprint
5	Project workload conditions — conditionType
6	Project workload published — Published
7	Project namespace conditions — conditionType
8	Project namespace published — Published
9	Project blueprint catalog — type
10	Project blueprint catalog — versionState
11	Project blueprint catalog — Blueprint
12	Users — Kind

Table specifications¶

1. Context — Key Value¶

Emit one row per key (values plain text; use **-** for empty **notes**):

Key	Value
`scope`	`org-wide` or `project:<name>`
`clusters_represented`	Integer count of cluster summary rows feeding the project, cluster-type, and blueprint tables
`cluster_pages_complete`	`yes` if cluster summary paging finished; else `no`
`notes`	`-` or one short cell (errors, wrong org, gaps not covered elsewhere)

If scope is org-wide, also emit:

Key	Value
`user_pages_complete`	`yes` / `no` after paging `user`
`sso_pages_complete`	`yes` / `no`
`sso_active_model`	`per-item` (SSO exposes `active`); `inferred-all-active` (`active` omitted on all → SSO Active = Count, Inactive = 0); `mixed` (some `active`, some omit → tally booleans, missing → active)

If scope is project:<name>, also emit:

Key	Value
`workloads_represented`	Integer count of workload list items used for the workload condition and published tables
`workload_pages_complete`	`yes` / `no`
`namespaces_represented`	Integer count of namespace list items used for the namespace condition and published tables
`namespace_pages_complete`	`yes` / `no`
`blueprints_represented`	Integer count of blueprint list items
`blueprint_pages_complete`	`yes` / `no`

If a list fails, record it in **notes** and omit tables with no rows; always emit Context.

2. By project¶

Columns: Project, Count, Healthy, Unhealthy, Nodes, Active nodes, Gaps
Source: Cluster summary list (same as §3–§4).

Project column and merging¶

Use the Project field on each summary row (confirm the name). If missing, use **(unassigned)**.
Merge rows that share the same tuple: (Count, Healthy, Unhealthy, Nodes, Active nodes, Gaps).
Merged Project cell:
≤ 3 project names: list them, **;** -separated, sorted A–Z.
> 3 names: use **N projects (C clusters each)** where N is the number of projects and C is clusters per project in that tuple.

Health (never use cluster `status` here)¶

Map only from **health. **Do not add an “Unknown” column.
Healthy: values you treat as good / connected (e.g. **HEALTHY**).
Unhealthy: everything else (e.g. **DISCONNECTED**, **UNHEALTHY**, **DEGRADED**, empty, missing).
Per merged row: Healthy + Unhealthy = Count.
If any value was ambiguous, say so in Context **notes**; counts stay binary.

Nodes¶

Nodes: for each cluster, sum **len(cluster.status.nodes)** (or payload equivalent). If not a list / missing → 0.

Active nodes¶

Active nodes: for each cluster, add numeric **activeNodeCount** (or equivalent). Missing or not a number → 0.

Gaps¶

Per merged row: count clusters where the nodes field is not a usable list or **activeNodeCount** is missing / not a number (at most once per cluster).

Sort order¶

Count ↓
Unhealthy ↓
Nodes ↓
Active nodes ↓

3. By cluster type¶

Columns: Cluster type, Count
Source: Same cluster summary list as §2.

Empty or missing type → **(none)**.
Sort: Count ↓, then cluster type alphabetically ↑.
Sum of Count should equal **clusters_represented** when **cluster_pages_complete** is **yes**.

4. By blueprint (clusters)¶

Columns: Blueprint, Count, Folded
Source: Cluster summary (e.g. **cluster_blueprint**). Missing → **(none)**.

Folding (distinct blueprint names)

Situation	What to emit
≤ 25 names	One row per name. Folded = `0` on every row. No `Other`.
> 25 names	Top 24 rows by count, then one `Other` row: Count = sum of the rest, Folded = number of names folded into `Other`. Other rows have Folded = `0`.

Sort: Count ↓, blueprint name ↑.

5. Project workload conditions¶

Columns: conditionType, conditionMessage, Count
When: scope is **project:<name>** and the workload list succeeded.

For each **items[]** row, read **status.conditionType** and **status.conditionMessage** (missing → **(none)** in that column).
Tally counts per distinct (conditionType, conditionMessage) pair only — do not include **status.published** in this table.
Sort: Count ↓, conditionType ↑, conditionMessage ↑.

6. Project workload published¶

Columns: Published, Count
When: scope is **project:<name>** and the workload list succeeded.

Tally **status.published** across the same paginated **items[]** as §5.
Emit exactly three rows in this fixed Published order: **true**, **false**, **unknown**.
unknown = items where **status.published** is missing or not a boolean — note briefly in Context **notes** if non-zero.
Count = integer tally for each bucket.

When **workload_pages_complete** is **yes**, the three row counts must sum to **workloads_represented**; otherwise note any mismatch in Context **notes**.

7. Project namespace conditions¶

Columns: conditionType, conditionMessage, Count
When: scope is **project:<name>** and the namespace list succeeded.

Same condition-only rules as §5 (tally (conditionType, conditionMessage) from **status.conditionType** and **status.conditionMessage**), using each namespace **items[].status** — do not include **status.published** in this table.

8. Project namespace published¶

Columns: Published, Count
When: scope is **project:<name>** and the namespace list succeeded.

Same rules as §6 for **status.published** on namespace **items[]** (fixed Published order: **true**, **false**, **unknown**).
When **namespace_pages_complete** is **yes**, the three row counts must sum to **namespaces_represented**; otherwise note any mismatch in Context **notes**.

9. Project blueprint catalog (by type)¶

Columns: type, Count
When: scope is **project:<name>** and the blueprint list succeeded.

Tally **spec.type** (missing → **(none)**).
Sort: Count ↓, type ↑.

10. Project blueprint catalog (by versionState)¶

Columns: versionState, Count
When: scope is **project:<name>** and the blueprint list succeeded.

Tally **spec.versionState** (missing → **(none)**).
Sort: Count ↓, versionState ↑.

11. Project blueprint catalog (detail rows)¶

Columns: Blueprint, Version, Type, State, Clusters, Folded
When: scope is **project:<name>** and the blueprint list succeeded.

One row per catalog entry¶

One row per distinct **metadata.name**.
Version = **spec.version, **Type = **spec.type, **State = **spec.versionState**.

Clusters column¶

Count clusters in this project whose cluster-summary **cluster_blueprint** (same field as §4; missing → **(none)**) equals this row’s **metadata.name**.
Use the same paginated cluster summary as §2–§4. Do not call **rafay_get** per blueprint.
No matching clusters → Clusters = **0**.

Folding (distinct `metadata.name` values)¶

Situation	What to emit
≤ 25 names	One row per name. Folded = `0` everywhere.
> 25 names	First 24 rows in sort order (below), then one `Other` row: Folded = count of remaining names; Version, Type, State = `-`; Clusters = sum of Clusters for all folded names (same `cluster_blueprint` tally as above).

Sort¶

Primary: Blueprint (metadata.name) ↑.

12. Users¶

Columns: Kind, Count, Active, Inactive
When: scope is **org-wide** only.

Kind rows (fixed order)¶

Local
SSO
Total — sums of Local + SSO per numeric column (do not add an “Unknown” column).

Local users¶

Use **accounts[].active** (boolean): Active vs Inactive.
If **active** is missing → count as Inactive; if any are missing, add a short hint in Context **notes**.

SSO users¶

Tally Active / Inactive only, following Context **sso_active_model**: **per-item**, **inferred-all-active**, or **mixed** (no third bucket).

Counts and paging¶

Prefer API **count** when it is trustworthy; otherwise page and tally.
Reflect honesty in **user_pages_complete** and **sso_pages_complete**.

Tools and resource types reference¶

Tool	When to use
`rafay_describe`	Confirm supported `resource_type` values, fields, and pagination defaults before listing.
`rafay_list`	All data for this skill; use `summary: true` only for `resource_type: cluster`.

`resource_type`	Role in this skill
`cluster`	Summary list (`summary: true`); drives project, cluster type, blueprint, and blueprint-cluster counts.
`user`	Org-wide dashboards only: local user accounts; Active/Inactive from `accounts[].active`.
`sso_user`	Org-wide dashboards only: SSO users; Active/Inactive per `sso_active_model`.
`workload`	Project scope only; §5 conditions, §6 `status.published` summary.
`namespace`	Project scope only; §7 conditions, §8 `status.published` summary.
`blueprint`	Project scope only; §9–§11 catalog tallies and per-blueprint rows.

Examples¶

Ask	Do
Org-wide dashboard	`rafay_list` clusters with `summary: true`, no `project-name`; then `user` and `sso_user`.
Dashboard for project `prod`	`rafay_list` clusters with `summary: true` and `project-name: prod`, plus paginated `workload`, `namespace`, and `blueprint`; do not list `user` / `sso_user` or emit the Users table.
“Is cluster X healthy?”	Do not expand this skill; use diagnose-cluster-health with `cluster_name` and `project_name`.

Performance notes¶

Complete paging before trusting aggregates: partial cluster (or org-wide user) pages skew counts—record incompleteness in Context (*_pages_complete, notes). The same applies to workload/namespace publish counts and condition tallies: they must cover the same fully paged **items[]** set.
Quality over speed: prefer verified page completion and honest Context flags over guessing totals.

Troubleshooting¶

Symptom	What to check
Lists fail or return unexpected scope	MCP project resolution (e.g. `RAFAY_PROJECT` or `project-name` on calls per server behavior).
Cluster count mismatch	`cluster_pages_complete: no` and a short `notes` entry; do not invent totals.
Ambiguous SSO `active`	Set `sso_active_model` in Context and follow §12 rules.
Wrong org / empty data	Note in `notes`; do not fabricate IDs or kubectl/`rafay_get` results.

Guardrails¶

Do not imply **rafay_get** or kubectl unless you ran them. Do not invent IDs; wrong org → **notes**.