Apache Flink Plugin

TLS settings location

TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.

Basic accessibility observation

Resource overviews show accessible, inaccessible, or access unknown independently of metric sources. Successful access does not attest healthy membership, replication, partitions, or workloads; use domain diagnostics and alerts for those conditions. Existing liveness/readiness fields are domain evidence and do not drive the single core-owned access alarm. Unknown observations do not resolve firing incidents.

TLS

Enable tls_insecure_skip_verify in connection settings to retain TLS encryption without verifying the server certificate. It defaults to false and does not require a CA when enabled. Mutual TLS still requires a client certificate and key when requested by the server. Keep CA-based verification enabled when server identity must be authenticated.

Capacity stays in one four-card row. Job/task workload and JVM comparisons use two columns, and the four recovery trends share one row. Labels and series are retained. Existing saved layouts and query definitions remain unchanged.

Counts are shown as integers, while scaled millisecond durations retain useful fractional digits. Percent gauges use a 0–100 range. Task throughput summaries add task series, while pressure, latency, CPU, and heap summaries show the worst series. A missing metric or ratio operand remains unknown.

Eligible single-metric stat panels show a lower sparkline. The current value keeps its instant query; a separate history request asks for at most 160 samples per series per queried interval. Categorical states and compound calculations are excluded. A history failure preserves the current value and displays “Trend unavailable”.

The Apache Flink plugin registers a Flink cluster as a Konduo resource. It uses the JobManager REST API and a linked Prometheus metric source to expose job execution, checkpoints, throughput, backpressure, and JVM state.

Highlights

• Reads current cluster and active-job state from the JobManager REST API.
• Inventories JobManager, TaskManagers, jobs, cluster topology, and the observed Flink software version from bounded REST responses.
• Provides administrator-only, dry-run-first cancel, savepoint, stop-with-savepoint, and capability-gated manual rescale operations for existing jobs.
• Provides 19 Flink logical metrics through a Prometheus mapping pack.
• Uses 16 default panels for cluster capacity, throughput, checkpoints, and JVM resources.
• Separates current state from bounded historical metric evidence.
• Provides managed alert rules for backpressure, task slots, checkpoints, job restarts, and JVM pressure.

Before Registration

1. Prepare a JobManager REST URL that is reachable from the Konduo backend. The default is http://localhost:8081, but in a container deployment localhost can mean the Konduo backend container itself.
2. If the REST API requires Bearer authentication, prepare an API token. The token is stored as sensitive configuration and is used only in the Authorization header of diagnostic requests.
3. Enable the Prometheus reporter on the JobManager and every TaskManager, then confirm that Prometheus scrapes those endpoints.
4. Link the target Prometheus resource to the Flink resource as its metric source.
5. If metrics.scope.* or the reporter prefix is customized, prepare mapping rules for that environment instead of relying on the default pack.

Connection Settings

Field	Required	Default	Description
endpoint	yes	http://localhost:8081	Base URL of the JobManager REST API
api_token	no	none	Bearer token sent with REST API requests
Metric-source link	for metrics	none	prometheus-plugin resource that executes time-series queries

A URL that works in a browser can still be unreachable from the Konduo backend. For container deployments, verify service DNS, published ports, and firewall rules from the backend network.

Registration And Validation

1. Enter the endpoint and, when required, api_token, then run Connection Test.
2. Save the resource and confirm the Flink version, registered TaskManagers, and total/available task slots in cluster diagnostics.
3. In Prometheus, confirm that the JobManager and every TaskManager target is UP.
4. Link that Prometheus resource to Flink as its metric source.
5. Even with no running job, confirm that cluster and JVM panels contain current samples.
6. With a test job, validate job/task labels on input/output rate, busy time, backpressure, and checkpoint panels.
7. Confirm that nine managed alerts are registered. Enable checkpoint-age and checkpoint-duration rules only after defining workload-specific baselines.
8. Open Operations, verify the current job inventory, and run a dry-run before granting administrators permission to execute job changes.

REST connectivity and Prometheus collection validate separate paths. A healthy REST diagnosis does not prevent empty dashboards or time-window diagnostics when reporters or metric linkage are misconfigured.

Dashboard And Metrics

The dashboard keeps 16 stable panels and separates four operator tasks into Overview (8 capacity and workload panels), Recovery (4), and Resources (4) views:

