jlcpcb-mcp

by Eyalm321

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.3
Disambiguation3/5
Most tools have distinct purposes, but there is clear overlap among component info tools: jlcpcb_get_component_details, jlcpcb_get_component_stock, jlcpcb_get_component_pricing, and jlcpcb_official_get_component_detail all return similar data. The official/public split adds confusion. TDP and PCB tools are well-separated.
Naming Consistency3/5
Names consistently use the jlcpcb_ prefix with subdomain (official_, tdp_, pcb_) and mostly follow a verb_noun structure. However, several tools are noun phrases (official_component_library, database_status, tdp_file_analysis_result, pcb_impedance_template_list) and the official component tools mix verbs and nouns (official_get_component_detail vs official_component_feed).
Tool Count4/5
28 tools is high, but the server covers three distinct services (components, PCB, 3D printing), each with around 9 tools. This makes the count defensible, though slightly heavy for a single surface.
Completeness4/5
The major lifecycle flows are covered: search/details/price/order for components and TDP, upload/quote/order/track for PCB. The only notable gap is the lack of a PCB order list (only detail by batch number).
Average 4.1/5 across 28 of 28 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 of behavioral disclosure. It mentions that it requires API credentials, which is useful, but it does not disclose whether the operation is read-only, whether it returns any particular status, or any rate limits. For a tool that fetches audit info, the agent is left to guess the response format and behavior. The description adds minimal behavioral context beyond the credentials requirement.
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, efficient sentence that states the purpose and a key requirement. No filler words. It front-loads the action ('Official PCB API: get engineering audit info') and includes essential context ('Requires API credentials.'). This is appropriately sized 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?
Given that there is no output schema and no annotations, the description should compensate by explaining what the audit info is used for, any prerequisites beyond credentials (e.g., prior upload), and the response nature. The tool has only 2 simple parameters, so complexity is low, but the description lacks return-value details and operational context. It is minimally viable but with clear gaps.
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 100%, with both parameters described ('Audit key (e.g. the fileKey/order key)' and 'Language code, if supported'). The description itself does not add extra semantics beyond the schema; it only mentions 'by key', which aligns with the schema. Since the schema fully documents the parameters, the baseline of 3 is appropriate, though the description's 'by key' somewhat reinforces the key parameter's meaning.
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?
The description clearly states the verb 'get' and the resource 'engineering audit (review) info for an uploaded design by key', which distinguishes this tool from siblings like order detail or file analysis. It names the key parameter and indicates it retrieves audit information, making the core purpose clear. It could further differentiate from jlcpcb_pcb_get_order_detail and jlcpcb_tdp_file_analysis_result, but the phrase 'by key' and 'engineering audit (review) info' gives adequate specificity.
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 phrase 'Official PCB API' sets context and 'Requires API credentials.' provides a prerequisite. However, there is no explicit guidance on when to use this tool versus alternatives like jlcpcb_pcb_get_order_detail or jlcpcb_tdp_file_analysis_result. The 'by key' hint implies it's for a specific audit key, but it does not specify scenarios. Thus, it provides clear context but lacks exclusions or explicit alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the useful requirement of API credentials, which is a significant operational constraint. However, it does not mention read-only status, error handling, or the shape of the returned data, leaving some behavioral ambiguities for a simple getter.
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?
The description is brief and front-loaded with the tool's core purpose ('Official PCB API'). The single sentence is efficient, though the credential requirement could be integrated more seamlessly. No unnecessary words or repetition.
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?
Although the tool is simple with one parameter, the absence of an output schema and the lack of any mention of what the returned order detail contains leaves the description somewhat incomplete. The sibling context helps disambiguate but does not substitute for describing the return value or typical response behavior.
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 coverage is 100%, so the schema already documents the batch_num parameter with a description. The tool description merely repeats 'by batch number' without adding syntax, format details, or examples, placing it at the baseline score of 3.
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 the verb 'get', the resource 'order details', and the unique identifier 'batch number'. This distinguishes it from sibling tools like jlcpcb_pcb_get_audit_info and jlcpcb_pcb_get_wip_process, which focus on different PCB order aspects.
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 order details by batch number, but it does not explicitly state when to prefer this over alternatives such as jlcpcb_tdp_order_detail or other order-related tools. No exclusions or alternate tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the fallback behavior ('prefers live API, falls back to catalog snapshot'), which is useful context about potential data source variability. However, it does not state whether the operation is read-only, how errors are handled, or what the URL format will be.
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 precise sentences: the first states the primary action and second adds a key behavioral detail. No redundant content or filler.
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, one-parameter read tool with no output schema, the description provides the core purpose and an important behavioral nuance (fallback logic). It is not fully complete (no error/edge-case mention), but sufficient for straightforward invocation.
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?
The input schema covers 100% of parameter descriptions, including the part number format and optional 'C' prefix. The description adds no additional parameter detail, but the schema already provides sufficient guidance, so a baseline of 3 is appropriate.
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 uses a specific verb ('Get') and resource ('datasheet PDF URL for a specific JLCPCB part'), clearly distinguishing it from sibling tools that handle components, pricing, or orders.
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), but does not explicitly mention alternatives or exclusions, such as 'for full component details use get_component_details'. It relies on the specificity of the tool name and the phrase 'specific part'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It discloses that the operation is a read-only status retrieval ('get') and that credentials are required, which partially informs the agent about authentication needs. However, it does not mention what the response contains, potential side effects (though likely none), or any rate limits. This is a minimal but acceptable level of disclosure for a simple status-check tool.
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 concise sentences, front-loaded with the core purpose and followed by the key prerequisite. Every word earns its place: the verb, resource, and credential requirement are all essential. There is no fluff, repetition, or unnecessary jargon.
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 no output schema, the description provides the essential context: the action (get WIP status), the target (an order), and the prerequisite (API credentials). It does not explicitly describe the return format, but 'work-in-progress production status' implicitly indicates what the response will contain. The sibling context shows this is one of several order-related tools, and the description sufficiently distinguishes its specific purpose. Given the low complexity, the description is nearly complete, only missing explicit output details.
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?
The input schema fully describes the single parameter 'order_uuid' as 'Order UUID,' achieving 100% schema coverage. The description's phrase 'for an order' merely echoes the schema and adds no extra semantic detail about the parameter format, constraints, or how to obtain it. Since schema coverage is high, the baseline of 3 is appropriate; the description does not add value 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 the tool's function with a specific verb and resource: 'get the work-in-progress production status for an order.' This distinguishes it from siblings like jlcpcb_pcb_get_order_detail, which likely covers broader order details. The 'Official PCB API' prefix adds authoritative context, leaving no ambiguity about what the tool does.
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 by stating the purpose (e.g., use this to check WIP status), but it provides no explicit when-to-use or when-not-to-use guidance relative to siblings like jlcpcb_pcb_get_order_detail or jlcpcb_tdp_order_process. The only prerequisite mentioned is 'Requires API credentials,' which is a general constraint rather than a usage scenario. This is adequate for an implied-use tool but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context by stating 'Requires API credentials' and 'Official PCB API', but it does not explicitly state that this is a read-only operation, nor does it describe the response format or any rate limits. The 'get' verb implies reading, but the description could be more transparent about expected behavior.
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 that immediately conveys the tool's purpose and then adds the essential credential requirement. There is no redundant or filler content; every word earns its place.
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 no-parameter, simple getter tool with no output schema, the description is nearly complete. It states what it does and the auth prerequisite. However, it lacks any note about return value characteristics or potential error scenarios, which could be valuable for an agent deciding whether to invoke it. Still, it is adequate for the simplicity of the 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?
The tool has zero parameters, so the schema is trivially complete (100% coverage). The description does not need to explain parameter semantics because there are none. This aligns with the baseline for 0-parameter tools, where the description's clarity about the operation is sufficient.
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 ('get') and a specific resource ('SMT stencil (steel) price configuration'), which distinguishes it from sibling tools like jlcpcb_pcb_calculate_price that handle full PCB pricing. The mention of 'Official PCB API' further clarifies its provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While the resource is specific, the description does not mention exclusions or alternatives, such as using jlcpcb_pcb_calculate_price for general PCB pricing. The only prerequisite mentioned is API credentials, but that is a general requirement rather than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses that API credentials are required and that it is an official 3D-printing API. It does not describe response format, rate limits, or error behavior, though the read-only nature is implied.
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 front-loaded and uses only 17 words to convey the domain, action, input, and credential requirement—every word serves a 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 single-parameter lookup tool, the description adequately conveys the input and purpose, but could optionally mention what kind of details are returned or provide links to related tools to be fully context-rich.
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 coverage is 100% with a clear description for batch_num, and the tool description repeats the need for a batch number without adding semantic detail beyond 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?
The description uses a specific verb ('get') and resource ('3D-printing order's details') along with the required batch number, clearly distinguishing it from sibling tools like jlcpcb_tdp_order_list (list) and jlcpcb_pcb_get_order_detail (PCB domain).
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 have a batch number and need order details, and specifies the 3D-printing domain, but it does not explicitly mention alternatives or exclusions, such as using jlcpcb_tdp_order_list for a list of orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the data is 'live' and provides USD unit prices per quantity break, which is useful behavioral info. However, it does not mention potential rate limits, return format details, or error behavior, leaving some gaps for a read operation.
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 that efficiently states the tool's purpose and output. Every word adds value, and there is no redundant or extra information.
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?
Given the tool's simplicity (one parameter, no output schema), the description adequately explains what it returns (pricing tiers). It covers the essential information needed for correct invocation and interpretation, though it could theoretically mention if prices exclude taxes or fees, but that's not critical.
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?
The input schema already documents the single required parameter 'lcsc' with examples and format details (e.g., 'C17976' and optional 'C'). The description does not add any further meaning to the parameter, so the baseline of 3 is appropriate.
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 uses a specific verb 'Get' and clearly specifies the resource ('live quantity-break pricing tiers') for a specific JLCPCB part. It distinguishes from siblings like get_component_stock or get_component_details by emphasizing pricing rather than stock or general details.
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 clearly indicates this tool is for retrieving pricing tiers, which gives clear context for when to use it. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent would select this over sibling tools for pricing queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses authentication requirements, cursor-based pagination, and the need to reuse the returned lastKey. It does not detail rate limits or failure behavior, but the core behavioral traits are clearly 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?
Two tightly worded sentences that front-load the official/authenticated identity and then immediately explain the pagination mechanism. Every phrase earns its place with no wasted words.
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 description gives enough context to select and start using the tool: it names the output domain (component catalog), explains paging, and notes credentials. It stops short of describing the item fields or page shape, but for a bulk feed without an output schema this is a reasonable level of detail.
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?
The schema already covers the single parameter at 100% coverage, including the 'omit for the first page' instruction. The description reinforces the cursor reuse behavior and adds the 'entire library' context, but provides little new semantic information beyond 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?
The description immediately identifies this as an authenticated, cursor-paginated bulk feed of the JLCPCB component catalog. It provides a specific action—page through the entire library—and distinguishes itself from detail/lookup tools by emphasizing full-catalog bulk retrieval.
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?
It states the prerequisite of API credentials and describes the intended use case of iterating the full catalog. However, it does not explicitly contrast with sibling tools like jlcpcb_official_component_library or jlcpcb_search_components, nor does it explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing 'Requires API credentials' (auth needs) and 'paginated' (iteration behavior). It also implies a read-only operation via 'browse'. It does not detail response format or rate limits, but for a simple list tool this is solid coverage.
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 sentence that front-loads the core purpose ('browse the full assembly component library, paginated'), then adds necessary context ('Requires API credentials'). Every word earns its place; there is no fluff or repetition.
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 two-parameter paginated list tool with no output schema, the description covers the essential context: the resource, pagination, and authentication. It lacks explicit alternative guidance, but that is a usage-consideration gap rather than a completeness gap for the tool's core function.
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?
The input schema already provides 100% description coverage for both page and page_size, so the schema does the heavy lifting. The description only mentions 'paginated,' which reinforces the parameter purpose but adds no new parameter-level semantics. Baseline 3 is appropriate.
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 the tool 'browse[s] the full assembly component library' with a specific verb and resource, and adds 'paginated' and 'Official JLCPCB Parts API' context. This distinguishes it from siblings like jlcpcb_search_components (search) and jlcpcb_official_get_component_detail (detail), which focus on different operations.
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 provides context that the tool is authenticated and browses the full library, which implies use for enumerating components. However, it does not explicitly name alternatives or state when to prefer this over siblings like jlcpcb_search_components or jlcpcb_official_component_feed, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication requirements and that it is paginated, adding useful behavioral context. However, it does not mention potential error conditions, rate limits, or explicitly state that this is a read-only operation, leaving some ambiguity for a tool that likely involves network calls.
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, front-loaded with the primary purpose ('list YOUR account's private / consigned component library'), and includes essential context (authenticated, paginated, credentials). Every phrase contributes value without unnecessary fluff.
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?
Given the low complexity (2 optional params, no nested objects) and no output schema, the description adequately covers the main use case, authentication, and pagination. It could have briefly described the return shape (e.g., component list with pagination info) since no output schema exists, but the description is largely complete for a list operation.
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 coverage is 100%, with both parameters (page and page_size) already described in the schema. The description adds the term 'paginated' which connects to these parameters but provides no additional semantic detail beyond what the schema already gives. This meets the baseline for high 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 uses a specific verb ('list') with a clear resource ('YOUR account's private / consigned component library'), and explicitly distinguishes this from the public library by highlighting the account scope. The purpose is unambiguous and differentiates from sibling tools like jlcpcb_official_component_library.
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 clearly states when this tool is applicable (authenticated, only with API credentials) and implies it is for private/consigned parts rather than public catalog parts. It does not explicitly name alternative tools, but the account-specific scope provides adequate contextual guidance against using the general component library tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the authentication requirement ('Requires API credentials'), which is a key behavioral constraint. However, it does not explicitly state whether the operation is read-only or has side effects, nor does it describe response format or rate limits. Since no annotations are provided, the description carries the full burden, and this is only partially met.
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, focused sentence that front-loads the core purpose and includes necessary auth context. Every word adds value, and there is no wasted text.
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?
Given the simplicity of the tool (one optional filter object, no output schema), the description is largely sufficient. It includes the purpose, example filter parameters, and auth requirement. It could be more complete by describing the response format or clarifying read-only behavior, but it covers the essential context for selection and invocation.
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?
The input schema describes 'params' as an optional filter object with examples (stencilLayer, cuprumThickness, plateType), and the tool description repeats these same examples. The description adds no additional parameter meaning beyond what the schema already provides. With full schema coverage, the baseline of 3 is appropriate.
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 the action ('list impedance template settings') and specifies the inputs ('given stackup parameters') with concrete examples. It distinguishes itself from siblings by focusing on impedance templates, a unique resource among the many PCB-related tools.
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 indicates when to use the tool: when you have stackup parameters and need impedance template settings. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over other PCB tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It adds the prerequisite 'Requires API credentials', which is useful authentication context. However, it does not disclose other behavioral traits such as side effects, file format restrictions, or what happens after upload, leaving some ambiguity.
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 brief sentences, front-loaded with the core action and resource. It contains no superfluous information, efficiently conveying purpose and credential requirements.
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 upload tool with two well-documented parameters, the description provides the necessary context: purpose, prerequisite, and scope. While it lacks explicit return-value information (no output schema), this is a minor gap for a straightforward upload operation.
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?
The input schema already provides 100% coverage for both parameters: 'file_path' describes the local path and reading behavior, and 'file_name' explains the override and default. The tool description adds no additional parameter meaning, aligning with the baseline of 3 for full 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 uses a specific verb ('upload'), identifies the resource ('blind/buried-via stackup image'), and states the scope ('for boards that need one'). This clearly differentiates it from sibling tools like 'jlcpcb_pcb_upload_gerber', which uploads gerber files.
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 phrase 'for boards that need one' implies the conditional use case, indicating when this tool is appropriate. However, it does not explicitly mention alternatives or when not to use the tool, though the resource type distinguishes it from related upload tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the local SQLite snapshot as the data source (implying possible staleness), and importantly distinguishes `jlc_assembly_stock` from `lcsc_retail_stock`, warning that a 0 in retail stock is NOT an assembly shortage. It also discloses the result ranking (Basic-first, assembly stock, unit price). This is strong behavioral context, though it doesn't explicitly state the tool is read-only or cover error handling.
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: 4 sentences plus examples, front-loaded with the core purpose. Every sentence adds value—the SQLite snapshot note, the stock field clarification, and the ranking explanation are all essential for correct interpretation. The examples are useful and take minimal space. No fluff or 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?
Given the tool's complexity (13 parameters, no output schema, no annotations), the description covers important context: data source, stock field meanings, ranking, and example queries. It hints at result fields (descriptions, packages, attributes, categories). It could mention pagination, error behavior, or a more explicit return format, but it is reasonably complete for a search tool.
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?
All 13 parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds example queries and clarifies result semantics but does not provide additional parameter-level meaning beyond the schema. It matches the baseline without adding notable parameter guidance.
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?
The description clearly states the tool's function: 'Search the JLCPCB component catalog by keyword and/or parametric filters, enriched with live pricing.' This provides a specific verb (Search), resource (JLCPCB component catalog), and scope (keyword/parametric filters). It also gives example queries, which reinforce purpose. However, it does not explicitly contrast with sibling tools like jlcpcb_get_component_stock or jlcpcb_official_component_library, so it stops short of a 5.
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 clear usage context by providing example search queries ('10k resistor 0805', 'STM32F4', 'ceramic capacitor') and explaining key behavior like ranking and stock fields. It implies this tool is for searching the catalog, but it does not explicitly state when not to use it or mention alternative tools. This is clear context without explicit exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the operation is a fetch (implying read-only) and requires API credentials, which is useful. However, it does not elaborate on side effects, rate limits, or error behavior, leaving some burden on the agent.
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 exceptionally concise: one sentence with a clear verb, resource details, and a credential prerequisite. The parenthetical list of result contents adds value without excess length.
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 single-parameter tool with no output schema, the description sufficiently covers the purpose, input, and credential requirement. It could mention the exact return format, but the tool's low complexity makes this adequate.
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?
The schema already fully describes the single parameter (file_access_id with its source), yielding 100% schema coverage. The description reinforces the purpose by mentioning 'by its fileAccessId' but adds no new format or constraint details beyond 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?
The description uses a specific verb ('fetch') and identifies the resource ('analysis result' with dimensions/volume/printability) for an uploaded model, clearly distinguishing it from sibling tools like pricing or order management. The 'Official 3D-printing API' prefix adds context without ambiguity.
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 implies usage after uploading a model by referring to fileAccessId from a prior upload and mentioning API credentials as a prerequisite. It does not explicitly name alternatives or exclusions, but the context is clear enough for a straightforward fetch operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions pagination/filterability and that API credentials are required, which are useful. However, it does not describe the response format, default parameters, rate limits, or explicitly state it's a read-only operation (though 'list' implies this).
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: the first states purpose, the second gives parameter guidance. Front-loaded, no redundant fluff, and every word contributes to understanding the tool.
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?
Given the tool's low complexity (one optional nested parameter, no output schema), the description covers the essential invocation details: purpose, filtering options, and authentication. It does not specify the return structure, but as a listing tool this is reasonably inferable. A slightly richer description of response content would make it a 5.
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?
The schema provides 100% coverage of the 'params' property with a description listing the possible keys (currentPage, pageRows, orderStatus, searchKey, businessType, ...), and the tool description repeats these same keys without adding new types, constraints, or behavior details. Thus the description adds minimal semantic value beyond 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?
The description identifies a specific action ('list'), a distinct resource ('your 3D-printing orders'), and clarifies scope ('your'), which distinguishes it from sibling tools like jlcpcb_tdp_order_detail (single order) and jlcpcb_tdp_create_order (creation).
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?
It clearly states the tool is for listing 3D-printing orders and supports pagination/filtering, which implies when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use jlcpcb_tdp_order_detail for a single order'), so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a key operational requirement: 'Requires API credentials.' The verb 'get' implicitly signifies a read-only operation, but it does not explicitly state the absence of side effects or describe any rate limits, error behavior, or return format. For a simple read tool, the credential note is valuable, but more transparency (e.g., 'does not modify order') would improve the score.
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, information-dense sentence. It front-loads the API domain ('Official 3D-printing API'), states the action and target, and includes the credential requirement. No unnecessary words or repetition.
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 one-parameter, single-purpose query tool with no output schema and no annotations, the description provides sufficient context: what it does, what input is needed, and a prerequisite. It doesn't describe the response shape, but the phrase 'get production progress' implies the nature of the output. It could mention error cases or more about the response, but given the low complexity, this is largely complete.
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?
The schema already provides 100% coverage by defining order_no as 'Order number'. The description adds little beyond reinforcing that the order is identified by number, and it does not specify format, source, or validation rules. With high schema coverage, the baseline of 3 is appropriate; description does not need to compensate.
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 uses a specific verb ('get') and resource ('production progress for a 3D-printing order') and clearly identifies the order by number. This distinguishes it from sibling tools like order_list (listing orders) and create_order (creating orders). It also explicitly scopes it to the 3D-printing API, separating it from PCB-related tools.
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 implies usage context: the agent must have an order number (likely from order_list or create_order) and should call this tool to check progress. It clearly states the input requirement ('by order number') and the domain (3D-printing). However, it does not explicitly name alternatives or exclusions, but the focus on 'production progress' distinguishes it from sibling tools like order_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 key behavior (upload returns a fileAccessId) and a prerequisite (API credentials), which is valuable. However, it omits other behavioral traits like file storage lifetime, size limits, error behavior, or whether the file is validated synchronously. This is adequate but not rich.
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 only two sentences, front-loads the core purpose, and includes essential context (return value, prerequisites). No wasted words, every sentence earns its place.
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 no output schema, the description adequately covers input (3D model file), output (fileAccessId), and place in the workflow (used by other TDP tools). It does not discuss error cases or limits, but for an upload tool this level of detail is reasonable and complete given the tool's simplicity.
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 coverage is 100% with both file_path and file_name documented. The description adds the file type examples (STL/STEP) which adds some context beyond the schema, but it does not explain file_name's override behavior beyond what the schema already states. Baseline of 3 is appropriate.
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 the tool uploads a 3D model file (STL/STEP) for analysis and quoting, with a specific verb and resource. It also distinguishes itself from sibling TDP tools by mentioning it returns a fileAccessId used by other TDP tools, and identifies itself as the official 3D-printing API, separating it from PCB upload tools.
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 usage context: it should be used first to obtain a fileAccessId for subsequent TDP operations (analysis, pricing, ordering). It also notes the prerequisite of API credentials. It does not explicitly name alternatives or exclusions, but the fileAccessId workflow strongly implies when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It explicitly discloses the reported information (file path, size, component count, last built/refreshed) and implies a read-only operation. This is transparent, though it could mention potential edge cases like the database not existing.
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, focused sentence with a clear subject-verb-object structure. It front-loads the main purpose and lists specifics without unnecessary detail.
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?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains what the tool reports. It could benefit from mentioning the return format or error behavior, but the listed details are sufficient for an agent to understand the tool's function.
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 tool has zero parameters, so the baseline is 4. The description provides meaningful context about what the tool returns, which is sufficient since there are no parameters to clarify.
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 the tool reports the status of the local component catalog database, listing specific data points (existence, path, size, component count, last refresh). This distinguishes it from sibling tools like jlcpcb_refresh_database, which performs a different action.
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 the tool is used to check the database status but does not explicitly specify when to use it versus alternatives (e.g., before refreshing or searching). The context is clear but lacks explicit exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses authentication requirements and the authoritative/more-complete nature of the data, which is valuable context. It does not mention rate limits or side effects, but the 'get' action and lack of mutation cues suggest a non-destructive read; considering the explicit auth and data-quality disclosure, it covers key behavioral aspects.
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 long, front-loads the official API context and purpose, and contains no filler. Every phrase contributes meaning, making it highly concise and well-structured.
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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides a solid context: it names the input, enumerates the fields returned, and highlights the authenticated/official nature. It omits response format details or error handling, but for a straightforward getter with a clear scope, this is sufficiently complete.
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 100% and the schema already documents the 'codes' parameter with an example. The description repeats that it accepts LCSC part codes and supports one or more, which largely mirrors the schema and adds minimal new semantic information. Thus, the baseline of 3 is appropriate.
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 the tool's function: fetching authoritative details (specs, stock, pricing, attributes) for one or more LCSC part codes. It uses specific verbs and resource, and the 'Official' prefix plus 'More complete than the public live endpoint' distinguishes it from sibling tools like jlcpcb_get_component_details.
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 implies when to use this tool: when authenticated, authoritative, and more complete data is needed, explicitly comparing it to the public live endpoint. It notes the credential requirement, which acts as a prerequisite. However, it does not name specific alternatives or provide explicit 'when not to use' scenarios beyond the implicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that no order is placed (read-only), states that API credentials are required, and identifies it as official. This covers key behavioral aspects, though it does not mention return format or error conditions.
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 concise sentences, front-loaded with the main purpose and immediately clarifying the non-order behavior. Every word adds value with no filler.
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 price calculation tool with one nested object parameter, the description covers the essential parameters, credentials, and side-effect freedom. It is sufficient for a task of this complexity, though a brief note on return value format would make it fully complete.
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 coverage is 100% and the schema already lists the same parameter keys as the description. The description reiterates these keys but adds no deeper semantic meaning beyond what the schema provides, such as types, constraints, or relationships between parameters.
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 uses a specific verb ('calculate price') and resource ('3D-printing job'), and explicitly distinguishes itself by clarifying that it is a quote and no order is placed. This differentiates it from sibling tools like jlcpcb_tdp_create_order and jlcpcb_pcb_calculate_price.
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?
It clearly indicates the tool is for pricing a 3D-printing job and that it does not place an order, which implies when to use it before order creation. However, it does not explicitly name alternatives or state when not to use it, though the context is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that both stock pools are returned, which is authoritative, and the meaning of a 0 retail value. This is valuable behavioral context beyond what the schema shows. It does not mention rate limits or errors, but for a read-only lookup 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 one dense, well-structured sentence that front-loads the purpose and then specifies components and stock semantics. Every phrase earns its place, with no redundancy or fluff.
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?
Given the simplicity (one parameter, no output schema, no annotations), the description is remarkably complete. It details what is included, differentiates the two stock pools, and provides an interpretative warning. An agent can confidently invoke this tool based on the description alone.
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?
The input schema has 100% coverage for the single parameter 'lcsc', including an example and note that 'C' is optional. The description does not add any additional parameter semantics, but it doesn't need to because the schema fully documents it. Baseline 3 is appropriate.
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 uses a specific verb+resource ('Get full details for a specific JLCPCB part') and enumerates the exact data categories (catalog metadata, pricing tiers, specifications, datasheet, images, stock). It clearly distinguishes itself from siblings like jlcpcb_get_component_stock and jlcpcb_get_component_pricing by packaging all details together.
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: use this tool when you need comprehensive details for a part. It also includes exclusionary guidance by distinguishing assembly stock from retail stock and warning that an LCSC retail 0 is not an assembly shortage, which helps avoid misuse. It does not explicitly name alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It transparently describes what the tool does: listing categories and subcategories with counts, and optional filtering. The phrase 'local catalog' hints at a local data source. It does not mention return format or pagination, but for a simple list operation this is sufficient. No contradictions with annotations (none present).
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 long and front-loaded with the core action. The first sentence states exactly what the tool does, and the second explains its purpose. No wasted words or redundant information.
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 tool with one optional parameter and no output schema, the description fully covers what it returns (categories and subcategories with component counts), how to filter (optional category), and when to use it (discovering valid category filter values for searches). This is sufficiently complete for an agent to invoke correctly.
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?
The schema already provides 100% coverage with a clear description of the 'category' parameter ('Optionally restrict to one top-level category (case-insensitive contains match)'). The tool description merely rephrases this ('Optionally filter to a single top-level category') without adding new semantics, so it adds no value beyond the schema baseline.
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 the verb 'List' and the resource 'component categories and subcategories available in the local catalog,' with the added detail of component counts. It also mentions an optional filter, distinguishing it from sibling tools like jlcpcb_search_components by focusing on category discovery rather than component search.
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 final sentence provides explicit context for use: 'Useful for discovering valid `category` filter values for searches.' This indicates when to use it (before searching) and implies the alternative (search tools). However, it does not name specific sibling alternatives or explicitly state when NOT to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it fetches from two distinct pools, one from a catalog snapshot (assembly) and one live from wmsc.lcsc.com (retail), and explains their relationship. This goes beyond a basic read operation and prevents misinterpretation of stock data. It also notes that assembly stock is the authoritative number for PCBA.
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, front-loaded with the action, and every phrase adds value. It efficiently packs the essential distinction between the two stock pools without 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?
The description is complete for a simple stock-lookup tool with one parameter. It names the output fields (jlc_assembly_stock and lcsc_retail_stock) and gives interpretive guidance. It could mention the output format or response structure, but that is largely implied and not a major 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?
The input schema describes the 'lcsc' parameter thoroughly with examples and notes the optional 'C' prefix (100% coverage). The tool description itself does not add parameter-level detail, but the baseline of 3 applies because the schema already does the heavy lifting.
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 and resource: 'Get stock for a specific JLCPCB part.' It clearly distinguishes itself from sibling tools like pricing, details, and search by focusing on stock across two named inventory pools. The scope is explicit and unambiguous.
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?
It provides clear context on when to use the tool and how to interpret results: 'Treat assembly stock as authoritative for board production' and warns that LCSC-retail 0 does not imply unavailability. It does not explicitly name alternatives like jlcpcb_get_component_pricing, but the guidance is strong enough for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explicitly states 'no order is placed' (non-mutating) and 'Requires API credentials' (authentication), which are valuable behavioral traits. It does not mention rate limits, error handling, or return format, but given the quote-only nature, it is appropriately transparent.
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, front-loaded with the primary purpose, then adding parameter guidance and credentials. Every sentence earns its place with no verbose or redundant text.
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?
Given the tool's complexity (nested params, no output schema, no annotations), the description is largely complete: it states the purpose, input structure, credential requirement, and the non-mutating nature. It could include return value details, but the mention of 'price and lead time' sufficiently communicates the output expectation.
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 already covers the 'params' object with 100% coverage, listing all keys. The description adds extra value by elaborating on pcbParam with '(layers, dimensions, quantity, ...)', providing more meaning than the schema alone. This exceeds the baseline of 3.
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 the tool's function: 'calculate price and lead time for a PCB / SMT-stencil order'. It uses specific verbs and resources, and distinguishes itself from siblings by noting it is the 'Official PCB API' and that it provides 'a quote, no order is placed', differentiating it from order-placement tools.
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: it is for quoting PCB/SMT-stencil orders, not placing them. It mentions the required credential and the input structure. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It prominently warns that this creates a real, paid order, implying financial impact and irreversibility. It also discloses the environment-flag requirement and API credentials, which are critical for an agent to avoid unintended financial transactions. Missing details like response format or error behaviors, but the core safety context is effectively communicated.
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 and well-structured: a clear purpose statement, a critical prerequisite warning, and a practical note on parameter construction. Every sentence adds unique value, with no redundancy or fluff. It is front-loaded, placing the most important safety message ('REAL, PAID') at the beginning.
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 complex tool that places a financial order, the description covers the essential context: what it does, prerequisites (env flag, credentials), and the typical input source. It lacks an explicit mention of the return value or post-order behavior, but the presence of sibling tools like jlcpcb_pcb_get_order_detail implies a follow-up workflow. This is adequate for an agent to understand the tool's role and act responsibly.
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 already describes the params object with a list of keys, so baseline is 3. The description adds meaningful context by stating that params are 'typically built from a prior jlcpcb_pcb_calculate_price quote', which informs the agent how to construct or obtain the necessary data. This goes beyond the schema's static list and helps the agent understand the relationship between tools.
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 the tool's purpose with a specific verb and resource: 'CREATE A REAL, PAID PCB / SMT-stencil order.' It distinguishes itself from sibling tools (e.g., jlcpcb_tdp_create_order) by the 'Official PCB API' prefix and explicit mention of PCB/SMT-stencil ordering, making the tool's function unambiguous.
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 usage context: it should be used after a prior jlcpcb_pcb_calculate_price quote, and it is disabled unless JLCPCB_ENABLE_ORDERS=true. It does not explicitly name alternatives or state when not to use it, but the workflow hint and environment flag give strong practical guidance for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 requires API credentials, reads a local file, and returns a fileKey. It also specifies the input is a zip archive of Gerber files. While it doesn't detail error handling, file size limits, or post-upload behavior, it covers the essential behavioral traits for this type of tool, placing it above the minimal 3.
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 with no redundant information. It front-loads the core action, then explains the return value and prerequisites. Every sentence earns its place, and the structure is clean and easy to scan.
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 file-upload tool with two parameters, the description is largely complete: it explains the upload purpose, the return value, and the required credentials. It also ties the tool into the broader PCB ordering workflow. The absence of an output schema is compensated by the mention of the fileKey return value. Minor omissions like file size limits or failure modes prevent a 5, but the tool is sufficiently contextualized.
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 input schema already provides complete descriptions for both parameters (file_path and file_name), achieving 100% coverage. The description adds extra semantic meaning by specifying the file must be a Gerber archive (zip), which clarifies the expected format for file_path. This goes beyond the schema's generic 'file to upload' wording, justifying a 4.
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 the tool's function: 'upload a Gerber archive (zip) for quoting/ordering.' It uses a specific verb ('upload') and resource ('Gerber archive'), and it differentiates from sibling tools like jlcpcb_pcb_calculate_price and jlcpcb_tdp_upload_model by focusing on the upload step. The phrase 'Official PCB API' adds authority and context.
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 usage context by stating it returns a fileKey to pass to downstream tools (jlcpcb_pcb_calculate_price / jlcpcb_pcb_create_order). This implies it should be used first in the PCB ordering workflow. However, it does not explicitly mention alternatives (e.g., jlcpcb_tdp_upload_model for 3D models) or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It warns 'CREATE A REAL, PAID... order', signaling financial impact, and mentions the disabled gate and credential requirement. It doesn't detail failure modes or idempotency, but the key behavioral traits are disclosed.
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?
Three sentences, each purposeful: purpose, enabling condition, and input guidance. Front-loaded with the action verb. No filler or repetition.
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 single-parameter create-order tool with no output schema, this covers purpose, prerequisites, and param source. It could mention the response shape or error behavior, but the essentials are present. The description is adequate for an agent to invoke correctly.
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% (the only parameter `params` is described), but the description adds workflow meaning: the params 'typically from a prior jlcpcb_tdp_calculate_price quote'. It also lists example keys, reinforcing the schema's nested structure. This goes beyond the schema's generic object description.
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 opens with 'CREATE A REAL, PAID 3D-printing order', which uses a specific verb ('create') and resource ('3D-printing order') while emphasizing the real, paid nature. This clearly distinguishes it from siblings like jlcpcb_tdp_calculate_price (pricing) and jlcpcb_tdp_order_list (listing).
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?
It states to pass a `params` object 'typically from a prior jlcpcb_tdp_calculate_price quote', establishing a clear workflow context. It also notes the tool is 'Disabled unless JLCPCB_ENABLE_ORDERS=true', giving a precondition. It doesn't explicitly name alternative tools or when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosure. It transparently mentions the ~50MB download and several-minute duration, giving the agent essential cost/side-effect information. It doesn't discuss whether existing data is replaced during the rebuild, but the term 'rebuild' implies a full rewrite, which is a reasonable inference.
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 the main action, then the cost (download size and time), then usage guidance. No redundant information; every clause earns its place.
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 zero-parameter, no-output schema tool, the description adequately covers what it does, the resources involved, and when to use it. There is no missing critical information needed for an agent to decide to invoke it.
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 tool has zero parameters, so the schema already provides complete coverage. The description adds contextual meaning about the operation's scale and purpose, which is sufficient given there are no parameters to explain.
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 the tool downloads and rebuilds the local component catalog from a specific snapshot source, distinguishing it from sibling tools that handle queries or orders. It uses specific verbs ('download and rebuild') and specifies the resource affected.
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?
It explicitly says to use 'occasionally' to pick up new components and clarifies that live stock/pricing is always current regardless, implying this refresh is not needed for those queries. This provides clear guidance on when to use the tool without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jlcpcb-mcp MCP server](https://glama.ai/mcp/servers/Eyalm321/jlcpcb-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Eyalm321/jlcpcb-mcp)

Score Badge

Copy to your README.md:

[![jlcpcb-mcp MCP server](https://glama.ai/mcp/servers/Eyalm321/jlcpcb-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Eyalm321/jlcpcb-mcp)

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/Eyalm321/jlcpcb-mcp'

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