FilingDelta

List coverage and prices

list_filers

Read-onlyIdempotent

Free. Call first: the current coverage list (SEC filers, central banks, US macro and CPI ids, bundles) with prices, payTo, card dates and content hashes. Compact by default (ids, prices, as_of, content_hash); pass full: true for the whole /catalog. Tickers: AMD, MRVL, NVDA, AVGO, TSM, MU, AMAT, AAPL, MSFT, META, TSLA, ORCL, INTC, ASML, MSTR, JPM, BAC, GS, WFC, NFLX, JNJ, BRK, PLTR, SPCX, GOOGL, LLY, LRCX, BA. Policy ids: BOE, FED, ECB, BOJ, RBA, BOC, SNB, NOR, SWE, MEX, BOK, TUR, IND, ZAF, CHN, IDN, ETH, RUS, EGY, IRN, BCB, NZL. Macro ids: NFP, GDP, CPI. CPI ids: US, UK, EA, JP. Bundles: SEMIS, CENTRALBANKS, BRICS.

Input Schema

Name	Required	Description	Default
`full`	No	true returns the full /catalog JSON; default false returns the compact list

Output Schema

Name	Required	Description	Default
`asset`	No
`cards`	Yes
`macro`	No
`payTo`	No
`filers`	Yes
`policy`	Yes
`bundles`	No
`network`	No
`service`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

addedInput schema / properties / full

Added value: +{
+  "description": "true returns the full /catalog JSON; default false returns the compact list",
+  "type": "boolean"
+}

Changed1 schema field changedOct 14, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "asset": {
+      "type": "string"
+    },
+    "bundles": {
+      "type": "array"
+    },
+    "cards": {
+      "type": "array"
+    },
+    "filers": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "macro": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "network": {
+      "type": "string"
+    },
+    "payTo": {
+      "type": "string"
+    },
+    "policy": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "service": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "filers",
+    "policy",
+    "cards"
+  ],
+  "type": "object"
+}

First observedOct 13, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the description rightly spends its words elsewhere: it is free, it exposes payTo/card dates and content hashes, and default output is a compact projection vs. full: true returning the whole /catalog. It doesn't mention rate limits or response size, which would complete the picture.

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 is front-loaded and tight (free, call first, compact vs full). However, three long enumerations of tickers, policy ids, CPI ids and bundles consume most of the text and are catalog data an agent learns from the response itself, so they crowd out behavioral guidance.

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?

An output schema exists, so return values need not be explained, yet the description still names the compact field set. With one optional param, full annotation coverage and a cheap read, an agent has everything needed to call it correctly; only pagination/response-size behavior is absent.

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% and the single param is already documented, so the baseline is 3; the description adds real meaning by naming the exact fields the compact mode returns (ids, prices, as_of, content_hash) versus the full catalog. That is incremental value beyond the property description, though not exhaustive.

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 verb+resource (list the current coverage catalog) and immediately scopes what's inside: SEC filers, central banks, macro/CPI ids, bundles, with prices and hashes. An agent can distinguish this from search_coverage or the get_* fetchers without opening the 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?

"Free. Call first" gives an explicit entry-point signal, which is the key routing decision for this catalog's siblings. It does not name search_coverage as the alternative when looking for one specific id, so exclusions are implied rather than stated.

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

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