• Cluster overview: registered TaskManagers, running jobs, total and available task slots, and slot utilization
• Workload and backpressure: input/output records per second, task busy time, and backpressure
• Checkpoints and recovery: checkpoint duration, age, failures, and job restarts
• JVM resources: JobManager and TaskManager CPU and heap utilization

Workload charts use half the grid width so job/task legends remain readable as cardinality grows. TaskManager CPU and heap comparisons also use half width. The original job/task label scope and metric aggregation remain unchanged, and existing saved visibility, row placement, order, and size take precedence.

Slot and JVM heap ratios require a positive reported limit. Missing or nonpositive limits produce no data, and values above 100% remain visible as exporter evidence.

Job, task, and checkpoint panels can legitimately have no data when no job is running. If cluster overview and JVM panels still have data, do not classify that state as a complete metric collection failure.

The default mapping assumes the Flink Prometheus reporter's flink_ prefix and default logical scopes. If all panels or one role-specific group is empty, check the Prometheus target, actual metric names, labels, and active mapping pack in that order.

Diagnostics

The diagnostic summary combines current REST evidence with metric-evidence readiness. Detail views are split into:

• Cluster: JobManager REST reachability, registered TaskManagers, and task-slot capacity
• Jobs: active job state and failure or restart signals
• Checkpoints: the latest checkpoint outcome for active jobs
• Performance evidence: backpressure, throughput, checkpoint, and JVM logical metrics

Current diagnosis reads /overview, /jobs/overview, and /jobs/{jobid}/checkpoints within bounded timeout and response-size limits. The current REST diagnostic budget is eight seconds, each response is limited to 2 MiB, and checkpoint inspection is limited to ten active jobs.

A FAILED job is historical context and does not by itself raise a current warning. Active states such as FAILING, RESTARTING, and SUSPENDED affect the live stability result. Batch and stateless jobs may not use checkpointing, so missing checkpoint activity is not automatically a failure.

Time-window diagnosis delegates logical metric queries to the linked Prometheus resource. When the metric source is absent or cannot serve the query, the plugin reports unavailable evidence and a follow-up route instead of assuming a healthy state.

The diagnostic run action refreshes current evidence only. The plugin does not provide persistent storage for previous diagnostic results.

Inventory And Job Operations

The cluster inventory combines /overview, /taskmanagers, and /jobs/overview. The topology view records which REST route supports each cluster, JobManager, TaskManager, and job relationship. Inventory snapshots are bounded to 500 jobs and 500 TaskManagers and report truncation explicitly.

The Operations page supports these existing-job actions:

• Cancel: submits PATCH /jobs/{jobid}?mode=cancel.
• Savepoint: submits POST /jobs/{jobid}/savepoints without cancelling the job.
• Stop with savepoint: submits POST /jobs/{jobid}/stop, optionally draining sources first.
• Rescale: when /config explicitly reports features.web-rescale=true, submits PATCH /jobs/{jobid}/rescaling?parallelism=<value>.

All four actions require an administrator role and default to dry-run. Dry-run checks the job ID and current state without mutation. Execution requires the exact CANCEL <job-id>, SAVEPOINT <job-id>, STOP <job-id>, or RESCALE <job-id> TO <parallelism> phrase plus an operator reason. Request and ticket IDs are retained as audit context. For a savepoint operation, a request ID produces a stable trigger ID so an operator can retry safely while Flink retains the asynchronous request.

Rescale dry-run reports the current and requested parallelism, delta, total/free slots, estimated slot shortage, the configured maximum, and any lower/upper resource requirements reported by Flink. It rejects a no-op, non-positive or over-limit value and any non-RUNNING job. A missing, disabled, or unreadable web-rescale capability keeps the action visible but disabled; Konduo does not infer support from version text alone. Review linked alerts and diagnostics before changing capacity. This is an operator action, not an automatic scaling policy.

The operation summary distinguishes a healthy idle cluster (idle/no_jobs) from a JobManager REST connection failure. A row action that lacks permission or is unsafe for the current state stays visible with a disabled reason. Cancel is available only for active states, while savepoint and stop-with-savepoint require a RUNNING job.

