Which integrations are available for this server?

Provides tools for searching, indexing, and retrieving official STMicroelectronics PDF documentation, enabling grounded answers from datasheets and technical reference manuals.

How do I use Electronics Docs MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Electronics Docs MCP Server look up TMP117 temperature sensor specs" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Electronics Docs MCP Server

by flaco-source

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Electronics Docs MCP Server

An MCP (Model Context Protocol) server that gives LLMs direct access to official vendor PDF documentation (Texas Instruments, STMicroelectronics, and Analog Devices), with a local SQLite full-text index (FTS5 + BM25) so answers can be grounded in real datasheet and TRM text.

Tools

Tool	Role
`lookup_doc`	Part + question: FTS on the local index only; if no match, returns `suggestedDocuments` (links from the vendor site). Does not download PDFs — use `read_doc` next.
`search_docs`	List PDF links for a part (metadata only).
`read_doc`	Index a PDF by direct URL — use for `/lit/ds/symlink/....pdf` and any link the user already has. Optional `part` / `title`.
`query_doc_content`	BM25 search; each hit includes `docUrl` and `pageNum`.
`read_doc_page`	Full indexed text for page or page range (`docUrl` from search results).

When to use: lookup for index check + suggested URLs; **read_doc** to index; **read_doc_page** after query_doc_content when you need full page text. TI symlink datasheets often need read_doc directly. See [src/resources/tool-usage-guide.md](src/resources/tool-usage-guide.md).

Related MCP server: PDF RAG MCP Server

MCP resources

URI	Content
`electronics-docs://guide/tool-usage`	Markdown guide: when to use each tool, how to phrase queries, limits. Source: `[src/resources/tool-usage-guide.md](src/resources/tool-usage-guide.md)`.

The server advertises **instructions** on initialize pointing agents to this resource.

Cursor skill (optional)

Project skills: electronics-docs-mcp, electronics-docs-mcp-ti, electronics-docs-mcp-st, electronics-docs-mcp-adi. Copy to ~/.cursor/skills/ if you want them globally.

Supported vendors

Vendor ID	Name	Status
`TI`	Texas Instruments	Supported
`ST`	STMicroelectronics	Supported
`ADI`	Analog Devices	Supported

Recent changes (server v2.7.x)

Analog Devices (ADI): New AnalogDevicesProvider — PDF discovery from analog.com/en/products/<slug>.html, slug fallbacks on 404, lookup_doc filters PCN and mds.analog.com from suggestions only; same MCP tools as TI/ST.
Vendor list: Supported vendors are derived from the vendors map in mcpServerFactory.ts (including list_indexed_documents validation). Tool schemas list all supported IDs.
STMicroelectronics (ST): Removed the blind “canonical datasheet” URL fallback that could suggest st.com/.../datasheet/<slug>.pdf for non‑ST parts. Legacy DB rows matching that synthetic pattern are skipped when merging search_docs results.
PDF download (read_doc): Retries on transient errors (502/503/504, timeouts, etc.); longer default timeout for analog.com; Accept-Language on Analog PDF requests; Referer for native fetch chosen by host (analog.com, ti.com, st.com).

Adding a new vendor (hot plug)

Create src/providers/YourVendorProvider.ts extending VendorProvider.
Implement searchDocs, readDoc, queryContent, and optionally override **lookupDoc** and **getDocumentPageText** for orchestrated behavior and page reads.
Register the provider in [src/mcpServerFactory.ts](src/mcpServerFactory.ts) under vendors (supported vendor IDs and tool descriptions follow this map automatically).
Rebuild: npm run build and restart the MCP process.

Development

npm install
npm run build   # compiles TS → build/ and copies src/resources/*.md to build/resources/
npm start       # stdio MCP server (for Cursor / Claude Desktop)
npm run start:http  # HTTP MCP server on port 3000 (for network / remote use)

Transport modes

This server supports two transports that share identical tools and resources:

