Skip to main content
Glama

get rewind

get_rewind
Read-onlyIdempotent

Build a Spotify-style Rewind of the user's wins for a year (kind year, with year), one role (kind role, with company and title from the profile), the whole career (kind career), or dates (kind range, with from and to): counts, top results, strengths, the career's steps, and a caption for LinkedIn, with share images and a LinkedIn carousel PDF. Use it to celebrate or share progress; for the plain list use list_wins, and for the employer timeline use get_career_timeline. Read-only: nothing is saved, and Compass OS never posts. With few wins logged it suggests logging past results with log_win.

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": {
      "kind": "<kind>"
    },
    "name": "get_rewind"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoFor range: the last day, YYYY-MM-DD
fromNoFor range: the first day, YYYY-MM-DD
kindYesWhat it covers: the whole career, one year, one role, or a date range
yearNoFor year: four digits, e.g. "2025"
titleNoFor role: the role's title, as the profile shows it
companyNoFor role: the role's company, as the profile shows it

Output Schema

NameRequiredDescriptionDefault
textYesThe answer, or what was done, in plain words for the user: the same text as content
undoNoOn a saved write: its undo handle, for undo within 24 hours
widgetNoThe card the host draws with it, e.g. "pipeline"; "confirm" means a write waits for the user's Yes and nothing is saved yet

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety bar is partly met elsewhere; the description still adds the user-visible guarantee that nothing is saved and Compass OS never posts, which matters for a share-oriented tool. It stops short of describing generation cost, latency, or what happens when images/PDF generation needs a download step, so it is not fully transparent.

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 verb and resource, and every clause carries information (modes, outputs, alternatives, read-only guarantee, fallback). The long enumerative sentence is dense and slightly hard to scan, but there is no filler to cut.

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?

Given six optional-per-mode parameters and an existing output schema, the description supplies everything an agent needs: what each kind covers, which parameters pair with it, what artifacts come back, the safety profile, and the alternatives. Nothing material is missing for correct invocation.

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 100%, so the baseline is 3; the description earns one more point by restating the conditional contract in prose (kind year needs year, kind role needs company and title from the profile, kind range needs from and to), which reinforces which parameters are relevant per mode. It adds no format hints beyond the schema, so it is not a 5.

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?

States a specific verb and resource ("Build a Spotify-style Rewind of the user's wins") and then enumerates the four coverage modes with their required inputs, plus the concrete artifacts produced (counts, top results, strengths, career steps, caption, share images, carousel PDF). It explicitly differentiates itself from list_wins and get_career_timeline, so an agent can choose it without opening the schema.

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?

"Use it to celebrate or share progress" gives the intent, and it names two alternatives with their respective scopes: list_wins for the plain list and get_career_timeline for the employer timeline. It also covers the low-data edge case by pointing to log_win when few wins are logged.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources