Skip to main content
Glama

AsOf

Entity state as of a date

entity_state
Read-onlyIdempotent

Also returns ended: the terms that closed on or before the day (a CEO who left, a seat given up), newest first, so a former role is answered too. State of an entity as of a date: the claims that held on that day, with sources and confidence. Omit as_of for today. For a company, person, product or regulator (a model has its own lineage fields), summary is the one dated, sourced sentence its record page opens with, title its page title from the same facts, key_facts the page's fact card (each with its claim) and faq the questions the page answers: quote summary as the record's answer. By default returns the core facts (leadership, ownership, names, financials, headquarters) and skips identifiers, bulk lists and events; pass predicates to ask for specific ones (e.g. ['subsidiary','board_member','hf_repo_created']) or scope='all'. By default only claims the record asserts are returned (valid, or primary-sourced at confidence 0.7+; never flagged or marked for review); scope='all' returns everything held on the date with its status; assertable_only overrides either default. Capped by limit (default 60, max 300); offset pages. as_of is effective time: a quarter's revenue is dated at the quarter end even though it was filed weeks later. known_by answers what could have been known on a day, strictly: only claims a source had published, or AsOf had recorded, by then; a figure published later is listed under not_yet_published and the claim it replaced is returned with ended_later; a claim no source dates that AsOf recorded later is listed under publication_unknown, not counted as known. Pass known_by alone for that day, or both for 'true on as_of, as known by known_by'. Dated events (released, launched, partnership, customer, acquired, ranking_update) are not state: ask timeline for those. group: true answers for the entity's company group (the records linked by parent_id, ownership claims or an official feed that speaks for both, and their products): each row's entity names its record, a fact held on two records is one row with the other in also_on, and group.members says how each record joined. An empty answer carries empty: the reason (nothing public, nothing held on the day, or only events and lists), the entity's coverage gaps and the records group: true would add. fact_pages lists the entity's one-fact pages today (revenue, ceo, valuation, headquarters...), each with a fetch id: the current value with its sources, every dated value before it and what replaced what.

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": "entity_state"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofNoISO date YYYY-MM-DD
groupNoAnswer for the entity's company group: Google with Alphabet, Google DeepMind, Gemini...
limitNo
scopeNocore (default) or all
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
entityYesEntity slug, e.g. google, openai, anthropic
offsetNoSkip this many matching claims (next_offset from the previous page)
known_byNoISO date YYYY-MM-DD: count only claims a dated source published, or AsOf recorded, by this day. as_of defaults to it
predicatesNoOnly these predicates
assertable_onlyNoOnly claims the record asserts for the day. Default true for core, false for all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field 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"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The annotations already declare read-only, idempotent, and non-open-world behavior, but the description adds substantial beyond that: default assertion filtering, limit/offset behavior, effective-time semantics for as_of, strict known_by publication rules, group roll-up behavior, and the shape of empty answers. No annotation contradiction is present.

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 paragraph that opens with 'Also returns ended' before clearly stating the primary purpose, and it chains many advanced rules together with semicolons. Much of the content is useful, but it is not front-loaded or scannable, and the structure works against quick comprehension.

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?

For a complex 10-parameter tool with no output schema, the description explains return fields, empty-answer behavior, group semantics, pagination, effective-time handling, known_by restrictions, and fact_pages. It is unusually complete and gives an agent enough to invoke the tool correctly.

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 high at 90%, so the schema already defines most parameters. The description still adds meaningful semantics beyond it, including the limit maximum, as_of as effective time, known_by's strict 'could have been known' logic, group=true behavior, and the default assertable_only policy.

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?

The description states a specific verb, resource, and temporal scope: 'State of an entity as of a date: the claims that held on that day, with sources and confidence.' It also explicitly distinguishes state from dated events by routing those to the timeline sibling.

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?

It gives concrete when-to-use guidance: omit as_of for today, use timeline for dated events, use group=true for company-group answers, pass predicates or scope='all' for broader results, and use known_by for as-known-at questions. It also names the claim tool/page as the place for claim-level detail.

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