Mode	Entry point	Transport	Use case
stdio	`src/index.ts`	`StdioServerTransport`	Cursor, Claude Desktop (local)
HTTP	`src/server-http.ts`	`StreamableHTTPServerTransport` (stateless)	LAN testing, remote deployment, multi-client

The shared logic lives in src/mcpServerFactory.ts — both entry points call createMcpServer().

stdio mode (local — Cursor / Claude Desktop)

How "local" works

This server speaks MCP over stdio, not HTTP. The IDE spawns node …/build/index.js (or Docker with -i) and talks to the process over pipes. There is nothing to "open in the browser"; exposure = registering the command in Cursor / Claude so they start the binary for each session.

The SQLite index lives at ~/.electronics-docs-mcp/docs.db on the host (or /root/.electronics-docs-mcp/ inside Linux containers unless you mount a volume).

Cursor MCP config (Node — recommended)

Use an absolute path to build/index.js. Adjust the drive/path for your machine.

{
  "mcpServers": {
    "electronics-docs": {
      "command": "node",
      "args": ["D:/Projects Cursor/mcp-docs/build/index.js"]
    }
  }
}

After editing MCP settings, reload the window or restart the MCP server so it picks up rebuilds.

Cursor MCP config (Docker)

Build the image first (npm run build is required so build/ exists before docker build).

npm run build
docker build -t electronics-docs-mcp .

Cursor runs the container with -i so stdin stays open for the stdio protocol. Persist the index on a named volume (maps to /root/.electronics-docs-mcp in the image):

{
  "mcpServers": {
    "electronics-docs": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-v", "electronics-docs-mcp-data:/root/.electronics-docs-mcp",
        "electronics-docs-mcp"
      ]
    }
  }
}

On first run Docker creates the volume electronics-docs-mcp-data. To reset the index: remove the volume (docker volume rm electronics-docs-mcp-data) or delete docs.db inside it.

Claude Desktop

Same command / args as Cursor in claude_desktop_config.json (e.g. %APPDATA%\Claude on Windows).

HTTP mode (LAN / remote)

The HTTP server exposes the same MCP tools and resources over MCP Streamable HTTP (POST /mcp).
Each request is fully independent — no session state is kept in memory.

Quick start

# Development (tsx, auto-reload)
npm run start:http

# Production (compiled)
npm run build
npm run start:http:prod

Default: http://0.0.0.0:3000/mcp

Environment variables

Variable	Default	Description
`PORT`	`3000`	TCP port to listen on
`HOST`	`0.0.0.0`	Interface to bind (`127.0.0.1` for local-only)
`MCP_AUTH_TOKEN`	(unset)	When set, all requests must carry `Authorization: Bearer <token>`

Health check

curl http://localhost:3000/health
# {"status":"ok","server":"electronics-docs-mcp","version":"2.7.0"}

Test a tool call (curl)

curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list"
  }'

With auth token:

curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer mysecret" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Cursor `mcp.json` (remote Streamable HTTP)

Cursor reads MCP settings from a JSON file at the user level (not per-project):

OS	Path
Windows	`%USERPROFILE%\.cursor\mcp.json` — e.g. `C:\Users\YourName\.cursor\mcp.json`
macOS / Linux	`~/.cursor/mcp.json`

Merge the block below into the top-level "mcpServers" object (alongside any other servers you already use).

Required fields for this server

Field	Value
`type`	`"streamableHttp"` — tells Cursor to use the Streamable HTTP MCP client (POST to `/mcp`). Without it, the client may POST to `/` and you get `Cannot POST /`.
`url`	Full URL ending in `/mcp` — e.g. `http://192.168.1.100:3000/mcp` or `https://your-subdomain.trycloudflare.com/mcp`. Do not use only the origin (`https://host/`) or Cursor will target `/` instead of `/mcp`.
`headers` (optional)	Only if the server was started with `MCP_AUTH_TOKEN`. Use `Authorization": "Bearer YOUR_TOKEN"` — the word `Bearer` plus a space before the secret is required; the server compares the token after `Bearer` to `MCP_AUTH_TOKEN`.

