Skip to main content
Glama

AsOf

Changes since a date

changes_since
Read-onlyIdempotent

Leads with headline and highlights: the changes that took effect since the date, ranked (leadership, then ownership and deals, then releases; figures and repositories last) and said as a sentence, drawn from the entity's whole record when one is named. Read them first; the rows follow. Every claim that became true, stopped being true, or was first recorded after a date. The diff query. Optionally scoped to one entity. Claims dated in the future (announced for a later date) are not changes yet and are left out; timeline shows them. limit default 50, max 200; offset pages through the first 900, newest first (the last page is shortened to end there). cursor pages the same feed with no cap, in the order the claims were recorded (oldest first; order: recorded in the answer): pass "" for the first page, then next_cursor from the previous answer; not with offset. assertable_only keeps claims the record asserts for their own dates. Each row carries kind (people, money, products, models or other), the same kinds /changes filters by; kind keeps one (on the page, so a page can come back short). For one entity's state on two days compared per fact, use entity_diff.

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
kindNoOnly changes of this kind (lib/change-types.ts, as /changes?type=)
viewNonews: only changes a reader would call news, that the record asserts: leadership, ownership, deals, funding, releases, board and feature changes, the main figures. Left out: Hugging Face repositories, posts, identifiers, routine balance-sheet and quarterly rows, undated claims, and unverified, flagged or retracted ones. For changes_since with an entity, news also means took effect since the date (not merely recorded since), newest first, with total. A news timeline pages by 50 unless limit says otherwise. all (the default): every row.all
limitNo
sinceYesISO date YYYY-MM-DD
cursorNoPage in recorded order with no cap: "" for the first page, then next_cursor from the previous answer (opaque). Not with offset
detailNocompact: each row is id, predicate, value, qualifier, the dates it held, status, why_not when the record does not assert it, and the primary source URL: about a fifth the size, so a page holds five times the rows. Left out: published, recorded, confidence, citation, evidence (each is on the claim page, https://asof.is/claim/{id}, or the claim tool). full (the default): every field.full
entityNo
offsetNoSkip this many changes, newest first (next_offset from the previous page); up to 900. Not with cursor
assertable_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / view / description
      Previous value: -"news: only changes a reader would call news, that the record asserts: leadership, ownership, deals, funding, releases, board and feature changes, the main figures. Left out: Hugging Face repositories, posts, identifiers, routine balance-sheet and quarterly rows, undated claims, and unverified, flagged or retracted ones. For changes_since with an entity, news also means took effect since the date (not merely recorded since), newest first, with total. all (the default): every row."New value: +"news: only changes a reader would call news, that the record asserts: leadership, ownership, deals, funding, releases, board and feature changes, the main figures. Left out: Hugging Face repositories, posts, identifiers, routine balance-sheet and quarterly rows, undated claims, and unverified, flagged or retracted ones. For changes_since with an entity, news also means took effect since the date (not merely recorded since), newest first, with total. A news timeline pages by 50 unless limit says otherwise. all (the default): every row."
  2. Changed2 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": "full",
      +  "description": "compact: each row is id, predicate, value, qualifier, the dates it held, status, why_not when the record does not assert it, and the primary source URL: about a fifth the size, so a page holds five times the rows. Left out: published, recorded, confidence, citation, evidence (each is on the claim page, https://asof.is/claim/{id}, or the claim tool). full (the default): every field.",
      +  "enum": [
      +    "full",
      +    "compact"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "all",
      +  "description": "news: only changes a reader would call news, that the record asserts: leadership, ownership, deals, funding, releases, board and feature changes, the main figures. Left out: Hugging Face repositories, posts, identifiers, routine balance-sheet and quarterly rows, undated claims, and unverified, flagged or retracted ones. For changes_since with an entity, news also means took effect since the date (not merely recorded since), newest first, with total. all (the default): every row.",
      +  "enum": [
      +    "all",
      +    "news"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent and closed-world, so the bar is lower; the description still adds real behavior: limit default 50 / max 200, the 900 offset ceiling with a shortened final page, cursor ordering by record date rather than effective date, and the warning that filtering by kind can return a short page. It stops short of describing the ranking/headline fields precisely, but 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.

Conciseness4/5

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

Front-loads the headline-then-rows shape and the ranking rule before drilling into pagination, so the most decision-relevant content comes first. It is dense and telegraphic in places ("The diff query."), and the cursor/offset rules partly repeat the schema descriptions, but nearly every sentence carries operational information.

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?

No output schema exists, so the description has to describe the return shape, and it does: a lead sentence plus ranked highlights, then rows carrying kind, with next_cursor handed back for paging. For a 9-parameter tool with two pagination modes it is largely complete, though it could say more about what the headline sentence contains when no entity is named.

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?

With 9 parameters and 67% schema coverage, the description carries meaningful extra weight: it explains the cursor contract ("" for the first page, then next_cursor) and its ordering, the offset/cursor incompatibility, what assertable_only asserts for, and that kind keeps one value per page, so a page can come back short. Only entity and since get no added semantics beyond the schema.

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?

Names the specific resource and scope: claims that became true, stopped being true, or were first recorded after a date, plus the ordering applied to the headline (leadership, ownership/deals, releases, figures/repositories). It explicitly routes away from the closest sibling with "For one entity's state on two days compared per fact, use entity_diff" and "timeline shows them" for future-dated claims.

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?

States when to use it (read the headline first, rows follow), when a claim is out of scope (future-dated announcements that have not taken effect), and which alternatives handle those cases (timeline, entity_diff). It also spells out the mutually exclusive pagination modes: offset up to 900 or cursor with no cap, "not with offset".

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