View details queries JobManager REST evidence only for the selected job. It shows the overview and vertices, bounded and sanitized recent exceptions, checkpoint history, per-vertex backpressure, and subtask-to-TaskManager placement through independent routes. If a Flink version does not support one endpoint or one request fails, the other evidence remains visible and only the affected block is unavailable. Review the collection time, source REST route, freshness, and truncation metadata on every result. Raw stack traces are not shown.

Cancel and savepoint submissions are asynchronous. Accepted requests appear in the in-progress and recent operations table for the current browser session. Konduo polls operations/status for a bounded period, supports a manual status recheck, and blocks another unresolved operation with the same action and request ID. Savepoint, stop-with-savepoint, and rescale also share a per-job conflict scope, so one cannot start while another remains unresolved in the same browser session. Closing the page stops polling and clears this session-only list; use the platform audit log for durable history. If Konduo loses the connection after dispatch, it reports an unknown outcome; reconcile it before retrying instead of assuming failure.

Savepoint catalog and disposal

After Konduo confirms completion of a savepoint or stop-with-savepoint request, the Operations page adds it to a resource-scoped catalog. Each row includes the job, format, trigger and execution IDs, requester, reason, ticket, creation time, lifecycle state, purpose, retention protection, last observation, and freshness. Filter by job, creation period, format, or state. Core encrypts the raw location and the UI shows only a scheme/fingerprint mask.

The catalog is deliberately labeled Konduo-observed: Flink has no global savepoint-list endpoint, and Konduo does not browse HDFS or object storage. A fresh observation means the asynchronous Flink result was recently reconciled; it does not prove that the storage object still exists. Savepoints created outside Konduo cannot be registered manually.

Use metadata to mark an entry as an upgrade candidate, rollback candidate, or temporary artifact and to set a retention lock or retain-until time. Candidate, locked, future-retained, non-available, and already-pending entries cannot be disposed.

Disposal has a separate capability and is disabled unless operations_savepoint_disposal_enabled=true is explicitly configured. For an eligible catalog row, an administrator first runs dry-run, supplies a reason and optional ticket, disables dry-run, enters exactly DISPOSE <savepoint-id>, and performs the final confirmation. Konduo resolves the actual location from encrypted core provenance; the request cannot supply an arbitrary path. Reconcile the asynchronous result in Operations before any retry, especially after a timeout or unknown outcome.

Alert Rules

flink-alert-rules-v1 provides nine rules:

Rule	Severity	Default condition	Pending duration	Default state
Task backpressure high	warning	above 50% over 5 minutes	3 minutes	enabled
Task-slot utilization high	warning	at least 90% over 10 minutes	5 minutes	enabled
Checkpoint failures detected	critical	at least one increase over 5 minutes	1 minute	enabled
Job restarts detected	warning	at least one increase over 10 minutes	2 minutes	enabled
Latest checkpoint age high	warning	at least 900 seconds over 10 minutes	5 minutes	disabled
Checkpoint duration high	warning	at least 60 seconds over 10 minutes	5 minutes	disabled
TaskManager JVM heap high	warning	at least 85% over 5 minutes	3 minutes	enabled
JobManager JVM heap high	warning	at least 85% over 5 minutes	3 minutes	enabled
JobManager JVM CPU high	warning	at least 90% over 10 minutes	5 minutes	enabled

Checkpoint age and duration vary significantly by job interval and state size, so those two rules are disabled by default. Before enabling them, tune the thresholds using the target job's checkpoint interval, state backend, and normal duration.

An alert is an investigation starting point, not a standalone conclusion. For example, correlate a backpressure alert with downstream throughput, busy time, checkpoint duration, and TaskManager capacity.

Example Workflows

Repeated job restarts

1. Inspect the current job state and recent exception.
2. Check recent checkpoint failures and the last successful checkpoint.
3. Verify checkpoint storage latency and reachability.
4. Compare TaskManager CPU, heap, and backpressure over the same interval.
5. Adjust restart strategy or parallelism only after confirming the evidence.

Throughput degradation

1. Compare input and output record rates.
2. Locate operators with high backpressure and tasks with high busy time.
3. Check task-slot headroom and resource skew between TaskManagers.
4. Inspect sink or external dependency latency before deciding to scale.

Slow or failing checkpoints