Example — LAN (no auth on server)

{
  "mcpServers": {
    "electronics-docs-remote": {
      "type": "streamableHttp",
      "url": "http://192.168.1.100:3000/mcp"
    }
  }
}

Example — LAN or tunnel with MCP_AUTH_TOKEN

{
  "mcpServers": {
    "electronics-docs-remote": {
      "type": "streamableHttp",
      "url": "http://192.168.1.100:3000/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SECRET_TOKEN"
      }
    }
  }
}

Example — Cloudflare quick tunnel (cloudflared tunnel --url http://localhost:3000)

The printed URL must include /mcp. Quick tunnels get a new *.trycloudflare.com hostname each run — update url whenever you restart cloudflared without a named tunnel.

{
  "mcpServers": {
    "electronics-docs-remote": {
      "type": "streamableHttp",
      "url": "https://random-name.trycloudflare.com/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_SECRET_TOKEN"
      }
    }
  }
}

After editing mcp.json, reload the Cursor window (or restart MCP) so the config is picked up.

Claude Desktop uses its own file (e.g. claude_desktop_config.json on Windows under %APPDATA%\Claude\) — same url / headers ideas apply if the client supports HTTP MCP.

Exposing to the internet

Option A — ngrok (fastest, for short-term testing)

npm install -g ngrok
ngrok http 3000
# → https://abc123.ngrok.io  (public HTTPS tunnel to localhost:3000)

Set in Cursor (~/.cursor/mcp.json or %USERPROFILE%\.cursor\mcp.json on Windows):

{
  "mcpServers": {
    "electronics-docs-remote": {
      "type": "streamableHttp",
      "url": "https://abc123.ngrok.io/mcp",
      "headers": { "Authorization": "Bearer mysecret" }
    }
  }
}

Option B — Cloudflare Tunnel (free, stable, no open port)

# Install: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
cloudflared tunnel --url http://localhost:3000
# → https://some-name.trycloudflare.com

Option C — Docker + VPS / cloud (permanent deployment)

Build a production image that starts the HTTP server:

# Add to Dockerfile (replace the existing CMD)
CMD ["node", "build/server-http.js"]

Deploy on any Node-capable platform:

# Railway / Fly.io / Render — set env vars in dashboard:
#   PORT=3000  (usually auto-set by platform)
#   MCP_AUTH_TOKEN=<your-secret>

# Fly.io example
fly launch --name electronics-docs-mcp
fly secrets set MCP_AUTH_TOKEN=mysecret
fly deploy

Option D — Docker Compose (self-hosted server)

# docker-compose.yml
services:
  mcp-http:
    build: .
    command: node build/server-http.js
    ports:
      - "3000:3000"
    environment:
      - PORT=3000
      - MCP_AUTH_TOKEN=mysecret
    volumes:
      - mcp-data:/root/.electronics-docs-mcp
    restart: unless-stopped

volumes:
  mcp-data:

npm run build
docker compose up -d

Option E — Vercel (serverless)

The repo includes api/index.ts and vercel.json so the HTTP MCP runs as a Vercel Node function. The build runs npm run build (TypeScript → build/, resources copied, then scripts/ensure-public-dir.cjs so a public/ directory exists). vercel.json sets outputDirectory: public so Vercel does not fail with “No Output Directory named public”. If the dashboard overrides this, set Output Directory to public or leave it empty and rely on vercel.json.

Install the CLI: npm i -g vercel
From the project root: vercel (link the project) then vercel --prod for production.
In the Vercel dashboard → your project → Settings → Environment Variables, add:

Name	Value	Environments
`MCP_AUTH_TOKEN`	Your secret (same value you use in `Authorization: Bearer …`)	Production, Preview
`ELECTRONICS_DOCS_DB_DIR`	`/tmp/electronics-docs-mcp`	Production, Preview

Redeploy after changing env vars.

