Skip to main content
Glama

rewind_consumer_group_offset_by_timestamp

Rewinds consumer group offsets to a specified timestamp. Optionally dry-run to preview changes or force action on active groups.

Instructions

Rewinds consumer group offsets manually based on a specific timestamp. Finds offsets matching the timestamp using Consumer, then sets using AdminClient. dry_run: If True, only calculates and returns the proposed offset changes without applying them. force: If True, forces the modification even if the group is active or STABLE.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo
dry_runNo
group_idYes
partitionNo
topic_nameYes
timestamp_msYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

B3.3/5.0
Behavior4/5

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

The description details the internal steps (Consumer, AdminClient) and explains the dry_run (preview changes) and force (override active group) parameters. This goes beyond the bare minimum, though it omits potential side effects like message loss or required permissions.

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?

The description is three sentences, front-loaded with the core action ('Rewinds... manually based on a specific timestamp'), followed by technical details and parameter explanations. Every sentence adds value with no redundancy.

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

Completeness3/5

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

Given the complexity (6 parameters, no annotations), the description is adequate but lacks prerequisites (permissions, group state), error conditions, and return value context (though an output schema exists). The force parameter notes one important constraint, but more completeness is needed.

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?

With 0% schema description coverage, the description must compensate. It explicitly explains dry_run and force but only implicitly covers group_id, topic_name, and timestamp_ms through the purpose. It does not describe the partition parameter or the unit of timestamp_ms, leaving gaps for half of the parameters.

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?

The description clearly states the tool rewinds consumer group offsets based on a timestamp, with specific verbs ('Rewinds') and resources ('consumer group offsets'). However, it does not explicitly differentiate from sibling tools like 'reset_consumer_group_offset', though the timestamp-based method implies uniqueness.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives. The description mentions dry_run and force but lacks context for appropriate usage scenarios or exclusions.

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