OptimistFi

What changed recently

what_changed

Read-only

What changed for a company since a reader last looked — the catch-up surface.

Instead of re-reading a full brief, get only what LANDED since the reader was last shown this
company: the latest quarter's results (earnings, with the quarter's own figures), new filings, insider trades, 8-K news, corporate actions, and the price move across the
window. This is `get_company_brief` scoped to a window, with the window remembered per reader.

When a thesis exists, the response also does the EDITORIAL job in `data.editorial`: each
development is classified against the case (supporting / challenging / mixed / invalidating /
immaterial), the immaterial ones are set aside, and one unified story says whether the case still
holds. Absent a thesis it falls back to co-locating the case for the reader to weigh.

Two ways to scope the window, in order of precedence — pick whichever matches how the client
tracks identity:
  - `since` (an ISO date): an explicit window start. STATELESS — the client supplies the
    last-seen time (e.g. Perplexity passing the prior visit timestamp). Nothing is stored.
  - `user` (a stable, pseudonymous end-user id): STATEFUL. We look up when this user was last
    successfully shown this company and use that as the window start, then advance the stored
    baseline to today on a successful response — so the next call catches up from here.
  - Neither: a first-time reader with no history — defaults to the last 30 days.

The baseline advances ONLY on a successful response, so a failed call never skips the reader past
changes they never saw. `data.window` reports the resolved window and where its start came from
(`explicit` / `remembered` / `default`). `response_mode="plain"` compresses the window into a
beginner-friendly explanation; "raw" omits thesis/editorial interpretation; "standard" and
"deep" preserve the complete current response.

Input Schema

TableJSON Schema

Name	Required	Default
`user`	No
`since`	No
`entity`	Yes
`reading_level`	No
`response_mode`	No	standard

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4/5.0

Behavior1/5

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

The annotations declare readOnlyHint=true, but the description says the tool is STATEFUL and 'advance[s] the stored baseline to today on a successful response' — a stateful write. This is a direct contradiction with the read-only annotation, and per rubric a contradiction forces a score of 1 despite the description being otherwise transparent about the side effect.

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

Conciseness5/5

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

Front-loaded with a one-line purpose, then a scoped alternative, then editorial behavior, then bulleted window options. Every sentence adds information about statefulness, failure behavior, or response modes; the length is justified by the tool's complexity.

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 stateful, no-output-schema tool, the description is unusually complete: it explains window resolution sources (explicit/remembered/default), the success-only baseline advance, editorial classification output in data.editorial, and response_mode semantics. The only real gap is reading_level, which is not addressed anywhere and prevents a perfect completeness score.

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?

The input schema has no property descriptions, so the description carries the burden. It explains since, user, neither/default, and response_mode values in detail. However, reading_level is never mentioned, and entity is only implied by 'for a company,' leaving two of five parameters without explicit semantic coverage.

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 action and resource: 'What changed for a company since a reader last looked' and 'get only what LANDED since the reader was last shown this company.' It also names the sibling it is scoped from ('This is get_company_brief scoped to a window'), so an agent can distinguish it from get_company_brief and other list tools.

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?

Explicitly frames when to use it ('Instead of re-reading a full brief') and names the alternative tool (get_company_brief). It also gives precedence rules for since vs user and describes the default when neither is supplied, so selection logic is fully specified.

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

All OptimistFi 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?