URLs after deploy

MCP (Streamable HTTP): https://<your-project>.vercel.app/mcp — rewrites in vercel.json map /mcp → /api/mcp.
Health: https://<your-project>.vercel.app/health
Direct function path (same behavior): https://<your-project>.vercel.app/api/mcp

Cursor mcp.json

{
  "mcpServers": {
    "electronics-docs-vercel": {
      "type": "streamableHttp",
      "url": "https://YOUR_PROJECT.vercel.app/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_MCP_AUTH_TOKEN"
      }
    }
  }
}

Caveats

Serverless timeouts: Default Hobby limit is 10s per invocation; long PDF indexing may hit it. Pro allows longer functions (see vercel.json maxDuration). Prefer indexing heavy PDFs locally or on a long-running host.
SQLite: The index lives under ELECTRONICS_DOCS_DB_DIR (e.g. /tmp). On serverless, storage is ephemeral — the DB may reset when the function cold-starts or scales. For a durable index, use self-hosted Option D or a VM.
better-sqlite3: Native module; if the build fails on Vercel, check Node version in Project Settings and build logs.
Secrets: Never commit tokens to git. Set MCP_AUTH_TOKEN only in the Vercel UI or vercel env add.

Project structure

api/
└── index.ts                    # Vercel serverless: Express app → /api/mcp, /api/health
src/
├── index.ts                    # stdio entry point  (Cursor / Claude Desktop)
├── httpApp.ts                  # Express app factory (shared: local HTTP + Vercel)
├── server-http.ts              # HTTP entry point   (LAN / remote / cloud)
├── mcpServerFactory.ts         # shared MCP server logic (tools + resources)
├── resources/
│   └── tool-usage-guide.md    # Copied to build/resources/ on build
├── cache/
│   └── DocumentCache.ts        # SQLite + FTS5
└── providers/
    ├── VendorProvider.ts
    ├── TexasInstrumentsProvider.ts
    └── StMicroelectronicsProvider.ts

Indexed data is stored under ~/.electronics-docs-mcp/docs.db.

Testing

npm test
# build + run.ts all (see run-default-smoke.cjs)

scripts/agent-flow/run.ts covers resource, search, lookup (TI + ST), and optionally read/query/page/flow. By default RUN_E2E_NETWORK is false in that script, so PDF downloads are skipped. Set RUN_E2E_NETWORK = true in run.ts for full read/query/page (network required).

npx tsx scripts/agent-flow/run.ts --tool search --vendor ST

Available Tools

6 tools

list_indexed_documentsA

List indexed PDF metadata from the local database (no web fetch). Returns count and documents (id, part, title, docType, url, indexedAt). Optional part filters to that part number (normalized like other tools). Omit part to list all documents for the vendor.

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`part`	No	Optional part number (e.g. STM32G071RB). If omitted, all indexed docs for the vendor are returned.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description bears full burden. It discloses that the tool performs a local database read (no web fetch) and returns specific fields. For a read-only listing tool, this adequately covers behavioral traits.

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 concise (three sentences), front-loaded with the most important information, and every sentence serves a purpose without redundancy.

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?

Despite no output schema, the description fully explains the return structure (count and documents with specific fields). It covers optional filtering and key traits, making it complete for this simple tool.

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%, but description adds value by explaining 'part' is normalized like other tools and omitting it lists all documents for the vendor. This provides context beyond the raw 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?

The description explicitly states the tool lists indexed PDF metadata from the local database (no web fetch), distinguishes from siblings by emphasizing local-only operation, and clearly specifies return fields (count, documents with id, part, title, docType, url, indexedAt).

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

Usage Guidelines4/5

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

The description provides clear context on when to use (listing indexed docs locally) and guidance on the optional 'part' filter. It lacks explicit when-not-to-use or alternative tools, but the context is sufficient for basic decisions.

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

lookup_docA

