Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Watchlist Diff

watchlist_diff

Read-onlyIdempotent

Return new SEC filings across a set of companies since a given date. Name the companies EITHER with name (a watchlist you have already saved) OR with tickers (a list you are holding right now) — pass exactly one. Use tickers for an ad-hoc question: there is no need to create a watchlist just to ask, and you should not, because a saved watchlist is a durable record in the user's account. Reads filing.parquet — does not call insider/ratio surfaces (use those tools separately if you need them). Scans at most 50 companies per call and reports truncated when you asked about more; batch a large universe rather than relying on the cap. A company whose read fails is named in tickers_failed, never silently reported as having filed nothing. NOT point-in-time: since bounds filing_date, not accepted_at.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Name of a watchlist the caller has already saved. Pass this OR `tickers`, never both.
`since`	Yes	Cutoff date (YYYY-MM-DD); the diff returns SEC filings whose filing_date is on or after this date.
`tickers`	No	Tickers or CIKs to scan, passed directly. Use this for an ad-hoc question — do NOT create a watchlist in order to ask one, since that writes a durable record into the user's account. Pass this OR `name`, never both.
`form_types`	No	Filing forms to include. Defaults to 10-K + 10-Q + 8-K.

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`since`	Yes
`filings`	Yes
`truncated`	Yes
`tickers_failed`	Yes
`watchlist_name`	Yes
`tickers_scanned`	Yes
`tickers_requested`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / properties / _meta / properties / fundamentals_as_of / description

Previous value: -"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt. Use THIS — not `last_updated` — when telling a user how current the fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to."New value: +"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt in bulk. Use THIS — not `last_updated` — when telling a user how current the cross-sectional fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to. It is a floor for a single filer, not a ceiling: a filer with a live partition receives its filing, facts and ratios intraday (minutes after EDGAR dissemination), so an entity-scoped read may carry a filing newer than this; cross-sectional ranks (factor scores, earnings signals) refresh with the weekly bulk export."

Changed9 schema fields changedSep 16, 2026

changedInput schema / properties / name / description

Previous value: -"Watchlist name."New value: +"Name of a watchlist the caller has already saved. Pass this OR `tickers`, never both."

changedInput schema / properties / since / description

Previous value: -"Cutoff date (YYYY-MM-DD); the diff returns SEC filings accepted on or after this date across the watchlist's tickers."New value: +"Cutoff date (YYYY-MM-DD); the diff returns SEC filings whose filing_date is on or after this date."

addedInput schema / properties / tickers

Added value: +{
+  "description": "Tickers or CIKs to scan, passed directly. Use this for an ad-hoc question — do NOT create a watchlist in order to ask one, since that writes a durable record into the user's account. Pass this OR `name`, never both.",
+  "items": {
+    "maxLength": 10,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / required

Previous value: -[
-  "name",
-  "since"
-]New value: +[
+  "since"
+]

addedOutput schema / properties / tickers_failed

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / tickers_requested
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / truncated
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / watchlist_name / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

changedOutput schema / required

Previous value: -[
-  "_meta",
-  "watchlist_name",
-  "since",
-  "tickers_scanned",
-  "filings"
-]New value: +[
+  "_meta",
+  "watchlist_name",
+  "since",
+  "tickers_scanned",
+  "tickers_requested",
+  "truncated",
+  "tickers_failed",
+  "filings"
+]

Changed2 schema fields changedJul 25, 2026

addedOutput schema / properties / _meta / properties / fundamentals_as_of

Added value: +{
+  "description": "ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt. Use THIS — not `last_updated` — when telling a user how current the fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to.",
+  "type": "string"
+}

addedOutput schema / properties / _meta / properties / price_as_of

Added value: +{
+  "description": "ISO timestamp when the price surfaces were last refreshed.",
+  "type": "string"
+}

Changed2 schema fields changedJul 7, 2026

addedOutput schema / properties / _meta / properties / cost_usd

Added value: +{
+  "additionalProperties": false,
+  "description": "Per-call cost transparency. Omitted for subscription-only tools that have no PAYG-equivalent price.",
+  "properties": {
+    "amount_usd": {
+      "minimum": 0,
+      "type": "number"
+    },
+    "basis": {
+      "description": "payg_charge = real agent-pay charge. payg_rate_card = indicative price, not billed.",
+      "enum": [
+        "payg_charge",
+        "payg_rate_card"
+      ],
+      "type": "string"
+    },
+    "billed": {
+      "description": "true = this amount was actually charged via PAYG for this call. false = indicative PAYG-equivalent value; your plan already covers this call for free.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "amount_usd",
+    "billed",
+    "basis"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / _meta / properties / latency_ms

Added value: +{
+  "description": "Wall-clock milliseconds this tool call took, measured server-side around the handler.",
+  "minimum": 0,
+  "type": "integer"
+}

Changed1 schema field changedJun 18, 2026
- addedOutput schema / properties / _meta / properties / pit_safe / description
```
Added value: +"true iff a zero-look-ahead point-in-time cut was applied to every returned figure"
```

Changed1 schema field changedJun 3, 2026

addedInput schema / properties / since / description

Added value: +"Cutoff date (YYYY-MM-DD); the diff returns SEC filings accepted on or after this date across the watchlist's tickers."

AddedMay 12, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds significant operational behaviors: the 50-company cap with `truncated` reporting, `tickers_failed` for failed reads never silently treated as no filings, and the non-point-in-time semantics where `since` bounds filing_date rather than accepted_at. This is exactly the kind of context that helps an agent avoid misusing the tool.

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?

The description is dense but every sentence earns its place: purpose is front-loaded, parameter guidance follows, and edge behaviors are compactly listed. There is no fluff or redundant restatement of the schema.

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?

The description covers the failure modes an agent must avoid: passing both name/tickers, creating watchlists unnecessarily, exceeding the 50-company cap, relying on point-in-time semantics, and misreading failures as no filings. With an output schema present, nothing critical for correct invocation is missing.

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?

Although schema coverage is 100%, the description adds the exactly-one rule between `name` and `tickers`, the durable-write warning against creating watchlists for ad-hoc queries, and the clarification that `since` is not point-in-time. These enrich the schema definitions rather than repeating them.

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 opening sentence, 'Return new SEC filings across a set of companies since a given date,' names a specific verb, resource, and date boundary. It further differentiates from sibling tools by noting it reads filing.parquet and does not call insider/ratio surfaces, making its scope unmistakable.

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?

The description explicitly tells the agent when to use `name` (an already-saved watchlist) versus `tickers` (an ad-hoc list), and warns not to create a watchlist just to answer one question because that writes a durable user record. It also directs the agent to use insider/ratio tools separately and to batch large universes instead of relying on the 50-company cap.

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

All Valuein — SEC EDGAR Fundamentals & Smart-Money Data 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.