Silicon Analysts
Server Details
Semiconductor data: AI accelerator costs, HBM, wafer pricing, packaging, chip cost calculator.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 9 of 9 tools scored.
Each tool targets a distinct aspect of semiconductor analysis (hypothetical cost, existing chip costs, foundry allocation, HBM market, HBM qualification, market news, packaging costs, recent changes, wafer pricing). Descriptions explicitly clarify which tool to use and which not to use, minimizing confusion.
Most tools follow a 'get_{plural_noun}' pattern (get_accelerator_costs, get_foundry_allocation, etc.), but 'calculate_chip_cost' deviates with a different verb, and 'get_recent_changes' uses a plural noun while others are singular in concept. The pattern is mostly consistent but has minor irregularities.
With 9 tools, the server covers a broad domain (cost estimation, market data, allocation, packaging, recent changes) without being overwhelming or sparse. Each tool serves a clear purpose and is justified.
The tool set provides comprehensive coverage for semiconductor cost modeling and market analysis: hypothetical and actual chip costs, foundry allocation, HBM market and qualification, packaging costs, wafer pricing, market news, and data changes. No obvious gaps for its intended use.
Available Tools
15 toolscalculate_chip_costAInspect
Pure-function chip cost estimator. Given die dimensions (mm), process node, and optional packaging/HBM parameters, returns: estimatedChipCost (USD), dieArea (mm²), grossDiesPerWafer, frontendYield (%), totalYield (%), and a costBreakdown {waferCostPerGoodDie, packagingAndTestCost, hbmCost, marginCost}.
USE THIS for: hypothetical chip cost modeling, sensitivity analysis, fabless tapeout decisions.
DO NOT USE for: published cost of an existing accelerator (use get_accelerator_costs); wafer pricing only (use get_wafer_pricing).
Required: dieWidth, dieHeight (1–33 mm reticle limit). Errors with INVALID_PARAMS if outside bounds. processNode defaults to tsmc-n5; valid nodes via get_wafer_pricing. Estimates are directional ±15–20%.
Optional energy adder: pass energyRegion (texas|ohio|arizona|china|korea|taiwan|germany) to get a conditional energy block — regional manufacturing-electricity cost per die (SA estimate; wafer price already embeds foundry energy, so treat it as a scenario delta). energyFacilityOverhead=false drops the ~1.75× facility multiplier.
Optional substrate scenario: pass substrate=panel-310x310 to model CoPoS panel-level assembly — applies the midpoint of Yole's realistic 20–30% panel cost-savings band to the packaging cost ONLY (silicon GDPW unchanged; panels are back-end). Conditional substrateScenario block + SA-scenario meta note. TSMC CoPoS: pilot ~June 2026, mass production 2028–29 — a forward-looking scenario, not a quote.
| Name | Required | Description | Default |
|---|---|---|---|
| volume | No | ||
| hbmCost | No | ||
| dieWidth | Yes | ||
| testCost | No | ||
| dieHeight | Yes | ||
| hbmStacks | No | ||
| substrate | No | ||
| waferCost | No | ||
| yieldModel | No | ||
| processNode | No | ||
| backendYield | No | ||
| energyRegion | No | ||
| marginTarget | No | ||
| defectDensity | No | ||
| packagingCost | No | ||
| packagingType | No | ||
| kgdTestCoverage | No | ||
| energyFacilityOverhead | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the tool's pure-function nature, error handling (INVALID_PARAMS for out-of-bounds inputs), accuracy range (±15-20%), default values, and detailed behavior for optional parameters like energyRegion and substrate. This fully compensates for missing annotations.
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 well-structured with clear sections and front-loaded purpose. It is information-dense but slightly lengthy; however, every sentence adds value. A minor reduction in detailed scenario explanations could improve conciseness.
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?
The description covers the core functionality and key optional parameters well, but given the tool's complexity (18 params, no output schema, no annotations), it fails to document many parameters, leaving gaps. Completeness is adequate for the primary use case but not comprehensive.
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%, and the description only explicitly explains a minority of the 18 parameters (e.g., dieWidth, dieHeight, processNode, energyRegion, substrate). Many parameters like volume, waferCost, yieldModel, backendYield, and others are not mentioned, leaving significant semantic gaps.
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 its purpose as a 'Pure-function chip cost estimator' with specific inputs and outputs. It explicitly distinguishes itself from sibling tools by listing when not to use it and suggesting alternatives like get_accelerator_costs and get_wafer_pricing.
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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections, providing clear context on appropriate use cases and directing users to alternative tools for other needs. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_lead_timeAInspect
Heuristic chip manufacturing LEAD TIME estimator (MANUFACTURING CYCLE TIME). Given total mask layers (or a processNode to default them), foundry utilization % (optional — defaults from live foundry-allocation data), and packagingType, returns min/max bands: fabDays, fabWeeks, packagingWeeks, totalWeeks, plus effectiveDpml (days per mask layer), the operating-curve weight, a resolved-inputs echo, assumptions, methodology, and public-source citations.
USE THIS for: "how long to manufacture this chip" — wafer-fab cycle time + packaging assembly/test time for hypothetical chips; cycle-time sensitivity to fab utilization or packaging class (conventional vs flip-chip vs CoWoS).
DO NOT USE for: booking windows / allocation lead time — how long until a booked-out foundry STARTS wafers, publicly 52–156+ weeks at N3-class nodes and CoWoS (use get_foundry_allocation); chip cost (use calculate_chip_cost / get_accelerator_costs).
Provide maskLayers (integer 10–200) or processNode (tsmc-n3 | tsmc-n5 | tsmc-n7 | tsmc-28 | samsung-3nm | samsung-5nm | intel-16). packagingType accepts coarse classes (conventional | flip-chip | cowos, default flip-chip) or any platform packaging id (fc-bga, wirebond-bga, cowos-l, copos, ...). Utilization ≤80% settles at the best-case band; ≥95% converges to the worst-case bound (FabTime operating-curve shape). Heuristic from public DPML benchmarks — directional, confidence LOW, not a foundry quote. Cite as "Silicon Analysts — Lead Time Estimator".
| Name | Required | Description | Default |
|---|---|---|---|
| maskLayers | No | ||
| processNode | No | ||
| utilization | No | ||
| packagingType | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states it is a heuristic from public DPML benchmarks with low confidence, not a foundry quote, and includes methodology and citation. No contradictions.
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 long but well-structured, front-loading purpose and then detailing parameters and usage guidelines. Every sentence adds value, though some redundancy could be trimmed.
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?
Despite no output schema, the description details return fields (min/max bands, effectiveDpml, etc.) and covers assumptions, methodology, citations. Complete for a complex heuristic tool.
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%, but the description compensates by explaining each parameter: maskLayers/processNode, utilization optional with defaults, packagingType with defaults and examples. Provides context like effect of utilization on output.
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 is a 'Heuristic chip manufacturing LEAD TIME estimator' and specifies the output (min/max bands for fab days, weeks, etc.). It distinguishes from siblings by providing explicit DO NOT USE scenarios.
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?
Provides explicit 'USE THIS for:' and 'DO NOT USE for:' sections, listing specific scenarios and alternatives like get_foundry_allocation and calculate_chip_cost. Also explains how utilization parameter affects output (≤80% best case, ≥95% worst case).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accelerator_costsAInspect
Returns 13 specific AI accelerators (H100/H200/B100/B200/GB200, MI300X/MI355X, Gaudi 3, TPU v5p, Trainium 2, Maia 100, MTIA v2) with structured fields: chip, vendor, processNode, dieSizeMm2, memoryType, memoryCapacityGb, memoryBandwidthTbS, fp8TflopsSparse, bf16TflopsDense, packageType, estMfgCostUsd, estSellPriceUsd, chipGrossMarginPct, costBreakdown.{logicDie, hbm, packaging, testAssembly}, interconnect.
USE THIS for: comparing manufacturing cost or sell price across vendors; looking up published specs of a specific shipping accelerator.
DO NOT USE for: chips not yet shipping (use get_market_pulse for forecasts); custom chip cost modeling (use calculate_chip_cost); HBM market dynamics (use get_hbm_market_data).
Filters: vendor (enum), chip (substring match), fields (projection list). Returns empty array if filters match nothing — does not error. Each chip record carries provenance.last_updated; data refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| chip | No | ||
| fields | No | ||
| vendor | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns an empty array with no error on no-match, mentions monthly data refresh and provenance.last_updated. It implicitly suggests read-only behavior but could explicitly state read-only/no-side-effects.
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 economical, front-loading the return structure, followed by usage guidelines, then filter behavior. Every sentence adds value, no redundancy.
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 no output schema, the description fully enumerates all return fields, covers parameter semantics, usage boundaries, and data refresh policy. It is complete for the tool's complexity and sibling context.
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%, but the description explains chip as substring match, fields as projection list, and vendor enum values. This adds significant meaning beyond the bare schema.
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 it returns 13 specific AI accelerators with structured fields. It uses a specific verb 'Returns' and resource 'AI accelerators', and distinguishes from siblings by listing explicit alternatives for other use cases.
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 explicit 'USE THIS for' and 'DO NOT USE for' guidance, naming specific alternative tools (get_market_pulse, calculate_chip_cost, get_hbm_market_data) and contexts, leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_benchmark_historyAInspect
Historical Benchmarks — the bitemporal benchmark-observations ledger behind the Chip Cost Calculator: wafer cost by node/foundry (deflationary curves), defect-density (D0) learning curves per node, advanced-packaging costs incl. the broken-out CoWoS interposer entity, test cost, backend yield, and HBM $/GB. Each observation carries as_of (the date the reading reflects — curated backfill from dated public archives extends history), detected_at (capture time), and full sourcing metadata (source_type taxonomy: foundry_ir | wfe_vendor_earnings | government_filing | press_release | analyst_report | company_announcement | trade_press | public_web; source_url; confidence high/medium/low). grain=month|quarter returns median/min/max rollups per period; grain=raw returns per-source observations. PRO/ENTERPRISE keys only.
USE THIS for: "how has TSMC N5 wafer pricing moved over 24 months?", "is our internal D0 ramp tracking the market's learning curve?", "CoWoS interposer cost trend", benchmarking product-lifecycle cost projections.
DO NOT USE for: current point values (use get_wafer_pricing / get_packaging_costs); the daily PIT ledger replay (use /api/v1/snapshot-series); margin history (use /api/v1/margin-trends).
Filters: benchmark_type (required: wafer_cost|defect_density|packaging_cost|interposer_cost|test_cost|backend_yield|hbm_cost_per_gb), entity_id, foundry, from/to (as_of bounds), grain (raw|month|quarter), limit. Cite as "Silicon Analysts — Historical Benchmarks".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| grain | No | raw | |
| limit | No | ||
| foundry | No | ||
| entity_id | No | ||
| benchmark_type | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the temporal nature (as_of and detected_at), grain options, sourcing metadata, and confidence levels. It mentions that backfill extends history and that PRO/ENTERPRISE keys are required. However, it does not explicitly state that the tool is read-only or non-destructive, though this is implied. Still, it provides rich behavioral context.
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 detailed but concise for the amount of information it conveys. It uses clear section markers ('USE THIS for:', 'DO NOT USE for:', 'Filters:', 'Cite as:') which improve structure. The initial sentence is dense but effectively summarizes the tool's scope. Some minor redundancy could be trimmed, but overall it's well-organized.
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 tool's complexity (7 parameters, no output schema, no annotations), the description is remarkably complete. It explains the purpose, use cases, alternatives, filter semantics, output structure, and even citation formatting. No critical information is missing for an AI agent to correctly select and invoke the tool.
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 compensate. It explains all main parameters: benchmark_type (required with enum values), from/to (as_of bounds), grain (raw/month/quarter), limit, entity_id, foundry. It also describes the output fields and their meanings. While it doesn't cover pattern constraints (those are in the schema), it adds significant semantic value beyond the schema.
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 purpose: 'Historical Benchmarks — the bitemporal benchmark-observations ledger behind the Chip Cost Calculator'. It specifies the resource (benchmark history) and the verb (get) implicitly. It distinguishes from siblings by listing specific use cases and explicitly naming sibling tools to avoid confusion.
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 explicit usage guidance with 'USE THIS for:' and 'DO NOT USE for:' sections, listing concrete examples and alternative tools. It also specifies required filters and access restrictions (PRO/ENTERPRISE keys only), making it clear when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fab_capacityAInspect
Fab Capacity — per-fab, per-tech-node-class capacity from the fabs + fab_capacity_snapshots time-series (65 fabs: TSMC, Samsung, Intel, SMIC, GlobalFoundries, and more; Frontend in kwspm, Backend advanced-packaging in k units/month). Default mode returns the LATEST state per (fab, node class) at/before as_of, joined with fab metadata (name, foundry, country, status) and availability_status (fully_booked → available). series=true returns the full dated series — node conversions appear as capacity shifting between node-class rows across effective_dates (e.g. 28nm shrinking while 7nm grows). Every reading carries sourcing metadata (foundry_ir / wfe_vendor_earnings / government_filing taxonomy + citation + confidence) and is_projection for forward-looking guidance. Latest state: all keys. series=true: PRO/ENTERPRISE keys only.
USE THIS for: "what is TSMC's 3nm-class installed capacity by fab?", "which fabs are fully booked?", "how is Fab 14's mature-node capacity being converted over time?", country-level capacity aggregation.
DO NOT USE for: node-level annual wafer starts (use get_wafer_pricing's foundry context or /api/v1/foundry endpoints — different granularity, deliberately separate); allocation/lead-time status per node (use get_foundry_allocation).
Filters: fab_id, foundry, country, tech_node_class, as_of (latest-state cutoff), series (bool), limit. Cite as "Silicon Analysts — Fab Capacity".
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| limit | No | ||
| fab_id | No | ||
| series | No | ||
| country | No | ||
| foundry | No | ||
| tech_node_class | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: default returns latest state, series=true returns full dated series, includes metadata and sourcing details, and notes access restrictions (PRO/ENTERPRISE keys for series). Missing only a note on idempotency or side effects, but as a read-only tool this is sufficient.
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 well-structured, front-loaded with summary, then details, usage guidance, and filters. Every sentence is informative with no redundancy. Long but efficient.
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 no output schema, no annotations, and 0% schema parameter descriptions, the description provides complete context: return values, data sources, access restrictions, and clear usage guidance. Fully compensates for lack of structured metadata.
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 coverage is 0%, so description must compensate. It lists all filters and explains their purposes (as_of as cutoff, series as boolean for time-series, limit count). However, lacks detailed validation constraints like patterns for fab_id, but provides enough semantic context for correct use.
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 returns per-fab, per-tech-node-class capacity from time-series data, and distinguishes from siblings by explicitly stating 'USE THIS for' and 'DO NOT USE for' with alternative tool names.
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?
Provides explicit use cases and exclusion cases, naming specific sibling tools (get_wafer_pricing, get_foundry_allocation) for different granularity, making it very clear when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_foundry_allocationAInspect
Foundry & advanced-packaging ALLOCATION — the current-state snapshot per node/tech (TSMC/Samsung/Intel/... × N2/N3/CoWoS-L/SoIC/...) plus optional time-series HISTORY. Current fields: allocation_status (fully_booked → available), lead_time_weeks_min/max + trend, utilization, price_trend, geo_risk, customers, capacity_current/target, customer_shares, allocation_note. With include_history=true, returns the tracked series from capacity_signals: lead_time / booking-window, pct_locked (%-capacity-locked), customer_allocation (publicly-reported per-customer share), cowos_capacity, foundry_utilization — each point dated (as_of) with provenance. No competitor publishes allocation as a structured, queryable feed.
USE THIS for: "who has CoWoS allocation and how much?", "what's the booking lead time for N2?", "how locked is 2026 CoWoS capacity?", allocation/lead-time trend over time.
DO NOT USE for: per-chip cost (use get_accelerator_costs / calculate_chip_cost); HBM market share/pricing (use get_hbm_market_data); HBM qual status (use get_hbm_qualification).
Filters: foundry, node, category, customer, history_metric, include_history (bool), limit. Sourced public estimates (analyst/press/earnings), human-reviewed; every record carries provenance.confidence_tier. wafer_price is intentionally omitted. Cite as "Silicon Analysts — Foundry Allocation".
| Name | Required | Description | Default |
|---|---|---|---|
| node | No | ||
| limit | No | ||
| foundry | No | ||
| category | No | ||
| customer | No | ||
| history_metric | No | ||
| include_history | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It transparently states data sources (public estimates, human-reviewed), provenance tracking, and intentional omission of wafer_price. It implies read-only behavior but does not explicitly declare destructiveness or lack thereof. Overall, it provides good behavioral context beyond the minimal schema.
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 relatively long but well-structured: a lead sentence, field list, usage guidelines, filter list, and sourcing info. It is front-loaded with the key purpose and uses bullet-like formatting. A few sentences could be trimmed without losing meaning, but it is organized and informative.
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 tool has 7 parameters, no output schema, and no annotations, the description covers the data returned, usage context, and data quality. It explains the return fields and sourcing. It does not describe the return structure (e.g., JSON format), which might be needed for full completeness, but it is otherwise comprehensive for an agent to use this tool effectively.
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 compensate. It lists the seven filter parameters (foundry, node, etc.) and provides context through usage examples (e.g., 'what's the booking lead time for N2?'). However, it does not explain each parameter's meaning or format in detail, leaving some ambiguity for an agent.
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 provides current allocation snapshot and optional history for foundries/advanced packaging, with a specific verb 'get' and resource 'foundry allocation'. It distinguishes from siblings by explicitly listing alternative tools for related queries (e.g., per-chip cost, HBM data).
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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections, providing concrete query examples and naming the correct sibling tools (get_accelerator_costs, get_hbm_market_data, etc.), making it unambiguous when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_foundry_economicsAInspect
Foundry IR ECONOMICS — per-foundry, per-process-node, per-fiscal-quarter wafer ASP (min/max/blended, USD per 300mm-equivalent wafer, $250-grained) and fab UTILIZATION (%), derived exclusively from PUBLIC IR materials (earnings releases/transcripts/decks, trade press) via a documented scaling calculation (rev-mix-v1): reported revenue × reported node revenue-shares × reported wafer shipments, allocated on pinned analyst prior ratios. Covers tsmc | umc | intel | samsung | smic | gf. Every row carries source_urls + release_dates + confidence (high/medium/low); utilization is 'stated' (company said it — UMC/SMIC style) or 'derived' (shipments vs capacity estimate, capped medium) and NEVER fabricated per node. include_facts=true returns the underlying evidence facts (verbatim quote + source per datum).
USE THIS for: "what does a TSMC 3nm wafer sell for and how has it moved by quarter?", "TSMC blended ASP trend", "UMC utilization last quarter", "N3 share of TSMC revenue over time", node-economics history for models.
DO NOT USE for: the current spot wafer price band only (use get_wafer_pricing — that is the live analyst-consensus band this dataset cross-validates against); allocation/lead-time/booking (use get_foundry_allocation); chip-level cost (use calculate_chip_cost / get_accelerator_costs).
Filters: foundry, node (canonical token, e.g. n3 | 22-28nm | 18a), node_group (leading_3nm | class_5nm | ...), quarter (2026Q1 | 2025FY), from/to range, include_facts, limit. LATEST period per foundry is free; multi-period HISTORY (quarter/from/to) requires a Pro key — free callers are clamped to latest with an explanatory meta.note (never an error). Sparse-disclosure foundries (Intel, Samsung) return nulls/low confidence rather than invented numbers. Refreshes weekly (Mon 14:30 UTC) + each earnings season. Cite as "Silicon Analysts — Foundry IR Economics".
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| node | No | ||
| limit | No | ||
| foundry | No | ||
| quarter | No | ||
| node_group | No | ||
| include_facts | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses data sources, calculation methodology, confidence levels, handling of sparse-disclosure foundries (nulls/low confidence), refresh schedule, and access restrictions (Pro key for history, free clamped to latest with meta.note). It also explains that utilization can be 'stated' or 'derived' and is never fabricated.
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 well-structured with clear sections (intro, use cases, exclusions, filters, notes). It front-loads the main purpose and each sentence adds value. Slightly verbose but justified by complexity; still very effective.
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 8 parameters, no output schema, and moderate complexity, the description completely covers input semantics, output content (rows with source_urls, confidence, etc.), access limitations, data freshness, and what the tool does not do. It is comprehensive and leaves no major gaps.
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 compensate. It explains filters (foundry, node, node_group, quarter, from/to, include_facts, limit) and their semantics (e.g., include_facts returns evidence, from/to for history, quarter pattern). However, it could be more precise about pattern constraints (e.g., limit max) and does not explicitly describe the 'to' parameter meaning.
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 it provides per-foundry, per-process-node, per-fiscal-quarter wafer ASP and fab utilization derived from public IR materials. It explicitly lists covered foundries and distinguishes from siblings like get_wafer_pricing and get_foundry_allocation.
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 includes explicit 'USE THIS for' and 'DO NOT USE for' sections with example queries and specific alternatives (get_wafer_pricing, get_foundry_allocation, calculate_chip_cost). This provides excellent guidance on when to use the tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hbm_market_dataAInspect
Returns 10 HBM market sub-tables: accelerators, specs, marketShare, spotPrices, leadingIndicators, qualificationFeed, revenueForecast, supplierRevenue, validationChecks, bitDemand. Optional table parameter narrows to a single sub-table; omitting returns all 10.
USE THIS for: HBM3/3e/4 generation specs, SK Hynix/Samsung/Micron market share, spot vs. contract pricing, derived HBM bit demand by SKU class and customer type (bitDemand, EB ranges, monthly).
bitDemand is NOT a workload split — it is a SKU-class/customer-type cut. Dominant HBM SKUs are dual-use, so a training-vs-inference HBM attribution would be dishonest; no public source publishes one.
DO NOT USE for: per-accelerator HBM cost in a specific chip (use get_accelerator_costs.costBreakdown.hbmCostUsd); HBM cost in a hypothetical chip cost calc (use calculate_chip_cost with hbmStacks/hbmCost).
Returns INTERNAL_ERROR if the upstream Supabase HBM tables are unreachable. Research tables refresh Mon/Wed/Fri; bitDemand refreshes monthly (1st).
| Name | Required | Description | Default |
|---|---|---|---|
| table | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: returns sub-tables, optional narrowing, error condition, refresh cycle, and clarifies bitDemand is not a workload split.
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?
Front-loaded with core functionality, followed by usage guidance. Slightly verbose but well-structured with clear sections.
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?
Thorough coverage for a tool with one parameter and no output schema: lists all sub-tables, usage boundaries, error behavior, and refresh frequency.
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?
Only one optional parameter table with enum; description explains its effect (narrow to one sub-table) beyond the schema, which lacks descriptions.
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?
Description explicitly states it returns 10 HBM market sub-tables, listing them. It distinguishes from sibling tools like get_accelerator_costs and calculate_chip_cost, making purpose 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?
Clear 'USE THIS for' and 'DO NOT USE for' sections with specific use cases and alternatives. Also notes potential INTERNAL_ERROR and refresh schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hbm_qualificationAInspect
Sourced HBM qualification tracker: which memory vendor (SK Hynix, Samsung, Micron) passed which AI-accelerator customer's qualification (NVIDIA Vera Rubin/GB300/B300/H200, AMD MI350/MI325X, Broadcom), by generation (HBM3/HBM3E/HBM4) and stack height. Returns matrix (current status per vendor×customer×generation, each row dated + source URL + confidence) and timelines (per-relationship status-change history back to 2022, e.g. sampling → in_qualification → qualified → volume_shipping). Refreshed daily; status changes human-reviewed.
USE THIS for: "who supplies HBM4 for Vera Rubin?", "did Samsung pass NVIDIA qualification?", "Micron HBM4 status", qualification timeline/history questions, HBM supply-eligibility analysis.
DO NOT USE for: HBM pricing/market share (use get_hbm_market_data); per-chip HBM cost (use get_accelerator_costs).
Filters: vendor (enum), customer (substring), generation (enum), include_timelines (boolean). Anonymous callers may receive timelines truncated to the latest event per relationship — full history with a free API key (https://siliconanalysts.com/developers). Cite as "Silicon Analysts — HBM Qualification Tracker".
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | No | ||
| customer | No | ||
| generation | No | ||
| include_timelines | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses behavioral traits such as daily refresh, human review of status changes, truncation of timelines for anonymous callers, and the requirement of an API key for full history. This adds value beyond typical read-only expectations.
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 well-structured with sections, but is somewhat lengthy. However, it front-loads the core purpose and uses bullet-like lists for clarity. Every sentence serves a purpose, though minor trimming could improve conciseness.
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?
Despite lacking an output schema, the description details the return structure (matrix and timelines with per-relationship history). It covers all relevant context: filters, use cases, data freshness, source attribution, and access restrictions. The tool is fully explained without requiring further inference.
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?
The input schema has 0% description coverage, so the description compensates by explaining each filter: vendor (enum), customer (substring), generation (enum), include_timelines (boolean). It adds meaning by describing how to use them (e.g., substring matching for customer) and notes the truncation behavior for timelines.
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 defines the tool as a 'Sourced HBM qualification tracker' that returns qualification status per vendor, customer, and generation. It uses specific verbs like 'returns' and lists outputs (matrix, timelines), distinguishing it from sibling tools with explicit 'USE THIS for' and 'DO NOT USE for' sections.
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 (e.g., 'who supplies HBM4 for Vera Rubin?') and when not to use it, naming alternatives like get_hbm_market_data and get_accelerator_costs. This provides clear decision guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_advantageAInspect
Market Advantage — human-vetted TIME-ADVANTAGE evidence: dated, immutable proof that Silicon Analysts recorded a semiconductor supply-chain event BEFORE the first English-language coverage of it. For each win: our first-seen timestamp (immutable), the cited source's own publication time, the first English coverage's timestamp + its public URL/publisher, and the lead in hours (lead_time_hours_vs_detection). Only wins a human has CONFIRMED for citation are returned; nothing unvetted is ever exposed.
USE THIS for: "where has Silicon Analysts led mainstream financial/English-language coverage on chip supply-chain events?", "show the last few supply shocks this feed flagged before Bloomberg/Reuters", proving the feed's Asia-hours latency edge to a fund or procurement team.
DO NOT USE for: the underlying data itself (use get_recent_changes / get_market_intelligence / get_hbm_qualification); unconfirmed or pending races (not exposed by design).
Filters: limit (1-100, default 25), order_by (lead_time|recent), event_kind (hbm_qual|capacity_signal|market_intelligence). Returns facts (timestamps + public URLs), not claims. Empty until a win is confirmed. Cite as "Silicon Analysts — Market Advantage".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| order_by | No | lead_time | |
| event_kind | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully compensates by disclosing behavioral traits: results are dated, immutable, human-confirmed, empty until win confirmed. Only minor gap is not explicitly stating read-only nature, but it's clearly implied.
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?
Well-structured with clear sections and bullet points, front-loaded with core purpose. Slightly verbose but every sentence adds value; no wasted words.
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 no output schema or annotations, the description is remarkably complete: explains return content (timestamps + URLs), citation, filtering options, and when results appear (only confirmed wins). Handles all context needed for correct invocation.
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 coverage is 0%, but description explains all three parameters (limit, order_by, event_kind) with defaults, ranges, and enum meanings, adding significant value beyond the schema.
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 returns human-vetted time-advantage evidence, specifying the resource (Market Advantage) and distinguishing it from sibling tools with explicit 'DO NOT USE for' references.
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?
Explicit 'USE THIS for' and 'DO NOT USE for' sections list specific use cases and alternative tools (get_recent_changes, get_market_intelligence, get_hbm_qualification), providing perfect usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_intelligenceAInspect
Market Intelligence — the freshest SOURCED semiconductor market briefs, generated daily from a Tavily + Claude scan of primary press, earnings, and trade outlets. Each brief returns title, severity (Critical/High/Medium/Low), confidence_score (0-100), quantitative_impact (e.g. "Est. BOM increase: +$500"), an executive summary, a short analysis, a category (Logic/Memory/Packaging/Connectivity/Power/Geopolitics), and a curated sources[] list — plus per-record provenance. UNIQUELY: each brief also carries entities (the chips/nodes/packaging/HBM-gen/companies it concerns), impact (when it's a cost move, the per-chip BOM dollar deltas computed from Silicon Analysts' cost models — e.g. "HBM +20% → +$580 on B200" with a pre-filled calculator URL), and related (cross-links to the live datapoints + tools). No pure-news source does this. The machine feed returns ALL severities; published flags the Critical/High briefs that also have a public page. Public sources only; no insider data.
USE THIS for: "what's the latest in HBM / CoWoS / TSMC supply this week?", "any recent semiconductor price hikes, yield news, or capacity moves?", building a sourced market-news digest, grounding a claim about a recent supply-chain event.
DO NOT USE for: current absolute cost/pricing values (use get_accelerator_costs / get_wafer_pricing / calculate_chip_cost); structured data movements over time (use get_recent_changes); allocation/lead-time status (use get_foundry_allocation).
Filters: severity, category, since (ISO timestamp), publishedOnly (bool), limit (1-100, default 25). N2/Apple omitted (conflict-safe). Cite as "Silicon Analysts — Market Intelligence".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| category | No | ||
| severity | No | ||
| publishedOnly | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses data source (Tavily + Claude scan), that it's public-only, no insider data, returns all severities with a 'published' flag for Critical/High that have a public page, and includes provenance, entities, impact, and related cross-links.
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?
Well-structured with paragraphs covering what it returns, uniqueness, usage guidelines, and filters. Some redundancy (e.g., 'freshest...' repeated), but generally concise given the amount of information conveyed.
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?
Without an output schema, the description thoroughly explains all return fields (title, severity, confidence_score, quantitative_impact, executive summary, analysis, category, sources, entities, impact, related) and how they relate to each other (e.g., 'published' flag, 'impact' with BOM deltas and calculator URLs).
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 coverage is 0%, but the description explains all 5 parameters: severity (enum), category, since (ISO timestamp), publishedOnly (bool), limit (default 25, range 1-100). Missing exact format for 'since' and possible category values, but provides helpful defaults and constraints.
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 it returns 'freshest SOURCED semiconductor market briefs' with specific fields like title, severity, etc. It distinguishes from sibling tools by noting what not to use it for (e.g., absolute cost/pricing use other tools) and highlights uniqueness vs pure-news sources.
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?
Provides explicit 'USE THIS FOR:' and 'DO NOT USE FOR:' sections with concrete examples (e.g., 'what's the latest in HBM...', 'use get_accelerator_costs for cost/pricing'). Also lists filters (severity, category, since, publishedOnly, limit) and notes N2/Apple omitted for conflict-safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_pulseAInspect
Returns curated supply-chain headlines with trend direction (up/down/neutral), source attribution, and impact analysis. Categories: logic, memory, packaging, connectivity, power, geopolitics. Defaults to all categories, all trends, no limit.
USE THIS for: "what's happening in HBM this quarter?", "any geopolitical moves affecting TSMC?", recent supply/demand inflections.
DO NOT USE for: structured pricing data (use get_wafer_pricing, get_hbm_market_data); published cost of a specific chip (use get_accelerator_costs).
Per-item dates are formatted strings (e.g., "Jan 2026") — not ISO 8601. Cache: 5 minutes server-side. Returns empty array if all items filtered out.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| trend | No | ||
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: defaults (all categories, all trends, no limit), date format (non-ISO 8601 strings), cache duration (5 minutes server-side), and response when all items filtered out (empty array). No contradictions with missing annotations.
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?
Description is efficient: first sentence captures core function, second provides usage guidance, third handles exclusions, fourth adds technical details. Every sentence adds value with no fluff.
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?
Despite no output schema, description covers return content (headlines with trend, source, impact), filtering behavior, date format, caching, and edge case (empty array). Complete for a headline retrieval tool.
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 coverage is 0%, but description adds meaning to all three parameters: lists category enum values, explains trend direction, and clarifies limit (default no limit). Also explains per-item date format not reflected in schema.
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 returns curated supply-chain headlines with trend direction, source attribution, and impact analysis. It specifies categories (logic, memory, etc.) and distinguishes itself from sibling tools by explicitly stating when NOT to use it.
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 concrete example queries like 'what's happening in HBM this quarter?' and explicit exclusions: 'DO NOT USE for structured pricing data (use get_wafer_pricing, get_hbm_market_data); published cost of a specific chip (use get_accelerator_costs).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_packaging_costsAInspect
Returns two sub-arrays: packaging (per-tech cost benchmark + capability matrix for CoWoS-S/L, EMIB, SoIC, InFO-PoP, FC-BGA, FC-CSP, etc.) and hbmSpecs (HBM2 through HBM4 cost per stack + bandwidth/capacity). Optional type filter narrows packaging array to one technology.
USE THIS for: packaging cost lookup, comparing CoWoS variants, getting HBM stack pricing for cost modeling.
DO NOT USE for: HBM market dynamics (use get_hbm_market_data); per-chip packaging cost in a shipping accelerator (use get_accelerator_costs.costBreakdown.packagingCostUsd).
Returns INVALID_PARAMS for unknown type. Refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior: returns two sub-arrays, optional filter, error handling (INVALID_PARAMS for unknown type), and refresh cadence (monthly). Somewhat lacking explicit read-only hint, but overall transparent given no annotations.
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?
Three concise paragraphs. First sentence states return structure, second gives use/non-use guidance, third covers error and refresh. No fluff; every sentence adds value.
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?
Covers return structure, parameter usage, error handling, refresh rate, and differentiation from siblings. No output schema provided, but description sufficiently explains return format for a lookup tool.
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?
Input schema has 0% description coverage, but description compensates by explaining that optional 'type' filter narrows the packaging array to one technology. Could be improved by listing valid technology values, but adds meaningful context beyond bare schema.
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?
Description uses specific verb 'Returns' and clearly identifies two sub-arrays ('packaging' and 'hbmSpecs'), listing exact technologies included. Differentiates from siblings by explicitly stating when not to use (e.g., use get_hbm_market_data for market dynamics).
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?
Includes explicit 'USE THIS for:' and 'DO NOT USE for:' sections with concrete alternative tool names (get_hbm_market_data, get_accelerator_costs), leaving no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recent_changesAInspect
"What Changed" — recent MOVEMENTS in Silicon Analysts' public data over a 7d/30d window, derived from the daily snapshot ledger. Each moved metric returns direction (up/down), magnitude (pct_delta for value metrics, pp_delta for percentage metrics), old/new values, the two snapshot dates compared (as_of, prior_as_of), window_days_actual (the REAL lookback — the ledger is young, so a 30d window clamps to available history), and per-record provenance. Domains: wafer_pricing, chip_cost, margin_benchmark, foundry_capacity, defect_density, nre_cost.
USE THIS for: "what moved in semiconductor costs this week?", "did any wafer prices change recently?", "what changed since my last fetch on June 20?" (use since), building a market-change digest, monitoring deltas across the data layer over time.
DO NOT USE for: current absolute values (use get_wafer_pricing / get_accelerator_costs / get_foundry_allocation); allocation lead-time trend specifically (use get_foundry_allocation with include_history).
Filters: window (7d|30d), since (ISO date — compare the latest snapshot against the newest snapshot at/before it; overrides window for baseline selection), datasetId (one domain), minDelta (override the significance threshold), limit. N2/Apple omitted (conflict-safe). Returns an empty array when nothing moved past the significance gate — does not error. Cite as "Silicon Analysts — What Changed".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| window | No | 7d | |
| minDelta | No | ||
| datasetId | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully carries burden. Discloses conflict-omission (N2/Apple), clamping of window_days_actual for young ledger, and that empty array returned instead of error. Provides provenance and field details.
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?
Well-structured with sections and bullet points. Front-loaded summary. Every sentence adds value; no wasted words despite length.
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 5 params, no annotations, no output schema, description covers all key aspects: return fields, behavior (clamping, conflict-safe), usage contexts, and filter semantics. Complete for agent selection and invocation.
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 coverage 0%, so description compensates: explains window, since (overrides baseline), datasetId (domains listed), minDelta (significance threshold). Limit is mentioned briefly but not explained in depth; still adds substantial value beyond schema.
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?
States 'recent MOVEMENTS in Silicon Analysts' public data' with clear verb and resource. Distinguishes from siblings by listing domains and specifying what not to use for (absolute values, allocation lead-time).
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 lists USE THIS for with concrete examples and DO NOT USE for with alternative tool names. Explains filters and default behavior (empty array when nothing moved).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wafer_pricingAInspect
Returns 300mm wafer price ranges (min/avg/max USD), defect density, NRE/mask-set cost, and node maturity for: tsmc-n3, tsmc-n5, tsmc-n7, tsmc-28, samsung-3nm, samsung-5nm, intel-16. Optional node filter narrows to one.
USE THIS for: looking up wafer cost for cost modeling, comparing foundries at the same node.
DO NOT USE for: per-chip cost (use get_accelerator_costs or calculate_chip_cost); packaging-related cost (use get_packaging_costs).
Returns INVALID_PARAMS if node is not in the valid set. Each record carries the source attribution string. Refreshes monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| node | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses error behavior (returns INVALID_PARAMS for invalid nodes), data freshness (monthly refresh), and source attribution. It implicitly indicates a read-only query. Slight deduction for not explicitly stating idempotency or lack of side effects, but sufficient for a pricing tool.
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?
Four sentences front-load the core purpose, then provide usage guidelines, then error behavior and refresh. Every sentence adds value with no redundancy.
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?
Covers all key aspects: input (allowed nodes, optional filter), output (price ranges, defect density, NRE/mask-set, node maturity), error handling, and data freshness. No gaps remain given the tool's complexity.
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?
The schema has one parameter with no description (0% coverage). The description adds full meaning by listing valid values and explaining the optional filter. This compensates completely for the schema's lack of detail.
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 'Returns 300mm wafer price ranges...' for specific nodes, making the verb and resource explicit. It distinguishes from sibling tools by specifying alternatives for per-chip and packaging costs.
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 provides 'USE THIS for' and 'DO NOT USE for' sections, naming alternative tools like get_accelerator_costs and get_packaging_costs. This leaves no ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!