Skip to main content
Glama
LuxAlgo

LuxAlgo Library MCP

Official
by LuxAlgo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Query a Market Trackers dataset

trackers_query

Search Market Trackers datasets by ticker, free text, exact field values, and event-date range; page results and order by newest or oldest. Each row links to its source SEC filing or record.

Instructions

Search one Market Trackers dataset by ticker, free text, exact field values, and event-date range, with paging and newest/oldest ordering. Data is read from year-sharded CC0 dumps: pass years (or since/until) to choose which years to read — default is the newest year with data. Deep-history years (see archiveYears in trackers_datasets) can be tens of MB compressed each, so read them one or two at a time; the tool refuses selections over its byte budget and says how to narrow. Every row carries provenance.sourceUrl (the SEC filing, disclosure, award, or record it came from). Examples: insider purchases at NVDA in 2024 → dataset insider-transactions, ticker NVDA, years [2024], where {code: 'P'}; a senator's trades → congress-trades, text 'Tuberville'; who lobbied on a bill → lobbying-filings, text 'H.R.1234'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrder by event date (default newest)
textNoCase-insensitive substring over the dataset's name/title fields (member, insider, issuer, recipient, registrant and client, sponsor, assignee, bill title, …); see textPaths in trackers_datasets
limitNoRows to return (default 25, max 100)
sinceNoEarliest event date (YYYY-MM-DD, YYYY-MM or YYYY), inclusive
untilNoLatest event date, inclusive
whereNoExact field matches by dot path, e.g. {"side":"buy"}, {"member.state":"CA"}, {"code":"P"}, {"formType":"4"}; string comparisons are case-insensitive, arrays match when any element does
yearsNoEvent years to read (max 8); default is the newest year with data. Prefer one year at a time for deep-history datasets.
offsetNoRows to skip, for paging (default 0)
tickerNoTrading symbol, case-insensitive (e.g. 'NVDA'); matches the dataset's ticker field(s). Only datasets flagged tickerSearchable carry tickers.
datasetYesDataset id, from trackers_datasets

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and exceeds it. It discloses the year-sharded CC0 data source, the default to the newest year, the byte-budget refusal behavior, the performance cost of deep-history years, and the presence of provenance.sourceUrl on every row. These are concrete behavioral traits an agent needs to anticipate outcomes.

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

Conciseness4/5

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

The description is long but every sentence earns its place: purpose, data source, performance caveat, provenance, and examples. It is front-loaded with the core capability, though slightly more verbose than a minimal definition would require; the density justifies the length for a 10-parameter tool.

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 complex query tool with 10 parameters and no output schema, the description supplies essential operational context: year selection mechanics, deep-history performance costs, refusal behavior, provenance, and worked examples. It does not detail the response shape beyond provenance.sourceUrl, but the input documentation and examples make correct invocation clear. This is near-complete, with only minor gaps around result formatting.

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%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining how years interact with year-sharding, the default behavior, the byte budget constraint, and by giving concrete query examples that map parameters to real cases (e.g., dataset insider-transactions, ticker NVDA, years [2024], where {code: 'P'}).

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 description opens with a specific verb and resource: 'Search one Market Trackers dataset', then enumerates the search dimensions (ticker, free text, exact field values, event-date range) and controls (paging, ordering). This makes the tool's purpose obvious and distinguishes it from metadata or convenience siblings like trackers_datasets, trackers_latest, and trackers_ticker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The three examples (insider purchases, senator trades, lobbying) imply concrete usage scenarios, and the reference to trackers_datasets for archiveYears is helpful. However, the description never explicitly contrasts this tool with trackers_latest or trackers_ticker, nor states when NOT to use it, leaving routing to alternatives implicit rather than explicit.

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

Deploy Server

Other Tools