Part number + question: FTS over the local index only — does not download or index PDFs. If the index matches, returns chunks; otherwise returns suggestedDocuments (prioritized PDF URLs from the vendor site). Next step: read_doc on a chosen URL, then query_doc_content. TI symlink datasheets may be missing from suggestions — use read_doc if you already have the PDF URL. See resource electronics-docs://guide/tool-usage.

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`part`	Yes	Part number (e.g., 'BQ40Z50', 'BQ40Z50-R2', 'ADAU1701'). Revision suffixes are normalized.
`question`	Yes	What to find: keywords, register hex (e.g. 0x51), signal names, parameters.
`maxDocsToIndex`	No	Ignored (legacy). Lookup does not index PDFs; use read_doc.

TDQS

A5/5.0

Behavior5/5

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

Discloses key behaviors: FTS over local index only, no PDF indexing, returns chunks vs suggestedDocuments, and that maxDocsToIndex is ignored. No annotations provided, so description carries full burden and fulfills it well.

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?

Concise yet comprehensive, using bold for emphasis and a logical flow. Every sentence adds value without redundancy.

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?

Fully contextualizes the tool for an AI agent: explains behavior, limitations, next steps, and references a resource guide. No output schema or annotations, but description compensates completely.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema: specifies vendor values, explains part revision normalization, clarifies question usage, and indicates maxDocsToIndex is legacy/ignored. Schema coverage is 100%, but description provides crucial additional context.

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 it performs full-text search over a local index for part numbers and questions, distinguishing it from sibling tools by explicitly noting it does not download or index PDFs.

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?

Provides explicit when-to-use and when-not-to-use guidance, including next steps (read_doc, query_doc_content) and mentions a known limitation (TI symlink datasheets may be missing from suggestions).

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

query_doc_contentA

BM25 full-text search over indexed chunks. Each hit includes docUrl and pageNum — use them with read_doc_page for full page text. Requires PDFs indexed via read_doc (lookup alone does not index).

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`query`	Yes	The text to search for within indexed documents (e.g., 'VCELL register', 'SoC calculation', 'maximum input voltage').
`part`	No	Optional: restrict search to documents for a specific part number (e.g., 'BQ40Z50').
`docType`	No	Optional: restrict search to a specific document type ('user_guide' for TRMs, 'datasheet' for electrical specs).
`limit`	No	Max number of results to return (default: 8, max: 20).

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the search nature and result fields but does not elaborate on non-obvious behaviors like rate limits, authentication, or destructive potential. The tool is inherently read-only, which is implied but not stated.

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 three sentences, each with a clear purpose: state the tool's function, describe output fields, and specify prerequisites. No redundant information; front-loaded with the core purpose.

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 tool with 5 parameters and no output schema, the description covers the main purpose, output structure, and inter-tool dependencies. It lacks details on query syntax or ranking, but the schema descriptions for parameters are thorough. Overall, adequately complete for effective use.

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?

Input schema coverage is 100% with descriptions already explaining each param. The description adds context about requiring indexing and output format, which aids understanding but does not significantly enhance parameter meaning beyond what the schema provides.

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 it performs 'BM25 full-text search over indexed chunks' with specific result fields. It distinguishes itself from siblings by explicitly mentioning the use of read_doc_page for full text and the prerequisite of indexing via read_doc.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the tool (for searching indexed chunks) and what prerequisites exist (PDFs must be indexed via read_doc). It also suggests a follow-up tool (read_doc_page). However, it does not explicitly state when to avoid this tool or compare directly to siblings like search_docs.

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

read_docA

Download and index a PDF by direct URL (required for TI /lit/ds/symlink/....pdf links and any PDF not found via lookup). Often works better than lookup when you already have the exact PDF link. Pass part when known. Then use query_doc_content or read_doc_page.

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`docIdOrUrl`	Yes	PDF URL to download and index.
`part`	No	Optional part number for metadata (strongly recommended; avoids UNKNOWN part rows).
`title`	No	Optional document title for metadata.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description adds behavioral context: downloads and indexes a PDF, requires direct URL, recommends part to avoid UNKNOWN rows. Hints at side effects (indexing) and prerequisites.

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?

