Skip to main content
Glama
Sign In

AsOf

by is.asof
OverviewDiscussionsAdmin

Entity timeline

timeline
Read-onlyIdempotent

Leads with headline and highlights, the main changes among the rows asked for, ranked and said as a sentence; the rows follow. Dated events and state changes for an entity in chronological order, superseded claims included, future-dated (announced) items included. Newest first when limited. Pass predicates to filter (e.g. ['released','model_release']; hf_repo_created is the day a Hugging Face repository was created, not a release date); on for one exact date, or from/to for a range; limit default 100, max 500; offset pages back (complete: false and next_offset say there is more). assertable_only keeps claims the record asserts for their own dates: a superseded CEO is assertable for the years he held the role. Each row carries its source's title: when a question names a date, answer from the rows on that date, and when several rows share a date, the title says which post each came from. Confidence ranks sources, not dates. group: true reads the entity's company group (as in entity_state): each row's entity names its record and a fact held on two records is one row (also_on). Every row carries its kind (people, money, products, models, other); kind keeps one. summary is the sentence the timeline page leads with and counts its claims by kind, over the entity's own timeline.

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": {
      "entity": "<entity>"
    },
    "name": "timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
onNoOnly events dated exactly this day, YYYY-MM-DD
toNoLatest date, YYYY-MM-DD
fromNoEarliest date, YYYY-MM-DD
kindNoOnly this kind of change
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
groupNoEvery record of the entity's company group, merged
limitNo
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
entityYes
offsetNoSkip this many rows, newest first (next_offset from the previous page)
predicatesNo
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

A3.8/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/closed-world, and the description adds substantial behavior on top: newest-first ordering, limit default 100 and max 500, offset paging with complete:false and next_offset signalling more rows, superseded claims retained, and the note that confidence ranks sources rather than dates. It does not cover error conditions or what an empty timeline looks like, but the operational profile is well disclosed.

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

Conciseness2/5

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

The definition is a single dense block of semicolon-chained clauses with no paragraph breaks, and it opens with a convoluted sentence about headline and highlights instead of the tool's function. Nearly every fact is useful, but the ordering and run-on structure make it hard to scan, so the content is not front-loaded and the signal-to-noise suffers despite the information density.

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?

For a 12-parameter read tool with no output schema, the description covers what a row contains (kind, source title, qualifier, status, why_not in compact mode) and how pages relate (next_offset, complete). Combined with annotations covering safety, an agent has what it needs to call and interpret this correctly, with minor gaps only around empty results and performance.

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?

With schema coverage at 67%, the description compensates strongly: it explains predicates with a concrete caveat (hf_repo_created is repository creation, not a release date), the on/from/to date semantics, limit default and max, offset as consuming next_offset, assertable_only via a worked superseded-CEO example, group row-merging with also_on, kind bucketing, and detail's compact-vs-full field list. This adds meaning well beyond the schema text.

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 second clause states a specific verb and resource: 'Dated events and state changes for an entity in chronological order, superseded claims included, future-dated (announced) items included.' That is enough to distinguish it from entity_state and claim, though the leading sentence is about the headline/highlights of the page rather than the tool's purpose, which muddies the opening rather than routing the agent.

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

Usage Guidelines3/5

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

There is real in-context guidance: 'when a question names a date, answer from the rows on that date,' 'on for one exact date, or from/to for a range,' and 'group: true reads the entity's company group (as in entity_state).' But it never says explicitly when to choose timeline over entity_state, entity_diff, or changes_since, and the only alternative it names is the claim tool for evidence fields, so the routing is implied rather than stated.

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

All AsOf toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources