Skip to main content
Glama

Control Plane

by io.cpln

List & Discover Metrics

list_metrics
Read-onlyIdempotent

Discover what metrics you can query before calling query_metrics, so you never guess a metric name or label. Returns the documented Control Plane default metrics (with type and a correct PromQL template each), PLUS the metrics actually present in the org right now — including CUSTOM metrics your workloads expose and kube_/node_ families. Pass filter to narrow by substring. Pass metric to see that metric’s REAL label dimensions and values (workload, gvc, location, …) from live data so your PromQL filters are grounded, not invented. Reach for this whenever a metrics query returns nothing or you are unsure of names/labels — it is optional, not required when you already know the metric you want.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orgYesOrganization slug (lowercase kebab-case). NEVER guess — if the user has not named one, ask. On org-not-found, stop and ask; do not retry variants.
limitNoMaximum number of items to return (1-500, default: all).
filterNoCase-insensitive substring to narrow the catalog and live metric names (e.g. "cpu", "workload", "agent").
metricNoA metric name to ground: returns its REAL label dimensions and sample values (workload, gvc, location, …) from live data, so you can build an accurate PromQL filter. Works for custom metrics too.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the call succeeded.
dataNoThe full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary.
summaryYesOne-line summary of the result.
nextStepsNoRecommended follow-up actions for this task, in order.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description adds substantive behavioral context: it returns both documented defaults and live org metrics, and the `metric` parameter fetches real label dimensions and values from live data. No contradiction with annotations.

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 is longer than typical but every sentence adds value: purpose, return content, parameter nuances, and usage triggers. It is front-loaded with the key 'discover' message and structured logically. Minor verbosity is justified by the tool's broad scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and annotations covering safety, the description is complete enough: it states what is returned, how to filter, how to ground metrics, and when to use it. Minor omissions like pagination details are not critical for correct invocation.

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?

Input schema covers all parameters with descriptions (100% schema_description_coverage), so baseline is 3. The description enhances meaning by clarifying `filter` is a case-insensitive substring that narrows 'catalog and live metric names' and that `metric` exposes live label dimensions (workload, gvc, location) and works for custom metrics, beyond the schema.

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 specific verb and resource: 'Discover what metrics you can query before calling query_metrics'. It enumerates exactly what is returned (documented default metrics with types and PromQL templates, plus live metrics including custom and kube_/node_ families), clearly distinguishing it from sibling tools like query_metrics.

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: 'Reach for this whenever a metrics query returns nothing or you are unsure of names/labels' and the exclusion 'optional, not required when you already know the metric you want.' It positions the tool as a precursor to query_metrics, making the use case unmistakable.

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

All Control Plane toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Every tool targets a distinct resource/action pair (e.g., get_resource vs get_resource_schema, list_deployments vs list_workload_replicas) and descriptions clearly differentiate purposes. No two tools appear to do the same thing.

Naming Consistency5/5

All tools follow a verb_noun snake_case pattern (create_gvc, update_workload, list_resources, query_metrics) with consistent verbs. The few imperative verbs (browse, build, mount) still maintain the same verb-first structure.

Tool Count1/5

With 55 tools, this server far exceeds the typical well-scoped 3-15 tool range. While each tool appears purposeful, the sheer number creates selection overhead and falls into the extreme 50+ category on the rubric.

Completeness4/5

The surface covers nearly the full Control Plane lifecycle: CRUD for GVC, workload, identity, policy, volumeset, and domain, plus observability, templates, image builds, and Terraform. Minor gaps include referenced but missing configure_workload_* tools and no secret creation/deletion (by design).

Resources