Silicon Analysts

get_forecasts

Read-onlyIdempotent

Forecast Vintages — third-party forecasts (research firms like TrendForce/WSTS/SEMI, and company capex/bit-growth guidance) archived with their ORIGINAL publication date. Query the REVISION HISTORY, not just the latest number: "what did TrendForce say about 2026 HBM bit growth in January vs July?". Each row: originator, originator_type, metric, target_period (e.g. CY2026, 2027H1), value (num or low/high), unit, as_of (publication date), a source URL, and a verbatim quote. This is the vintage archive of OTHER organizations' forecasts — distinct from our own scenario models.

USE THIS for: forecast revision tracking, "how has the 2026 capex outlook moved across TSMC's earnings calls?", comparing what different firms projected for the same target period, building a consensus-vs-time view.

DO NOT USE for: current cost/pricing values (use get_wafer_pricing / get_accelerator_costs); Silicon Analysts' OWN frozen and graded projections (use get_track_record).

Filters: originator, originator_type (research_firm|company_guidance|government|bank|industry_body|other), metric, target_period, entity_id, limit (max rows). group='series' additionally returns a "chains" array — the rows already collapsed by originator + metric + target period, oldest print first, with the change between prints — which is usually what you want instead of reassembling them yourself. Latest slice for all tiers; full history (from/to/since/all/group=series) needs a free API key — anonymous callers get the latest slice with a note, never an error. Cite as "Silicon Analysts — Forecast Vintages".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No
`all`	No
`from`	No
`group`	No
`limit`	No
`since`	No
`metric`	No
`entity_id`	No
`originator`	No
`target_period`	No
`originator_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 30, 2026

addedInput schema / properties / group

Added value: +{
+  "enum": [
+    "none",
+    "series"
+  ],
+  "type": "string"
+}

AddedJul 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive status, but the description adds material behavior the annotations cannot express: full history requires a free API key, anonymous callers silently get the latest slice with a note and never an error, and group='series' changes the return shape by adding a chains array.

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?

Well front-loaded with a one-line identity statement, then labeled USE/DO NOT USE and Filters blocks that make scanning easy. It is on the long side and the citation instruction plus the quote/URL field enumeration add bulk, but nearly every sentence carries actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, no-output-schema tool the description is complete: it lists the row shape returned (originator, metric, target_period, value, unit, as_of, URL, quote), covers the auth fallback behavior, and clarifies the relationship to sibling tools. Nothing an agent needs to call it correctly is missing.

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?

With 0% schema description coverage, the description carries the full burden and mostly delivers: it enumerates originator, originator_type (with all enum values), metric, target_period, entity_id and limit, and explains group='series' in detail. What it does not adequately explain are from/to/since/all, which are only name-dropped as 'full history' without stating how each differs.

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 opening sentence names a specific resource (a vintage archive of third-party forecasts) and immediately scopes it: research firms, company capex/bit-growth guidance, archived with original publication dates. It explicitly distinguishes itself from sibling tools by name — get_wafer_pricing / get_accelerator_costs for current pricing, get_track_record for the company's own graded projections.

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

Usage Guidelines5/5

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

Explicit 'USE THIS for' and 'DO NOT USE for' blocks with concrete example queries, each paired with the alternative tool to use instead. The revision-history vs latest-number framing gives the agent a clear decision rule.

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

All Silicon Analysts tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?