Skip to main content
Glama

update_metric_group

Replace a metric group's name and evaluator set, optionally setting relative metric weights for future Composite scores.

Instructions

Replaces a Metric Group's name and Evaluator set, and optionally its Metric weights.

This is a full replace of name and Evaluators: send every Evaluator the group keeps, in order (read them with list_metric_groups). Past runs are unaffected; each recorded the versions it used, and a run's Composite keeps the weights it started with, so edits change only later runs. Leave weights out to keep the stored weights of the Evaluators that stay (those of removed Evaluators are dropped); send an empty list to clear them all, which removes the Composite.

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 metric_group_id: The Metric Group's id. :param name: The name to keep or change to. :param evaluator_ids: Every Evaluator the group keeps, in order (at least one). :param weights: Replaces the stored weights; None keeps them, [] clears them. :returns: The Metric Group, or an error message.

Input Schema

NameRequiredDescriptionDefault
nameYes
weightsNo
evaluator_idsYes
metric_group_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.44

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does: it discloses full-replace/destructive semantics, that removed Evaluators' weights are dropped and clearing all weights removes the Composite, that past runs are unaffected because they pin versions and keep starting weights, and the exact hub-api validation conditions that cause rejection. Only permission requirements are unstated.

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?

Dense and front-loaded, leading with the replace semantics and the irreversibility note before validation detail. It loses a point for redundancy: weights are described both in the body prose and again in the ':param weights:' line, and the trailing Sphinx-style param block partially restates the paragraphs above.

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?

For a four-parameter, unannotated, no-output-schema mutation, the description supplies returns, failure behavior, validation constraints, and downstream effects on runs. The remaining gap is purely operational — permissions/auth and exact error shapes are not described.

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 coverage is 0% for the top-level parameters, so the description must compensate and does: every parameter is explained (id, name to keep, complete ordered evaluator_ids list with a minimum of one, weights None-vs-[] behavior). It also documents weight semantics (relative, above 0, sum-normalized, no duplicate pairs, metric_key must be a Normalized mean of the newest version) and the meaning of a stored weight with usable false.

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?

Opens with a specific verb and resource ('Replaces a Metric Group's name and Evaluator set, and optionally its Metric weights'), which also distinguishes it from create_metric_group and delete_metric_group. An agent knows this is a full-replace mutation rather than a patch.

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?

States the workflow prerequisite ('send every Evaluator the group keeps, in order (read them with list_metric_groups)') and gives explicit rules for the optional field: omit weights to keep stored values, send [] to clear them all. It names the sibling to call for reading state, so the when-and-how of invocation is fully resolved.

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