Skip to main content
Glama
Reid-n0rc

Future Electronics MCP

by Reid-n0rc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Future Electronics part lookup

future_lookup_part
Read-only

Look up one electronic component by manufacturer part number in the Future Electronics catalog. Returns offers with stock, quantity price breaks, lead time, and datasheet links.

Instructions

Look up one electronic component in the Future Electronics catalog by manufacturer part number (MPN). Returns a compact JSON summary: lookup_value, lookup_results, total_offers (offers found before truncation), and up to max_offers offers. Each offer lists MPN, Future part number, product URL, stock (quantity_available, quantity_on_order), minimum and order multiple, lead time, currency, price breaks, package type, MPQ, RoHS, date code, and datasheet URL when known. When quantity is given, each offer also has price_at_quantity: the price break that applies to that quantity, or a reason there is none (below_minimum, no_pricing, no_matching_break). Pricing matches the Future website and is NOT an official quote: Pricing is not an official quote. Confirm price and availability with Future Electronics before ordering. lookup_type defaults to exact, which matches the full part number. Use starts_with when you know only the beginning of the MPN (for example a base part without its packaging or temperature suffix), and contains when you know a fragment from the middle. Those return more, less precise offers, so check the mpn of each result. Set raw to true only when you need upstream fields the summary omits; it returns the untouched API response (offers still truncated to max_offers) and ignores quantity. Output is compact JSON capped at FUTURE_MAX_OUTPUT_TOKENS: if offers must be dropped to fit, the last ones go and truncated {omitted, hint} says how many. For many parts at once, use future_lookup_parts instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rawNoReturn the untouched upstream response instead of the summary.
quantityNoOptional order quantity; reports the applicable price break per offer.
max_offersNoMaximum offers to return, 1-50 (default 10).
lookup_typeNoMatch mode: exact (default), starts_with, contains, or default (the API's own default).exact
part_numberYesManufacturer part number, at least 3 alphanumeric characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations cover read-only/open-world, and the description adds real behavioral context beyond them: the truncation behavior (last offers dropped, truncated {omitted, hint}), the FUTURE_MAX_OUTPUT_TOKENS cap, the exact return shape, and the critical caveat that pricing is not an official quote and must be confirmed before ordering. It also notes raw ignores quantity. Slight deduction only for not restating auth/rate-limit behavior.

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-loads the core purpose, then proceeds through return shape, pricing caveat, lookup modes, raw behavior, and truncation in a logical order. Dense but each clause carries information; the repetition of 'Pricing is not an official quote' is the only minor waste.

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 a read-only lookup with no output schema, the description supplies everything an agent needs: the return structure, field-level offer contents, pricing caveat, lookup-mode semantics, raw-mode tradeoffs, and truncation signaling. No meaningful gap remains.

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 the baseline is 3, but the description adds meaning the schema does not: what price_at_quantity contains and its failure reasons (below_minimum, no_pricing, no_matching_break), the practical distinction between starts_with and contains, and the fact that raw ignores quantity. That is genuine value on top of the schema.

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 (look up) and resource (one electronic component in the Future Electronics catalog), names the required key (MPN), and explicitly distinguishes from the sibling: 'For many parts at once, use future_lookup_parts instead.' An agent can pick this versus the batch tool 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?

Explicit when-to-use for each lookup_type (exact for full MPN, starts_with for known prefixes, contains for middle fragments), plus the warning that those return 'more, less precise offers, so check the mpn of each result.' Also scopes raw to true 'only when you need upstream fields the summary omits' and routes multi-part queries to the sibling.

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