1. Identify the affected job and its latest successful and failed checkpoints.
2. Read checkpoint duration, age, and failure increase together.
3. Compare state size, alignment delay, backpressure, and storage health.
4. Do not hide the root cause with repeated restarts.

Management Boundary

• The CE plugin provides guarded cancel, savepoint, stop-with-savepoint, and capability-gated manual rescale and explicitly enabled savepoint disposal for existing jobs. It does not deploy, submit, restart, restore, automatically rescale jobs, register external savepoints, browse storage, or run unattended retention deletion.
• Missing metrics do not prove that Flink is down. Evaluate REST state and collection state separately.
• Never expose the API token in diagnostic results, logs, or UI descriptions.
• Default alert thresholds are starting points and must be reviewed for the workload.

Troubleshooting

Symptom	Check in this order
Only REST diagnosis fails	Check endpoint, JobManager state, backend network path, and firewall
REST returns 401 or 403	Check the Bearer token value and expiry, proxy authentication forwarding, and permission for the target REST route
REST diagnosis times out	Check backend-to-JobManager latency, proxy behavior, and JobManager load; the diagnostic budget is eight seconds
Response format is invalid	Check whether a proxy error page replaced JSON, REST API compatibility, and whether the response exceeds the 2 MiB limit
Every metric panel is empty	Check Prometheus targets, JobManager/TaskManager reporters, and the metric-source link
Only job/checkpoint panels are empty	Check for active jobs and checkpoint usage; this can be normal on an idle cluster
Only one role or job is empty	Check actual metrics.scope.*, the flink_ prefix, labels, and mapping-pack rules
Time-window diagnosis is unavailable	Verify the Prometheus link and range-query support for the required logical metric

---

Apache Flink Enterprise Overlay

TLS settings location

TLS modes, CA/client certificates and keys, server names and verification options are grouped under Security > TLS. Endpoint/port fields keep their original location. Grouping does not change field keys, saved values, defaults, sensitive handling, visibility or validation.

Basic accessibility observation

Resource overviews show accessible, inaccessible, or access unknown independently of metric sources. Successful access does not attest healthy membership, replication, partitions, or workloads; use domain diagnostics and alerts for those conditions. Existing liveness/readiness fields are domain evidence and do not drive the single core-owned access alarm. Unknown observations do not resolve firing incidents.

TLS

Enable tls_insecure_skip_verify in connection settings to retain TLS encryption without verifying the server certificate. It defaults to false and does not require a CA when enabled. Mutual TLS still requires a client certificate and key when requested by the server. Keep CA-based verification enabled when server identity must be authenticated.

Capacity stays in one four-card row. Job/task workload and JVM comparisons use two columns, and the four recovery trends share one row. Labels and series are retained. Existing saved layouts and query definitions remain unchanged.

Counts are shown as integers, while scaled millisecond durations retain useful fractional digits. Percent gauges use a 0–100 range. Task throughput summaries add task series, while pressure, latency, CPU, and heap summaries show the worst series. A missing metric or ratio operand remains unknown.

The 16 dashboard panels are grouped into Overview (8 capacity and workload panels), Recovery (4), and Resources (4). Capacity, traffic, and backpressure can be compared in the same view. Job/task trends and TaskManager resource comparisons use half width without changing query scope, aggregation or saved layouts.

Eligible single-metric stat panels show a lower sparkline. The current value keeps its instant query; a separate history request asks for at most 160 samples per series per queried interval. Categorical states and compound calculations are excluded. A history failure preserves the current value and displays “Trend unavailable”.

The Apache Flink Enterprise overlay adds multi-signal anomaly rules and read-only MCP descriptors to the Community Flink resource plugin. Community continues to own connectivity, JobManager REST diagnostics, dashboards, logical metrics, mapping packs, and managed alerts.

Metric interpretation

Slot and JVM heap ratios require a positive reported limit. Missing or nonpositive limits produce no data, and values above 100% remain visible as exporter evidence.

Before Registration

1. Configure JobManager REST connectivity and optional Bearer authentication as described in the Community manual.
2. Link the Prometheus resource that collects the JobManager and every TaskManager to the Flink resource.
3. Confirm that the Enterprise license enables mcp.gateway and anomaly.engine.
4. Grant anomaly-rule readers Resource Viewer or Resource Operator access.
5. Grant correlation readers Resource Viewer or Resource Operator access; metric evidence must include an RFC 3339 observation time and, when used, a valid time range.
6. Give MCP callers both an allowed MCP read scope and access to the target Flink resource instance.

