MARKET-WIDE ONLY — never for one ticker's news (that is tengu_v3_news_summary). Live cross-publisher newswire headlines: headline, publisher, tickers, is_major flag, feed-supplied sentiment; seconds-fresh, 120s cache. For 'what's happening in the market right now?' scans and cross-ticker sweeps.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ticker | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals live streaming, a 120-second cache, the exact data fields (headline, publisher, tickers, is_major flag, sentiment), and notes the sentiment is feed-supplied. This goes beyond a simple statement of purpose. It does not describe error behavior or rate limits, but the key operational traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently structured. It front-loads the most critical constraint ('MARKET-WIDE ONLY') in caps, provides a brief list of returned fields, and states freshness and cache behavior in a single, readable sentence. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description provides a solid overview of the tool's data contents, freshness, and use cases. The main gap is the unexplained 'ticker' parameter and lack of explicit mention of whether results are sorted or how many are returned (though the schema gives a limit). For a news headline tool with many siblings, this is mostly complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It does not explain the 'ticker' parameter at all, and its 'MARKET-WIDE ONLY' statement creates ambiguity about whether ticker is for filtering or should be left unused. The 'limit' parameter is self-explanatory from the schema, but the description adds no clarity to the semantics of the remaining parameter and even introduces contradiction with the market-wide claim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Live cross-publisher newswire headlines.' It explicitly defines the market-wide scope and distinguishes itself from the sibling tool 'tengu_v3_news_summary' for per-ticker news. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('MARKET-WIDE ONLY') and when NOT to use it ('never for one ticker's news'), pointing to the alternative ('that is tengu_v3_news_summary'). It also provides concrete use cases ('what's happening in the market right now?' scans and cross-ticker sweeps), making the decision boundary crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