Concise, front-loaded, every sentence adds value. No redundancy.

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?

Covers usage context, parameter emphasis, follow-up actions. Lacks output description, but no output schema is provided. Complete enough for effective agent use.

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%, but description adds value by emphasizing 'part' as strongly recommended and clarifying docIdOrUrl as PDF URL. Enhances understanding beyond 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?

Clearly states the tool downloads and indexes a PDF by direct URL, specifying it's for TI links and PDFs not found via lookup. Distinguishes from sibling tools like lookup_doc.

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

Usage Guidelines4/5

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

Explicitly describes when to use (direct URL required, better than lookup with exact link) and what to do after (use query_doc_content or read_doc_page). Lacks explicit when-not-to-use, but context is clear.

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

read_doc_pageA

Return full indexed plain text for one PDF page or a page range (after query_doc_content gives you pageNum). Requires the document to already be indexed. Pass docUrl exactly as in search results (or the PDF URL used with read_doc). Use this when snippets are too short for tables or register maps.

ParametersJSON Schema

Name	Required	Description
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`docUrl`	Yes	PDF document URL as returned by search_docs / query_doc_content (doc is identified by URL).
`page`	Yes	1-based PDF page number (same numbering as query_doc_content pageNum).
`pageEnd`	No	Optional inclusive end page for a range. If omitted, only page is returned.
`maxChars`	No	Max characters of text to return (default 120000, hard cap 500000). Truncation sets truncated=true in the JSON.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the read-only operation (implied by 'return'), requires indexed documents, and mentions truncation behavior (maxChars cap, truncated flag). It does not detail rate limits or error handling, but for a read retrieval 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.

Conciseness5/5

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

The description is two sentences with no redundancy. Each part serves a purpose: purpose statement, prerequisite, parameter guidance, and usage context. Perfectly concise.

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

Completeness3/5

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

While the description covers purpose and guidelines, it lacks information about the output structure (beyond mentioning truncated flag) and error conditions (e.g., invalid page, unindexed document). Given no output schema, more details would improve completeness.

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%, but the description adds context beyond the schema: docUrl must be exactly as in search results, pageEnd is optional for a range, maxChars default and hard cap with truncation flag. This aids correct parameter usage.

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 explicitly states it returns full indexed plain text for a PDF page or page range, and references query_doc_content for getting page numbers. It clearly distinguishes from siblings by noting usage when snippets are too short.

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

Usage Guidelines4/5

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

The description gives an explicit use case: when snippets are too short for tables or register maps. It also mentions prerequisites (document must be indexed, docUrl must be as in search results). It could be improved by explicitly stating when not to use (e.g., for whole documents, use read_doc).

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

search_docsA

Primitive: list PDF links (datasheet, TRM, app notes) for a part from the vendor site. Does not index. After lookup returns only suggestions, you can use this for a fuller link list.

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	Yes	Vendor ID: TI, ST, ADI.
`query`	Yes	Part number or search term (e.g., 'LM317', 'BQ40Z50', 'BQ40Z50-R5', 'ADAU1701').

TDQS

A3.5/5.0

Behavior3/5

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

Discloses it does not index and relationship to lookup results. No annotations exist, so description carries full burden. Lacks details on read-only nature, rate limits, or authentication.

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?

Two sentences, front-loaded with key action. No unnecessary words. Efficient and well-structured.

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

Completeness3/5

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

Adequate for low complexity tool with full schema. Explains purpose and behavior relative to lookup. Lacks output format details, though implied by 'list PDF links'. No output schema to compensate.

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 already fully describes parameters (vendor, query). Description adds little beyond mentioning 'vendor site', which aligns with vendor parameter. Baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists PDF links for a part from vendor site. Distinguishes itself from indexing. However, could more explicitly differentiate from sibling tools like list_indexed_documents and lookup_doc.

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?

