Skip to main content
Glama
research-workflow-studio

research-workflow-studio

by BorgDiven

rws_metrics_snapshot

Idempotent

Freeze selected run metrics through a read sequence into one immutable metric-history artifact, including definitions and points; reject snapshots over 5,000 points instead of truncating.

Instructions

Freeze the selected run metrics through a previously read sequence into one immutable metric-history artifact. Includes complete definitions and points; rejects over 5000 points instead of silently truncating.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "requestId": "<requestId>",
      "projectId": "<projectId>",
      "expectedRevision": "<expectedRevision>",
      "runRef": "<runRef>",
      "title": "<title>",
      "throughSequence": "<throughSequence>"
    },
    "name": "rws_metrics_snapshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
toXNo
fromXNo
titleYes
runRefYes
metricIdsNo
projectIdYes
requestIdYes
throughSequenceYes
expectedRevisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.2

TDQS

B3.4/5.0
Behavior4/5

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

Adds genuine value beyond annotations: the artifact is immutable, it carries complete metric definitions as well as points, and it hard-fails above 5000 points instead of truncating. With destructiveHint=false and idempotentHint=true already declared, the remaining gaps are the concurrency contract (expectedRevision/requestId) and what a revision mismatch yields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences with no filler, leading with the core action and following with the limits behavior that matters most for correct invocation.

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

Completeness2/5

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

For a 9-parameter, 6-required mutation with a nested object and no output schema, the description omits the meaning of the required concurrency and idempotency fields, how metricIds scopes the snapshot, and what the caller gets back. An agent could not fill the schema correctly from this text plus 0% field coverage.

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

Parameters2/5

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

Schema description coverage is 0% across 9 parameters, including a nested runRef object, so the description carries the full burden and does not meet it. It never explains throughSequence, expectedRevision, requestId, metricIds, or the fromX/toX window; only 'sequence' faintly echoes one field name.

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?

Names a specific verb (freeze) and a specific resource (an immutable metric-history artifact) built from run metrics up to a sequence. That is distinguishable from rws_metrics_append and rws_metrics_query, though it never names those siblings to make the boundary explicit.

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

Usage Guidelines3/5

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

The phrase 'through a previously read sequence' implies you must query metrics first, which is real but indirect usage guidance. There is no explicit statement of when to snapshot versus append or query, and no mention of preconditions such as the revision check.

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