Skip to main content
Glama

New stories since a time

changes_since
Read-onlyIdempotent

Stories we published after a timestamp, oldest first, for polling. Use next_since from the result as the next call's since. Corrections and removals are not conveyed.

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": {
      "since": "<since>"
    },
    "name": "changes_since"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size; use next_since from the result to continue.
sinceYesISO datetime. Stories we published after this moment, oldest first. At most 7 days back anonymous, 30 with a key.
sectorNoRestrict to these sectors. Sector slugs: see list_sectors (e.g. healthcare_life_sciences, law, retail, regulation_government, financial_services, manufacturing_robotics).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description is not obligated to restate that. It earns credit for two non-obvious behaviors: the oldest-first ordering and the explicit limitation that 'Corrections and removals are not conveyed', which warns the agent that this feed is not a full change log. It stops short of describing payload contents or edge cases like gaps when the since window lapses.

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?

Three short sentences, each load-bearing: what it returns, how to paginate, and the caveat. The core polling contract is front-loaded before the limitation.

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?

With no output schema, the description carries return-shape burden, and it does flag the key return field (next_since) and the fact that removals/corrections are absent. It does not describe the story objects returned or the practical consequence of missing the 7/30-day window, leaving minor gaps for a polling tool.

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

Parameters3/5

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

Schema description coverage is 100%, so `since`, `limit` and `sector` are already documented in-schema including the anonymous-key window and the list_sectors pointer. The description only reinforces the since/next_since loop and adds nothing about `sector` or `limit` beyond what the schema states. Baseline 3 is appropriate.

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 names the specific resource (stories published after a timestamp), states ordering (oldest first) and use case (polling), so the agent knows this is a delta/incremental feed rather than a query tool. It is clear, but it never names the sibling it competes with (search_stories) to make the distinction explicit.

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?

'for polling' plus 'Use next_since from the result as the next call's since' gives a precise, actionable continuation loop that an agent can follow without inference. What is missing is when NOT to use it or which alternative (search_stories) covers free-text retrieval.

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