Skip to main content
Glama

AppTierList

What changed

recent_changes
Read-onlyIdempotent

Append-only history: memberships added/removed, tier changes, categories created/activated/archived, apps discovered/missing. Newest first (by time, then id); page with cursor. To poll for new events use after_id instead: events whose seq is greater than after_id, oldest first by seq, each with its seq, and next_after_id (the last seq) to send next time (start at 0); seq is the order events became public, so it never misses an event written late or shown after review, which since can (not with since, cursor or summary). since is exact for events: only changes after that instant. summary=true answers 'what moved this week' in one call instead: per category, apps added/removed/contested, each app's net tier move (up, down, entered or left the top 40) with the S/A moves and membership changes as highlights (each with its reason: why it moved, e.g. under review or checked), plus catalog events; window from since rounded down to its UTC day (default 7 days back, at most the last 31 days), counted over every event in it. By default the 15 busiest categories (lists_total says how many changed); pass list for one.

Input Schema

NameRequiredDescriptionDefault
kindNoone change kind (not with summary)
listNocategory slug
limitNodefault 100 (not with summary)
sinceNoISO-8601 timestamp. Events: only changes after this exact instant. summary: rounded down to its UTC day, within the last 31 days
cursorNonext_cursor from the previous page (not with summary)
summaryNotrue: a per-category digest of the window instead of raw events
after_idNopolling: events whose seq is greater than this, oldest first by seq; send next_after_id from the previous answer, 0 to start (not with since, cursor or summary)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnly/idempotent annotations: append-only history, newest-first ordering, seq semantics, late-event safety, exact since behavior for events versus rounded-day summary windows, and default/max window rules. Nothing contradicts the annotations.

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

Conciseness3/5

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

Purpose is front-loaded, but the rest is one dense run-on paragraph with tangled parentheticals such as 'which since can (not with since, cursor or summary)'. The information is mostly necessary, but bulleted mode structure would materially improve scanability.

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?

Given 7 optional parameters, three modes, and no output schema, it covers mode constraints and summary/polling outputs well. Raw event object fields and list filtering behavior outside summary mode remain only partially specified.

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 already 100%, but the description still adds operational meaning: the after_id polling contract with next_after_id and start at 0, seq ordering guarantees, summary window rounding/default/max, and the default category count with lists_total. This is well beyond the field-level schema text.

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 resource: append-only change history, with event kinds enumerated and ordering described. It also separates raw events, after_id polling, and summary digest modes, so an agent can understand the tool's scope without opening the schema. No sibling tool covers history, so differentiation is implicit but clear.

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?

Explicitly routes between modes: use after_id instead for polling, summary=true instead for a digest, pass list for one category, and respect 'not with since, cursor or summary' incompatibilities. It also gives defaults such as the 15 busiest categories and a 7-day summary window. Sibling comparison is not needed because none of the named siblings overlaps with history.

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.