MCP and anomaly analysis do not replace the Flink REST connection. Validate REST state, Prometheus collection, and logical-metric mapping separately.

Anomaly Rules

flink-anomaly-rules-v1 provides five rules. Every rule uses all condition mode, so all listed conditions must match in the same evaluation context.

Rule key	Severity and score	Conditions	First checks
flink.worker_availability_risk	critical, 0.98	running jobs at least 1; registered TaskManagers below 1	TaskManager registration, heartbeat, network, JobManager leadership, and task slots
flink.checkpoint_restart_cascade	critical, 0.94	checkpoint-failure increase above 0; job-restart increase above 0	job exception, latest completed/failed checkpoint, and checkpoint storage
flink.backpressure_capacity_saturation	warning, 0.86	backpressure at least 50%; task-slot utilization at least 90%	constrained operator, upstream/downstream throughput, slots, and parallelism
flink.taskmanager_resource_pressure	warning, 0.82	TaskManager CPU at least 90%; heap utilization at least 85%	per-TaskManager skew, GC, busy time, and backpressure
flink.throughput_stall_pattern	warning, 0.80	input at least 1 record/s; output at most 0.001 record/s; busy time at least 85%	sink, asynchronous I/O, operator exceptions, and per-task skew

These rules do not replace Community managed alerts. Managed alerts evaluate individual thresholds and pending durations, while Enterprise rules combine logical metrics to provide incident-triage evidence.

Every rule points to correlation/runtime-risk for relation-aware evidence and uses unknown_no_trigger for missing or stale inputs. Job and checkpoint metrics can be absent on an idle cluster. Do not interpret a missing series or unresolved mapping as healthy or zero; inspect metric linkage and mapping state first.

MCP Resources And Tools

The MCP catalog provides 11 read resources and 13 read tools.

Kind	Surfaces
Resources	monitoring overview, cluster inventory, topology, current diagnostics, historical diagnostics, metric catalog, mapping-pack catalog, managed alerts, anomaly rules, software inventory, and runtime-risk correlation
Diagnostic tools	monitoring overview, cluster inventory and topology, plus summary, cluster, job, checkpoint, and performance diagnostics
Metric tools	logical-metric query resolution and mapping-pack resolution
Analysis and rule tools	runtime-risk correlation, managed-alert metadata, and Enterprise anomaly-rule metadata

The metrics_query_resolve tool accepts:

Input	Required	Value
logical_metric_key	yes	A logical key from the Community Flink metric catalog
query_mode	no	instant or range

The runtime_risk_correlation tool accepts optional metric_values_json, metric_observed_at, window_start, window_end, and a bounded maximum evidence age. Only keys from the Community Flink logical metric catalog are used. Unknown keys, secrets, and raw upstream response bodies are not returned.

MCP descriptors expose query routes only. The diagnostics/summary/run refresh is a separately RBAC-protected write action and is deliberately excluded from the read-only catalog. Job deployment, cancellation, savepoints, stop-with-savepoint, and rescaling are also not exposed through MCP. Operators use the Community operations page, RBAC, confirmation, dry-run, and audit controls for the supported mutations.

Runtime-risk Correlation

correlation/runtime-risk reads bounded Community inventory, topology, and checkpoint evidence and combines it with optional fresh metric values. It reports worker availability, slot pressure, checkpoint failures and age, restart cascades, backpressure with slot pressure, throughput stalls, and TaskManager JVM pressure. Each finding includes source routes, observed time, time range, freshness, completeness, entity roles, confidence, expected impact, and a recommended follow-up.

The result is advisory. Partial REST collection, invalid metric JSON, stale observation times, missing metric keys, and incomplete topology remain unknown; none are converted into a normal result. Flink REST topology proves role-level relationships but not direct task-to-TaskManager placement.

Operations Risk And Impact

The Enterprise operations/schema contribution adds a read-only Risk & Impact tab and a per-job summary action to the Community Operations page. The contribution uses the flink.correlation.runtime_risk capability and is removed by normal license/access filtering when the Enterprise overlay or Resource Viewer/Operator access is unavailable. Community job inventory, dry-run, RBAC, confirmation phrases, audit fields, action payloads, and mutation handlers remain unchanged.

