Skip to main content
Glama

tengu_v3_features_dataset

READ ONE DERIVED FEATURE PANEL — the model-ready research features this platform computes for itself: price/return and liquidity features, monthly fundamentals, analyst-estimate dynamics, options and volatility-surface features, insider and institutional-ownership features, news-sentiment features, betas, regime and macro features. Discover the slugs via /api/v3/features/datasets — they are product names, not table names. With ?ticker= you get that symbol's observations newest first; without it you get the LATEST cross-section (every symbol on the most recent observation date), which is bounded by construction rather than by sorting the whole panel. Symbols resolve through the shared security resolver first and identity.identity_verified states whether the read was keyed on an authoritative identifier or on the resolved security's symbol; an ambiguous symbol is refused, never guessed. Every response carries the dataset's measured coverage (rows_total, symbols_total, observation_dates, history window) and its freshness, so an empty rows array arrives beside the count of symbols that DO have rows and can never be read as a dead upstream — result is the machine-readable outcome (rows, no_rows_for_symbol, no_rows_in_window). Five of the 19 servable datasets are archival: their producer has stopped, they are served for their history, and every response says so rather than implying currency. An unknown or withheld slug is a 404 and an unreadable store is a 503 — both refunded, because a billed 200 over an empty array is the defect this endpoint exists to remove.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
sinceNo
untilNo
tickerNo
datasetYesPath parameter 'dataset' (required).

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 full responsibility and does an excellent job. It discloses response structure (coverage fields, result values), edge cases (empty rows vs. symbols_with_rows), archival dataset behavior, and error handling with refunds (404/503). It also explains that ambiguous symbols are refused, never guessed.

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 a dense single paragraph that front-loads the main purpose. While long, nearly every sentence adds valuable operational detail (coverage, freshness, errors, archival). It could be better structured with breaks, but it is appropriately sized for the 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?

Given no output schema, the description thoroughly explains the response envelope: coverage fields, freshness, result outcomes, row arrays, and error codes. It also covers the two data retrieval modes and the archival distinction. The only significant gap is the lack of explanation for limit/since/until, which are part of the input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, so the description must compensate. It explicitly explains the dataset parameter (slugs are product names, discoverable via /api/v3/features/datasets) and the ticker parameter (two modes). However, it does not address the limit, since, or until parameters at all, leaving their semantics to inference.

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 clear verb and resource: 'READ ONE DERIVED FEATURE PANEL' and then enumerates the feature families (price/return, liquidity, fundamentals, etc.). It distinguishes this from siblings by emphasizing 'model-ready research features' and directing to /api/v3/features/datasets for slug discovery, clarifying this is the read endpoint for feature panels.

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?

It provides clear usage context: with ?ticker= you get per-symbol observations newest first; without it you get the latest cross-section. It also explains how to discover valid dataset slugs. However, it does not explicitly compare to alternatives or state when not to use this tool, though the purpose is distinct enough.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.9/5.0
Disambiguation2/5

With 336 tools, there is substantial overlap. Over a dozen health/status tools share nearly identical 'is the system healthy?' descriptions (e.g., tengu_status, tengu_ready, tengu_ml_health, tengu_v3_system_health, tengu_v3_stream_status), and multiple single-ticker analysis (tengu_ml_predict, tengu_copilot_score_ticker, tengu_v3_intel_ml_prediction) and top-picks (tengu_copilot_top_picks, tengu_ml_top_picks, tengu_v3_trade_setups) tools have poorly defined boundaries. Agents would frequently misselect.

Naming Consistency2/5

The server mixes no-version (tengu_crypto), v2 (tengu_v2_drift), v3 (tengu_v3_intel_*), and copilot (tengu_copilot_*) families, and within families there is inconsistent verb/noun ordering (tengu_v3_research_fetch_url vs tengu_v3_news_summary). While subfamilies like tengu_v3_private_markets_* are internally consistent, the overall naming pattern is chaotic and unpredictable.

Tool Count1/5

336 tools is far beyond any reasonable tool set size, even for an all-in-one financial data platform. This extreme count creates choice paralysis, high latency in tool selection, and makes the server effectively unusable for autonomous agents. The calibration guideline marks 50+ as extreme; this is nearly 7x that threshold.

Completeness4/5

The platform covers a vast domain: equity and crypto prices, fundamentals, insider trading, options, news (including crypto and FX), private markets, streaming data, risk metrics, and execution planning. There are minor gaps (no direct multi-ticker comparison tool, no order placement), but the surface is remarkably comprehensive for an analysis-focused server.