Nobl9 application (1.178.0)
· 2 min read
We've just released Nobl9 1.178.0! Release highlights:
keep up to date!
Keep tracking the latest changes in Nobl9 and subscribe to our Application RNs RSS Feed new
fixed
Release details
new Metadata-only list tools in Nobl9 MCP server
The Nobl9 MCP server now includes new list tools for lightweight object discovery.
These tools return object metadata only, so AI clients can find and select Nobl9 resources without fetching complete object definitions, status payloads, or detailed configuration.
Use these tools when you need quick discovery across the main Nobl9 object types before opening a specific resource for deeper analysis.
| Area | New list tools |
|---|---|
| SLOs and reliability data | listSLOs, listAlerts, listAnnotations, listBudgetAdjustments |
| Organization structure | listProjects, listServices |
| Data and integrations | listAgents, listDirects, listDataExports |
| Alerting configuration | listAlertMethods, listAlertPolicies, listAlertSilences |
| Reports | listReports |
| Access control | listUserGroups, listOrganizationRoleBindings, listProjectRoleBindings |
The listAlerts tool also provides dedicated filters for alert-focused workflows:
- SLO, service, alert policy, and objective names
- Objective values
- Triggered or resolved state
- Time range
Use metadata-only MCP list tools to narrow down the right Nobl9 object first, then request full details only for the resources you want to inspect.
fixed Stability improvements
This release includes fixes that improve reliability in high-volume views and edge-case API flows.
| Area | What changed |
|---|---|
| Status Page preview | Large search results in the preview no longer cause browser crashes. The preview now mounts heavy component cards only as they approach the viewport and uses a single tooltip per uptime strip, reducing memory usage while preserving the existing layout and tooltip behavior. |
| Reliability Roll-up reports | Reports created through internal APIs without filter definitions now load correctly instead of returning HTTP 500 errors. Missing or null filters are normalized during create, update, and read paths, including older stored reports. |
| Service filters | Canceled POST /api/search/services/filters requests no longer produce spurious HTTP 500 responses or critical-level server logs. Canceled requests are now treated as expected client-aborted requests and logged at info level. |