Skip to main content
Glama

search

Read-onlyIdempotent

Search Silicon Analysts — returns up to 10 matching records as {results: [{id, title, url}]}: curated market datasets and their individual series (HBM contract $/GB by generation, DRAM/NAND pricing, TSMC wafer price history, CoWoS capacity and lead times, capex), the reference pages and tool domains behind them (wafer pricing by node, AI accelerator costs, foundry allocation, HBM market and qualification, fab capacity, packaging costs, forecast track record, what changed), and published analysis articles. Every url is a citable https://siliconanalysts.com page.

USE THIS for: connector hosts that only speak search + fetch — ChatGPT deep research and ChatGPT company knowledge — and any agent that needs to discover which record answers a free-text question before reading it with fetch.

DO NOT USE for: structured or filtered queries when you can call tools directly — the specialised tools (get_market_dataset, get_wafer_pricing, get_foundry_allocation, get_hbm_market_data, ...) take filters and return typed fields; search returns ids, titles and urls only, never values.

Deterministic keyword match over published catalogs (no live data read), identical for every tier. An empty or unmatched query returns {results: []}, not an error. Pass a result's id to fetch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesFree-text query, e.g. 'HBM3E contract price', 'TSMC N3 wafer price', 'CoWoS lead time'. Returns up to 10 records as {id, title, url}; pass an id to fetch for the full text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld=false, but the description adds behavior annotations cannot express: deterministic keyword matching, no live data read, identical results for every tier, and a documented empty-result contract ({results: []}, not an error). That is exactly the extra context the bar asks for.

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?

Front-loaded with purpose and result shape, then clearly block-structured by USE/DO NOT USE/behavior. It is longer than strictly necessary (some catalog enumeration is decorative), but every block carries routing or behavioral value.

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?

No output schema exists, so the description supplies the return shape, the 10-record cap, the empty-result semantics, and the follow-up chain (pass id to fetch). Combined with 22 sibling tools, this gives an agent everything needed to route correctly.

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?

Schema coverage is 100% and the single query parameter is already documented with examples and maxLength, so the baseline is 3. The description adds marginal value by restating the result contract and the id-to-fetch handoff, which slightly exceeds what the schema alone conveys.

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 states a concrete verb and resource (search across Silicon Analysts records) and names the exact result shape. It explicitly distinguishes itself from the many get_* siblings by scope: search returns ids/titles/urls only, never values.

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?

Unusually explicit: 'USE THIS for' names the target host class (search+fetch-only connectors, deep research) and 'DO NOT USE for' names the alternative (specialised tools like get_market_dataset, get_wafer_pricing) and the condition that selects them. Nothing is left to inference.

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.

Resources