AsOf

Entity diff between two dates

entity_diff

Read-onlyIdempotent

What changed on an entity's record between two days: its state on from against its state on to (today when omitted), compared by claim. added: facts held on to and not on from. ended: held on from, not on to, and not replaced. replaced: the same predicate with another value, the claim that held on from beside the one that holds on to (paired by the record's superseded_by pointer, when the predicate has exactly one of each and the new value begins the day the old one ends, or when the predicate has one holder at a time, such as ceo, chair, cfo or headquarters, and one holder ended while another began). unchanged counts the claims held on both days; by_predicate gives each predicate's counts; summary is the one sentence the page /record/{slug}/diff leads with: quote it. Rows carry the fields entity_state rows carry; added rows are labelled for to, ended rows for from. Posts and Hugging Face repos are counted (skipped_posts), not listed: changes_since lists them. counts, by_predicate and summary cover the whole diff; the rows are paged in the order replaced, added, ended (limit default 50, max 200; offset pages; complete: false and next_offset say there is more). group: true reads the entity's company group (as in entity_state), each row naming its record. from must be before to.

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>",
      "from": "<from>"
    },
    "name": "entity_diff"
  }
}

Input Schema

Name	Required	Description	Default
`to`	No	The later day, ISO date YYYY-MM-DD; today when omitted
`from`	Yes	The earlier day, ISO date YYYY-MM-DD
`group`	No	Compare the entity's company group (Google with Alphabet, Google DeepMind, Gemini...)
`limit`	No	Rows per page across replaced, added and ended (max 200)
`detail`	No	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.	full
`entity`	Yes	Entity slug, e.g. openai
`offset`	No	Skip this many rows (next_offset from the previous page)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 13, 2026

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"
+}

First observedNov 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, but the description adds substantial behavior: what gets silently skipped (posts and HF repos only counted), the fixed row ordering (replaced, added, ended), pagination with complete:false and next_offset, and that counts/by_predicate/summary cover the whole diff rather than the page. It also maps each category (added/ended/replaced/unchanged) to a definition, which is more than the annotations provide.

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?

A single sprawling paragraph with stacked parentheticals, most severely the 'replaced' definition, which buries a simple rule inside a long clause about superseded_by pointers and single-holder predicates. The purpose is front-loaded, but the structure makes key behaviors hard to scan and several ideas deserve their own sentences.

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?

There is no output schema, so the description carries the return-shape burden and does: it explains added/ended/replaced/unchanged, counts, by_predicate, summary, rows, paging fields and complete/next_offset. For a seven-parameter diff tool this is effectively complete.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the from-before-to constraint, that group: true mirrors entity_state grouping and names each row's record, and how offset/limit interact with page ordering and next_offset. The detail enum is already fully documented in the schema, so this is additive rather than duplicative.

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 operation on a specific resource: what changed on an entity's record between two days, compared by claim. It explicitly contrasts with siblings by noting posts and Hugging Face repos are counted (skipped_posts) and that changes_since lists them, so an agent can distinguish it from entity_state and changes_since without opening a schema.

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?

Gives the when-to-use condition clearly (diff two dates; omit to for today) and names an alternative for a related need: changes_since lists the posts/repos this tool only counts. Also states prerequisites such as 'from must be before to' and the semantics of group: true. Missing only an explicit contrast with entity_state for single-date snapshots.

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

All AsOf tools Inspect

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

Need Help?