Skip to main content
Glama
Reid-n0rc

Future Electronics MCP

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Future Electronics BOM lookup

future_lookup_parts
Read-only

Look up up to 2,000 Future Electronics part numbers at once, such as a full BOM, to check stock, pricing, lead times, and issues by quantity.

Instructions

Look up many Future Electronics parts at once, e.g. a whole bill of materials (BOM). Accepts up to 2000 part numbers, each optionally with a quantity. Part numbers are trimmed and de-duplicated case-insensitively (quantities of duplicates are summed), then sent in batches of 300, several batches in parallel. Each part is judged on its best offer (the most stock) at the requested quantity (1 when none is given). By default it returns exceptions and totals, not every part: totals (requested, unique, found, not_found, errors, not_attempted, short_stock, below_moq, call_for_leadtime, batches, rate_limited), extended_cost (quantity x applicable unit price, summed per currency), unpriced (found parts with no applicable price break, left out of extended_cost), max_lead_time, and an issues table {columns, rows} listing ONLY problem parts. Problems: short_stock (available < quantity), below_moq (a given quantity < the minimum order), call_for_leadtime (lead time "CALL"), not_found, error, not_attempted; one part can have several, joined by ";" in its reason. Parts with no problem appear only in the counts. detail "all" returns a parts table with a row for every part instead. Output is capped at FUTURE_MAX_OUTPUT_TOKENS: when rows are dropped, truncated {omitted, hint} says so. If one batch fails, its parts get the error and the rest are still returned. If the API rate limit is still hit after retries, the lookup stops early: batches already running finish, and parts in batches not yet started are "not_attempted" (retry them later; totals.rate_limited is true). Prices are not an official quote. Use the single-part lookup tool for full offer details of one part.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNoReturn the untouched upstream batch responses instead of the summary. Far larger, so whole batches are usually dropped by the output budget; use only for one small batch.
partsYes1-2000 manufacturer part numbers. Each item is a string ("LM317T") or {"part_number": "LM317T", "quantity": 500}. Quantity is optional (positive integer) and selects the price break; duplicates are merged and their quantities summed.
detailNo"summary" (default): totals plus a table of problem parts only. "all": a table row for every part. Both are capped by the output budget.summary

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, yet the description discloses far more: batch size (300) and parallelism, case-insensitive de-duplication with quantity summing, partial-failure semantics ('If one batch fails, its parts get the error and the rest are still returned'), rate-limit early stop with 'not_attempted' handling, and output-budget truncation via {omitted, hint}. This is unusually rich behavioral disclosure.

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 before diving into mechanics, and every sentence carries information (dedup rules, batching, totals fields, failure modes). It is long and dense to the point of being a wall of text, but for a tool with this much hidden behavior the length is largely earned.

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?

There is no output schema, so the description carries the full burden of explaining returns — and it does, enumerating totals fields, extended_cost, unpriced, max_lead_time, the issues table, the detail='all' alternative, and truncation behavior. Nothing an agent needs to call or interpret this tool 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond the schema: each part is judged on its best offer (most stock) and quantity defaults to 1 when omitted, which explains how the quantity parameter actually changes the result. The 'raw' and 'detail' semantics largely duplicate the schema descriptions.

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?

States a specific verb and resource ('look up many Future Electronics parts at once, e.g. a whole bill of materials') and explicitly distinguishes itself from the sibling by directing single-part needs to 'the single-part lookup tool'. An agent can route between future_lookup_parts and future_lookup_part without opening either schema.

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?

Names the alternative tool and the condition that selects it ('Use the single-part lookup tool for full offer details of one part'), and gives conditional guidance for the detail enum ('all' returns every part vs the default summary). It also advises raw is only for one small batch.

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

Deploy Server

Other Tools