kicad-mcp-layer

Overview Schema Source Related Servers Discussions Admin

doc_fetch

Idempotent

Download a technical document into the project's documentation library and index it with source, date, size and hash. Handles redirects, PDF viewers and scripted download portals via headless browser.

Instructions

Download a technical document into the project's documentation library (research/references by default) and index it with its source URL, date, size and hash. A plain fetch with browser-grade headers comes first; it follows redirects and a single PDF link on a viewer page. When a site answers with a scripted download portal or refuses the plain client, headless Chromium loads the page and takes the download it offers. If that fails too (login walls, bot checks), the error says so: open the URL in a browser, save the file, and use doc_import. Find URLs with web search first; manufacturer sites and distributor mirrors usually both work.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	Direct URL of the document, usually a PDF datasheet, application note or reference-design archive.
`tags`	No	Keywords for later lookup, e.g. ['poe', 'silvertel', 'ag5405'].
`notes`	No
`title`	No	Human title, e.g. 'Silvertel Ag5400 PoE module datasheet'.
`expect`	No		pdf
`subdir`	No	Folder inside the documentation library, e.g. datasheets, reference-designs, standards.	datasheets
`browser`	No	auto: try a plain fetch, then headless Chromium when the site answers with a page or refuses; always: start in the browser; never: plain fetch only.	auto
`filename`	No	File name to store under; default derived from the URL.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Stable id: first 12 hex digits of the file's SHA-256.
`file`	Yes	Path relative to the documentation library.
`path`	Yes	Path relative to the workspace.
`size`	Yes
`tags`	No
`notes`	No
`pages`	No
`title`	Yes
`sha256`	Yes
`fetched`	Yes	Date the file entered the library (YYYY-MM-DD).
`source_url`	No
`content_type`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A3.8/5.0

Behavior1/5

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

The annotations declare openWorldHint=false, yet the entire description is about interacting with an open world of external websites (manufacturer sites, distributor mirrors, scripted download portals, login walls, bot checks). That is a direct contradiction of the annotation, so per the rubric this scores 1 even though the description otherwise discloses rich fallback/error 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?

Five tight sentences that front-load the core action before describing the fetch/browser/fallback ladder. Each sentence carries load-bearing information about mechanics or failure handling, with only minor redundancy around the browser-vs-plain-fetch decision.

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?

An output schema exists, so return values need no explanation. For a network tool with 8 parameters, 1 required, and complex browser-fallback behavior, the description covers the operational flow, failure routing to doc_import, and where to source URLs adequately.

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 75%, so the schema already documents url, tags, title, subdir, browser and filename, and this is the baseline case. The description adds library-location context but leaves expect and notes unexplained and does not reconcile its stated default ('research/references') with the schema's subdir default ('datasheets').

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 ('Download a technical document into the project's documentation library') and clarifies scope (research/references by default, indexed with URL, date, size, hash). It clearly distinguishes itself from the sibling doc_import, which is named as the redirect target when fetching fails.

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?

Gives explicit when-to-use guidance for each mode: plain fetch first, headless Chromium when the site serves a scripted portal or refuses the client, and doc_import when login walls/bot checks defeat both. It also says where to find URLs ('web search first; manufacturer sites and distributor mirrors usually both work').

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