AsOf

Search the record

search

Read-onlyIdempotent

Find entities by name, slug, ticker or former name ('MSFT', 'Facebook', 'Google AI Mode'; accents, spacing and one typo forgiven), and claims by value, predicate, entity and date ('who is the CEO of Microsoft', 'Google core update March 2026'), best match first. Returns slugs to use with the other tools, matching claims (entity, predicate, value, date) and the days a query names. A product released, a ranking update rolled out, a company acquired are values on their maker's record, not entities, so search for the thing itself ('August 2026 spam update') and read the date off the claim. A question in full ('who ran Nvidia in 2019', 'Meta revenue as of 2024-06-30', 'what changed at OpenAI since March 2026') is also answered: answers holds one card per fact asked (answer is the first), each with a sentence (the value, its date and sources; what holds today when the day asked is past; the change against the value before), the entity, the fact and the day it was read as asking about, and the claims from the entity's state on that day (asserted ones first, or the held ones and why each is not asserted). 'X vs Y revenue' compares two entities (against); 'before', 'formerly' give the history; 'as known on DATE' counts only what was public by then (held_back); 'how old', 'how long' add years. An entity on the record that lacks the fact gets kind 'gap' with what it does hold (coverage). Empty when the query is not such a question. Up to 300 characters. kind narrows to entities or claims; limit (default 20, max 50) applies to each; assertable_only drops claims the record does not assert from the lists.

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": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No	all (default), entities or claims
`limit`	No
`query`	Yes
`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
`assertable_only`	No

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

Behavior5/5

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

Annotations only declare read-only, closed-world, idempotent; the description goes far beyond that by disclosing result structure (slugs, matching claims with entity/predicate/value/date, days named), the answers-card shape with asserted-vs-held ordering, the 'gap' kind with coverage for entities lacking the fact, and the 'Empty when the query is not such a question' failure mode. It also explains limit applying per-list and assertable_only filtering, which an agent cannot infer from annotations.

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

Conciseness3/5

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

The core capability is front-loaded correctly, but the body is a single dense block with nested parentheses, stacked quoted examples and internal jargon (held_back, coverage, assertable_only) that forces re-reading. It is information-rich rather than padded, but bulleted or sentence-per-feature structure would make the same content far easier to parse.

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 five-parameter tool with no output schema, the description carries the return-shape burden thoroughly: it specifies the fields of matching claims, the composition of an answer card, and the error/empty condition. An agent could call this and interpret results without opening any other documentation.

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 40% schema coverage the description must compensate, and it largely does: kind is explained as narrowing to entities or claims, limit is clarified as applying to each list (default 20, max 50), assertable_only as dropping non-asserted claims from the lists, and the 300-character query cap is restated. detail is left to a rich schema-level description rather than repeated, which is reasonable but means one of five params gets no narrative support.

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 opens with a concrete verb+resource ('Find entities by name, slug, ticker or former name ... and claims by value, predicate, entity and date') and states what the output is for ('Returns slugs to use with the other tools'), so an agent can distinguish it from claim/entity_state/coverage. The only thing diluting it is the second advertised mode — full natural-language question answering — which makes it read as two tools in one rather than a single crisp search.

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?

Guidance is unusually explicit for query construction: search for the thing itself ('August 2026 spam update') rather than the product/ranking/company, read the date off the claim, use 'X vs Y' for comparisons, 'before'/'formerly' for history, 'as known on DATE' for time-bounded views. What's missing is an explicit when-not/switch rule naming sibling tools (e.g. use entity_state when you already have a slug), though 'use with the other tools' implies the handoff.

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?