TickerDB

get_universe

Read-only

Get selected fields for EVERY asset on one date in a single call (about 11,000 rows), ordered by ticker: the input of a daily or weekly trading model run. Fields use the same names as get_search and are tier-gated the same way; at most 60 per call. Costs 5 credits per 10 fields. member_of / held_by restrict it to an index's or a fund's holdings on that date ("S&P 500 members with garp_core_score"). A row dated D reflects everything known by 04:00 UTC on D+1, so a backtest acts at the next session's open. For filtered or ranked subsets use get_search; for one ticker use get_summary.

Input Schema

Name	Required	Description
`date`	No	Date (YYYY-MM-DD). Omit for each asset class's newest published date. History depth depends on plan.
`fields`	Yes	Fields to return, e.g. ["trend_direction", "momentum_rsi_zone", "market_cap_usd"]. Same names and aliases as get_search; at most 60.
`held_by`	No	Only assets this fund held on each row's date: fund ticker (e.g. "IVV", "ARKK") or SEC series id (find with get_funds). Point in time like member_of.
`member_of`	No	Only members of this index on each row's date, e.g. "sp500", "nasdaq100", "russell2000" (list: get_indexes). Point in time: the tracking fund's N-PORT portfolio public on that date (typically 2-5 months old).
`timeframe`	No	daily, or weekly (Sunday-dated). Daily snapshots are Pro and Commercial only (Free and Plus read weekly; daily returns 403). Default: daily on Pro and Commercial, weekly on Free and Plus
`asset_class`	No	Only this asset class. Omit for all.

Output Schema

Name	Required	Description	Default
`data`	No	The TickerDB API response payload for this tool call.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026

addedInput schema / properties / held_by

Added value: +{
+  "description": "Only assets this fund held on each row's date: fund ticker (e.g. \"IVV\", \"ARKK\") or SEC series id (find with get_funds). Point in time like member_of.",
+  "type": "string"
+}

addedInput schema / properties / member_of

Added value: +{
+  "description": "Only members of this index on each row's date, e.g. \"sp500\", \"nasdaq100\", \"russell2000\" (list: get_indexes). Point in time: the tracking fund's N-PORT portfolio public on that date (typically 2-5 months old).",
+  "type": "string"
+}

changedInput schema / properties / timeframe / description

Previous value: -"daily, or weekly (Sunday-dated). Default: daily"New value: +"daily, or weekly (Sunday-dated). Daily snapshots are Pro and Commercial only (Free and Plus read weekly; daily returns 403). Default: daily on Pro and Commercial, weekly on Free and Plus"

AddedNov 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare read-only, open-world, non-destructive behavior, but the description adds substantial operational context: row count, ordering, tier gating, 60-field cap, 5 credits per 10 fields, and point-in-time lag (D+1 04:00 UTC; backtest acts at next open). These are material traits not captured by the annotations.

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?

Dense but front-loaded: the core scope appears first, followed by field/tier constraints, costs, and alternatives. Every sentence carries operational information, and neither ordering nor phrasing wastes space.

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?

With a rich input schema, annotations, and an output schema, the description fills the remaining gaps an agent needs: cost model, row volume, field limits, point-in-time interpretation, and sibling routing. Nothing essential for correct invocation is missing.

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 description coverage is 100%, establishing a baseline of 3. The description still adds meaning by tying fields to get_search names/aliases and tier gating, and by giving a concrete member_of example, though most per-parameter details remain in the schema.

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 and resource: get fields for EVERY asset on one date, ordered by ticker, around 11,000 rows. It explicitly distinguishes itself from get_search for filtered/ranked subsets and get_summary for one ticker.

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?

Gives clear when-to-use context (input of a daily/weekly trading model run) and names alternatives with conditions: get_search for filtered or ranked subsets, get_summary for one ticker. It also explains member_of/held_by restriction semantics with an example.

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

All TickerDB 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.