Skip to main content
Glama
SpectraSynq

mcp-nexar

by SpectraSynq
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

mcp-nexar

Model Context Protocol server for Nexar/Octopart component search.

License GitHub Discord

mcp-nexar exposes Nexar GraphQL supply search through MCP tools for part lookup, exact MPN search, and datasheet URL extraction. It is intended for PCB design and EDA agents that need Octopart/Nexar component data without embedding project-specific K1 hardware code.

This repository is the canonical source for the Nexar MCP server. SpectraSynq/K1.hardware consumes it by repository reference instead of carrying a second editable copy.

Quickstart

Install in an isolated Python environment:

python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .
export NEXAR_CLIENT_ID="your-client-id"
export NEXAR_CLIENT_SECRET="your-client-secret"
mcp-nexar

Nexar credentials are required for live API calls. Create your own application credentials in Nexar; do not commit them to a repository or MCP config file.

Related MCP server: Nexar MCP Server

Tools

  • parts_search(q, limit=3) - free-text supply search for MPNs, manufacturers, and datasheet URLs.

  • part_by_mpn(mpn) - exact MPN lookup with basic specs.

  • best_datasheet_url(mpn) - extracts the first bestDatasheet.url from an MPN search.

Claude Desktop example

{
  "mcpServers": {
    "nexar": {
      "command": "/absolute/path/to/mcp-nexar/.venv/bin/mcp-nexar",
      "env": {
        "NEXAR_CLIENT_ID": "your-client-id",
        "NEXAR_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Honest local demo

This demo proves the package imports and refuses to call the network without credentials:

python - <<'PY'
from mcp_nexar.server import clear_token_cache, get_token

clear_token_cache()
try:
    get_token()
except RuntimeError as exc:
    print(exc)
PY

Expected output:

Set NEXAR_CLIENT_ID and NEXAR_CLIENT_SECRET before using Nexar tools.

Run the offline test harness:

python -m pip install -e ".[dev]"
python -m pytest -q

Provenance

Extracted from SpectraSynq/K1.hardware after the repository transfer to the SpectraSynq organisation.

  • Source commit: 002fc9770c6211a752dfb50c43802c245c7e69

  • Source file: mcp/mcp-nexar/server.py

  • Source SHA-256: cbb668253d78fa2e01e6ccf87ee2e7bee56555644e583c91239bad757ae7ce94

Part of the SpectraSynq toolchain

License

Apache-2.0 - see LICENSE.

Available Tools

3 tools
best_datasheet_urlA

Return the first bestDatasheet URL for a manufacturer part number.

ParametersJSON Schema
NameRequiredDescriptionDefault
mpnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns the 'first' bestDatasheet URL, implying an ordering or ranking behavior. However, it does not mention potential errors, rate limits, or side effects, though the read-only nature is implied by 'Return'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It conveys the essential information efficiently.

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

Completeness4/5

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

For a simple tool with one parameter and an output schema present, the description is adequate. It clearly states the return value (first bestDatasheet URL). It lacks edge-case behavior (e.g., no match found), but given the output schema and low complexity, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 does by explaining that the parameter mpn is a 'manufacturer part number', which is a key semantic. However, it does not provide format examples or constraints beyond that.

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 clearly states a specific verb ('Return') and resource ('bestDatasheet URL') for a given manufacturer part number, which distinguishes it from siblings like part_by_mpn (likely returns part details) and parts_search (likely searches parts).

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

Usage Guidelines3/5

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

The description implies usage: when you need a datasheet URL for a specific MPN. However, it does not explicitly mention when to use this tool versus alternatives like part_by_mpn, nor does it provide any exclusions or prerequisites.

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

part_by_mpnA

Search Nexar/Octopart for an exact manufacturer part number.

ParametersJSON Schema
NameRequiredDescriptionDefault
mpnYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states the basic search action and does not disclose any behavioral traits such as return format, error handling, or access requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant information, achieving maximum conciseness.

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

Completeness4/5

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

The tool is simple (one parameter) and an output schema exists, so return values need not be described. The description sufficiently covers the core function, though it lacks some behavioral depth and usage guidance.

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?

The schema provides no description for 'mpn', but the description's phrase 'manufacturer part number' clarifies the parameter's meaning. For a single self-explanatory parameter, this is adequate compensation for the 0% schema coverage.

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 specific verb ('Search') and resource ('Nexar/Octopart') with a clear modifier ('exact manufacturer part number'), distinguishing it from sibling tools like parts_search and best_datasheet_url.

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

Usage Guidelines3/5

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

The description implies usage for exact MPN lookups but does not explicitly state when to use this tool versus alternatives (e.g., 'use parts_search for partial matches'). No exclusions or alternatives are mentioned.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation4/5

Each tool serves a distinct purpose: exact MPN lookup, free-text search, and datasheet URL retrieval. The potential confusion between part_by_mpn and best_datasheet_url is mitigated by clear descriptions of differing outputs.

Naming Consistency2/5

Tool names lack a consistent pattern. 'parts_search' follows a noun-verb structure, while 'part_by_mpn' uses a prepositional phrase and 'best_datasheet_url' is an adjective-noun combination. The inconsistent naming style makes the set feel ad hoc.

Tool Count5/5

With only 3 tools, the server is well-scoped for a focused part-search and datasheet service. Each tool is essential, and the count falls comfortably within the ideal range.

Completeness4/5

The server covers the core functions of part search (exact and free-text) and datasheet retrieval. Minor gaps exist, such as no explicit endpoint for part specifications or availability, but these are likely covered by the part_by_mpn response, making the surface adequate.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • tscircuit MCP Server

    charlielockyer-rice
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides Claude with access to the tscircuit electronics component registry, enabling search, browsing, and analysis of electronic components and circuit packages from the tscircuit ecosystem.
    3
    MIT

  • Nexar MCP Server

    phuhduong
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables searching for electronic components through the Nexar Supply API, providing detailed part information including manufacturer, pricing, specifications, and datasheets.

  • Nexar MCP Server

    Farad-Labs
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables searching for electronic components, comparing prices across distributors, checking availability, and retrieving datasheets through the Nexar/Octopart API with specialized tools for resistors, capacitors, inductors, semiconductors, crystals, and connectors.
    8

  • SheetsData MCP

    octoco-ltd
    A
    license
    A
    quality
    C
    maintenance
    Provides AI agents with instant, structured access to electronic component datasheets, pinouts, and electrical specifications without requiring PDF uploads. It enables seamless part searching, design validation, and side-by-side component comparisons across major hardware providers.
    12
    84
    10
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpectraSynq/mcp-nexar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server