Quarter-over-quarter 13F position deltas (alternative-data), sign preserved: positive = added, negative = trimmed. Call this when the user asks 'are institutions adding or dumping X?'; set min_pct (absolute change fraction, e.g. 0.5 = 50%) to drop noise.
| Name | Required | Description | Default |
|---|---|---|---|
| fund | No | ||
| limit | No | ||
| ticker | No | ||
| min_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does add value by explaining the sign convention (positive = added, negative = trimmed) and the QoQ time period, and it hints at noise reduction via min_pct. But it omits key traits such as what the output structure looks like, whether all parameters are optional, and any pagination/filtering behavior, leaving meaningful gaps.
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 two sentences long and front-loaded with the core meaning, followed by the usage trigger and parameter guidance. Every sentence contributes; there is minimal fluff. The parenthetical '(alternative-data)' is slightly extraneous but does not detract. It could be slightly tighter, but it is well-structured.
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?
There is no output schema, so the description should explain what the tool returns, but it does not. It also does not clarify the role of fund vs ticker, the default limit, or how optional parameters interact. For a tool with four optional parameters, the description only covers the core semantic and one parameter, leaving an agent uncertain about expected call patterns and response format.
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% for all 4 params, so the description must compensate. It does explain min_pct with a concrete example ('0.5 = 50%') and its purpose (drop noise), which is helpful. However, it does not explain the ticker, fund, or limit parameters at all; the reference to 'X' is only an implicit hint. With only one of four params clarified, the compensation is insufficient.
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 opens with a specific and precise statement: 'Quarter-over-quarter 13F position deltas (alternative-data), sign preserved: positive = added, negative = trimmed.' This clearly identifies the tool as a deltas/changes endpoint for 13F holdings, and the sign semantics remove any ambiguity. It also gives a concrete trigger question ('are institutions adding or dumping X?'), making the purpose unmistakable and distinct from raw 13F or history tools.
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 provides an explicit usage trigger: 'Call this when the user asks "are institutions adding or dumping X?"' and gives actionable guidance for min_pct ('set min_pct ... to drop noise'). However, it does not mention when not to use this tool or name alternative tools (e.g., tengu_v3_intel_sec13f or sec13f_history), so it falls short of the highest bar for alternatives/exclusions.
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.