Opening Risk & Impact for a job captures a bounded in-process baseline for 30 minutes. A successful cancel, savepoint, stop-with-savepoint, or rescale action passes its execution ID to the risk tab. While that tab is active, the normal screen refresh and manual refresh re-read operation status and current risk; there is no plugin background worker. A terminal execution is classified as improved, degraded, or unchanged only when both snapshots are complete. Missing or expired baselines, non-terminal or invalid execution IDs, and any unknown or partial evidence produce indeterminate instead of an optimistic result.

Each protected action dialog includes its expected impact and the checks to run after execution. Review the per-job Risk & Impact summary before dry-run, keep the same request context through final execution, then use the execution-linked tab to verify job state, slots, checkpoints, backpressure, throughput, and JVM pressure. The baseline cache is bounded process-local evidence, not durable audit history; the platform audit log and operation-artifact catalog remain the durable records.

Operational Workflows

Worker availability risk

1. Confirm the running-job and registered-TaskManager counts.
2. Read TaskManager registration and task-slot evidence from JobManager REST diagnostics.
3. Check TaskManager process, heartbeat, network, and resource state.
4. After workers recover, verify available slots and job recovery before deciding whether to restart.

Checkpoint and restart cascade

1. Identify the affected job and its recent exception.
2. Compare completed and failed checkpoints, duration, and storage reachability.
3. Read backpressure, TaskManager CPU/heap, and restart increase over the same interval.
4. Do not repeatedly change restart strategy or parallelism before confirming the cause.

Throughput stall

1. Compare input, output, and busy time by job and task over the same interval.
2. Inspect the stalled operator chain, sink, asynchronous I/O, and external dependencies.
3. Compare backpressure and slot headroom to distinguish skew from overall capacity shortage.

Troubleshooting

Symptom	Check in this order
EE extension or MCP entries are absent	Check Enterprise license, mcp.gateway, anomaly.engine, plugin version, and contribution loading
Anomaly-rule query is denied	Check Resource Viewer or Resource Operator access to the target resource
Correlation query is denied	Check Resource Viewer or Resource Operator access to the target resource
Correlation findings remain unknown	Restore the listed REST evidence route or provide catalog-valid metric values with a fresh RFC 3339 observation time and valid window
Before/after comparison is indeterminate	Open the per-job Risk & Impact summary before execution, keep the baseline within 30 minutes, wait for terminal operation status, and restore every unknown or partial source
No anomaly rule can be evaluated	Check the Prometheus link, Flink reporter targets, logical-metric mappings, and range-query support
Only job-related rules are unevaluated	Check for running jobs, checkpoint use, job/task labels, and default scopes
MCP metric resolution fails	Confirm that logical_metric_key exists in the current catalog and use instant or range for query_mode
Diagnostic refresh is absent from MCP	This is the intended read-only boundary; use Konduo's RBAC-protected diagnostic action

Edition Boundary

The anomaly pack, Operations risk contribution, MCP descriptors, and Enterprise localization remain in the EE overlay. Flink mutations and diagnostic execution do not bypass the read-only MCP surface; they remain behind existing Konduo API, RBAC, audit, and operation-artifact boundaries. The Community manual remains authoritative for rescale, asynchronous tracking, savepoint catalog, retention, and disposal behavior.

MCP argument and result contracts

Diagnostic summary and performance tools accept lookback (or lookback_window) and optional metric_source_id. Mapping-pack resolution accepts target_metric_source_plugin_id or metric_source_plugin_id. Metric resolution describes the supported instance and label selectors. Fixed cluster inventory, topology, current diagnostic detail, overview, and rule tools accept {}.

Argument-bearing routes retain compatible dynamic filters where the plugin passes an open query filter map; the advertised properties describe useful inputs without removing existing aliases. Unknown fields are rejected for explicitly argument-free tools.

Results contain route-specific diagnostic evidence, vendor inventory, optional fields, and availability states. These dynamic result shapes intentionally omit outputSchema; clients should inspect the returned structured content and status rather than assume a fixed success-only result. Tools and resources use the same instance scope, authorization, and masking. Resource-only catalogs remain available through resources/read; tools-only clients can inspect tool-backed operational routes but need resource support for the remaining metadata catalogs.