Private peer set for one company: same industry sector and similar size band (0.2x-5x total raised), excluding the company itself. Call this when the user asks 'who are X's private comps' or needs a peer group for valuation framing; detail=full returns every column per peer.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | lean | |
| fields | No | ||
| company_id | Yes | Path parameter 'company_id' (required). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds useful context: the peer selection criteria (same sector, 0.2x-5x total raised, excludes itself) and the behavior of 'detail=full returns every column per peer'. However, it doesn't disclose potential side effects (likely read-only), rate limits, or whether it returns paginated results or errors for unknown companies. Given the absence of annotations, a score of 3 is appropriate for partial transparency.
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?
Two dense sentences: first defines the output precisely, second tells when to use it and what detail=full does. Every word earns its place; no padding or repetition. Front-loaded with the core purpose.
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?
No output schema exists, so the description should explain return shape. It mentions 'every column per peer' for detail=full, but doesn't describe the lean return or whether the response includes identifiers, metrics, or pagination. It's reasonably complete for a simple lookup given the strong sibling context (private_markets_company_* tools), but not fully complete for an AI agent needing to parse output without examples.
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 only 25% (only company_id has a description that just repeats 'Path parameter'). The description adds meaning for 'detail' (explains full vs lean) and clarifies the tool's core concept, but leaves 'limit' and 'fields' to be inferred. For 4 params with low schema coverage, the description partially compensates but doesn't document all parameters. Since the schema is sparse, the description's explanation of detail and the overall purpose earns a 4.
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 states a specific verb ('Call this when'), resource ('Private peer set for one company'), and defines the scope precisely ('same industry sector and similar size band 0.2x-5x total raised, excluding the company itself'). It distinguishes from sibling tools like tengu_v3_fundamentals_peers and other private_markets_company_* tools by focusing on comparables for valuation.
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?
Explicitly says when to use: 'when the user asks who are X's private comps or needs a peer group for valuation framing'. It contrasts with the generic private_markets_company tool and provides a concrete trigger. It doesn't name an alternative tool explicitly, but the trigger context is clear enough; it also explains the 'detail=full' parameter usage.
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.
