Skip to main content
Glama
Sign In
deepset-mcp

deepset-mcp

Official
by deepset-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_metric_groups

Lists a workspace's Metric Groups newest first, optionally attaching each group's latest scoring run for a pipeline to inspect status, timing, and selection.

Instructions

Lists the workspace's Metric Groups, newest first.

A Metric Group is a named, ordered set of Evaluators. It belongs to the workspace, not to a pipeline: a scoring run judges chosen Sessions of one pipeline with it, and an Experiment scores both its sides with one. With pipeline_name, each entry's last_run is its newest scoring run on that pipeline without the grid (status, selection, timing), or null when it never ran there; read a run's results with get_experiment_run. weights says how much each Metric counts toward the group's Composite (empty: no Composite); a weight with usable false says in unusable_reason why it will not count in a new run. The API has no paging: a result of exactly limit groups may be cut off (at most 200 are ever reachable). :param pipeline_name: A pipeline to attach each Metric Group's most recent scoring run on. :param limit: Most Metric Groups to return (at most 200). With pipeline_name each one costs a call. :returns: The Metric Groups, or an error message.

The output is automatically stored and can be referenced in other functions. Returns a formatted preview with an object ID (e.g., @obj_123). Use the object store tools in combination with the object ID to view nested properties of the object. Use the returned object ID to pass this result to other functions.

Input Schema

NameRequiredDescriptionDefault
limitNo
pipeline_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.44
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 200,
+  "title": "Limit",
+  "type": "integer"
+}
  2. Addedv0.1.31

TDQS

A4.5/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 behavioral burden and does so well: it discloses the lack of API paging, that a result of exactly limit may be truncated, that at most 200 groups are reachable, and that supplying pipeline_name costs one call per entry. It also explains that last_run is null when the group never ran on that pipeline and that weights flagged usable=false carry an unusable_reason.

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 purpose is front-loaded and the paragraph flows from definition to behavior to parameters, with no wasted sentences in the core prose. The trailing block about automatic object storage and object IDs is generic boilerplate that is only loosely tied to this tool, which trims a point.

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?

No output schema or annotations exist, so the description must describe returns, and it does: last_run fields (status, selection, timing), weights and unusable_reason, and an error message on failure. It does not enumerate the rest of a group's entry shape (identifiers, name, ordering of Evaluators), leaving a modest gap for a list tool.

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?

Schema description coverage is 0%, so the description must supply all parameter meaning, and it does for both: pipeline_name is described as attaching each group's most recent scoring run on that pipeline, and limit as a cap of 200 with a per-entry call cost when pipeline_name is set. It stops short of stating the default/bounds interaction beyond the 200 ceiling, but the semantics are substantive.

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 plus ordering: "Lists the workspace's Metric Groups, newest first." It then defines what a Metric Group is and how it relates to pipelines/experiments, which distinguishes it clearly from siblings like list_evaluators, create_metric_group, or list_experiments.

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 clear context on when the tool is relevant (workspace-scoped named sets of Evaluators) and explicitly routes one follow-up need away from this tool: "read a run's results with get_experiment_run." It does not explicitly say when to prefer this over alternatives such as listing evaluators directly, or to call it before update/delete_metric_group, so a small gap remains.

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