Provides context for use after lookup that returns suggestions. But does not explicitly state when not to use or compare to alternatives like lookup_doc or query_doc_content.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0May 29, 2026
- First observedlist_indexed_documents
- First observedlookup_doc
- First observedquery_doc_content
- First observedread_doc
- First observedread_doc_page
- First observedsearch_docs

Install Server

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

TDQS

A4/5.0

Disambiguation4/5

Tools have distinct purposes: listing indexed docs, lookup/search over index, fetching/indexing PDFs, reading pages, and searching for links. Some overlap exists between lookup_doc and search_docs, but descriptions clarify their roles.

Naming Consistency4/5

Most tool names follow verb_noun pattern with underscores, but 'list_indexed_documents' uses full 'documents' while others use 'doc', and 'lookup_doc' uses 'lookup' as verb. Minor inconsistency, but overall pattern is clear.

Tool Count4/5

Six tools cover the core workflow of finding, indexing, and reading PDFs. The count feels appropriate for the domain, though a tool for managing the index (e.g., delete) could be added.

Completeness4/5

The tool set covers listing, searching, indexing, and reading documents. Missing operations like deleting indexed documents are minor gaps; the main user workflows are well-supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

sheetsdata-mcp A
io.github.octoco-ltd
Electronic component datasheets for AI agents — specs, pinouts, package data on demand.
Embedded system Developer Tools Research & Data
12210
embedded-docs A
ai.byteask
Page-cited retrieval for embedded docs, datasheets, MISRA, CMSIS, and RTOS references.
Embedded system Documentation Access
3223
ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2
TomeVault AOAuth
io.github.olijboyd
Search, fetch (with provenance), scan, and convert AI instruction files for agents.
Documentation Access Knowledge & Memory Search
172

Related MCP Servers

RAG Database MCP Server
RAG Systems Vector Databases Search
Human-center
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search and query PDF documents through a local RAG system with vector embeddings. Provides semantic document search capabilities while keeping all data stored locally without external dependencies.
Updated a year ago (2025-09-14 03:01 UTC)
-
PDF RAG MCP Server
RAG Systems Vector Databases Documentation Access
wesleygriffin
A
license
Not graded
quality
D
maintenance
Enables intelligent search and question-answering over PDF documents using semantic similarity and keyword search. Supports OCR for scanned PDFs, persistent vector storage with ChromaDB, and maintains source tracking with page numbers.
Updated 10 months ago (2025-11-11 03:07 UTC)
6
MIT
pdfsearch-mcp
Search Documentation Access RAG Systems
russellbrenner
F
license
Not graded
quality
Not graded
maintenance
Enables local indexing and semantic search of PDF documents (like AGLC4 style guide) with OCR support, allowing LLM tools to query PDF content and retrieve relevant text snippets with context.
Updated a year ago (2025-09-15 07:16 UTC)
-
SheetsData MCP
Developer Tools Research & Data Embedded system
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.
Updated 4 months ago (2026-04-26 15:57 UTC)
12
84
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/flaco-source/mcp-docs'

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

Electronics Docs MCP Server

Tools

MCP resources

Cursor skill (optional)

Supported vendors

Recent changes (server v2.7.x)

Adding a new vendor (hot plug)

Development

Transport modes

stdio mode (local — Cursor / Claude Desktop)

How "local" works

Cursor MCP config (Node — recommended)

Cursor MCP config (Docker)

Claude Desktop

HTTP mode (LAN / remote)

Quick start

Environment variables

Health check

Test a tool call (curl)

Cursor mcp.json (remote Streamable HTTP)

Exposing to the internet

Option A — ngrok (fastest, for short-term testing)

Option B — Cloudflare Tunnel (free, stable, no open port)

Option C — Docker + VPS / cloud (permanent deployment)

Option D — Docker Compose (self-hosted server)

Option E — Vercel (serverless)

Project structure

Testing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Cursor `mcp.json` (remote Streamable HTTP)