Skip to main content
Glama

create_metric_group

Creates a named, ordered group of Evaluators to score pipeline Sessions, with optional weights that define how metrics contribute to a Composite score.

Instructions

Creates a Metric Group: a named, ordered set of Evaluators to score Sessions of any pipeline with.

The group names Evaluators, not versions, so each run judges with their newest versions. Running it costs money if an Evaluator is judged. Find Evaluator ids with list_evaluators.

weights say how much each Metric counts toward the group's Composite, as {evaluator_id, metric_key, weight} entries. weight is a number above 0 and relative: weights are divided by their sum, so 2, 1, 1 count as 50%, 25%, 25%. Each Evaluator must be in the group, each metric_key must be one its newest version declares with a Normalized mean (a Score with both range and better, or a Label with a scale), and no pair may repeat; otherwise hub-api rejects the request. Without weights a group has no Composite. A stored weight with usable false and an unusable_reason means a newer Evaluator version dropped the Metric or its normalization: it is kept but no longer counts in new runs. :param name: The Metric Group's name. :param evaluator_ids: The Evaluators to run, in the order results show them (at least one). :param weights: Optional Metric weights, as described above. :returns: The created Metric Group, or an error message.

Input Schema

NameRequiredDescriptionDefault
nameYes
weightsNo
evaluator_idsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.44

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full load and does so well: it discloses cost implications, that evaluators are referenced by name rather than version so each run uses the newest version, the relative-normalization math for weights, the exact validation rules hub-api enforces (Normalized mean, no duplicate pairs), and the degraded `usable: false` / `unusable_reason` state that is retained but no longer counted. These are non-obvious failure and lifecycle behaviors an agent could not infer from the schema.

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?

Front-loaded with the purpose before the caveats, and every paragraph maps to a decision the caller must make. It is dense and long-ish for a three-parameter tool, and the weight-normalization example is partly redundant with the schema's own wording, but nothing is filler.

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?

A mutation tool with no annotations and no output schema, yet the description covers prerequisites, cost, validation rejection behavior, version-drift semantics, and even a returns line ('The created Metric Group, or an error message'). An agent has enough to call this correctly on the first try.

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

Parameters5/5

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

Schema description coverage is 0% at the top level, so the description must compensate, and it does: `evaluator_ids` is not just a list but an ordered list controlling result display order with a minimum of one, and `weights` is explained structurally and semantically. The business rules that no duplicate evaluator/metric pair may appear and that weights divide by their sum add meaning well beyond the raw types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource and goes further by defining the resource: 'a named, ordered set of Evaluators to score Sessions of any pipeline with.' That is far more than a restatement of the name. It does not, however, explicitly route against the adjacent lifecycle siblings (update_metric_group, list_metric_groups, delete_metric_group), so it lands at clear-but-undifferentiated rather than fully distinguishing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real context for when to reach for it and points to the prerequisite tool: 'Find Evaluator ids with list_evaluators.' It also warns that running the group costs money, which is a practical decision input. It stops short of explicit when-not guidance, e.g. when to update an existing group instead of creating a new one.

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

Deploy Server

Other Tools