szlcsc-mcp

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Search, parametric search, get part, compare, find alternatives, download single/batch, Altium tools, library management tools, and utilities all serve different functions with no overlap.
Naming Consistency4/5
All tools share the 'szlcsc_' prefix. However, some tools use verb_noun pattern (szlcsc_download_parts, szlcsc_search) while others use noun_noun or noun_verb (szlcsc_library_status, szlcsc_altium_import). This inconsistency across the set, though grouped by subdomain, prevents a perfect score.
Tool Count4/5
25 tools is high but appropriate given the comprehensive scope: search, part data, Altium conversion, library management, and utilities. Each tool serves a distinct operation, and the count reflects the complexity of the domain.
Completeness3/5
The tool set covers search, retrieval, comparison, Altium import, and library management (add, sync, search, audit, repair). However, there is no tool to delete a part from the library, which is a notable gap for lifecycle management.
Average 3.3/5 across 24 of 25 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 88 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
The description does not disclose any behavioral traits beyond the name, such as the fact that it may overwrite files (force parameter) or that it downloads from a specific source. There are no annotations to provide safety hints, so the description carries the full burden but fails to mention important behaviors like overwriting behavior or network usage.
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 extremely concise, being a single sentence. It is well-structured and front-loaded with the action. However, it might be too brief, as it omits crucial details, but for the information it conveys, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch operation, multiple parameters, no annotations, no output schema details except its existence), the description is insufficient. It does not explain the return format, error handling, or how it relates to other download tools, leaving major gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the purpose of each parameter beyond the schema. 'identifiers' could be ambiguous (are they part numbers or IDs?), 'output_root' implies a directory but no format, and 'force' is not clarified beyond its default. The description should compensate for the lack of schema coverage but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: batch download and organize complete documentation directories for multiple components. It distinguishes from sibling tools like szlcsc_download_part (singular) and szlcsc_sync_datasheets (syncing), but it lacks explicit mention of output behavior, which could clarify its role further.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain whether it can be used for single components or if szlcsc_download_part should be used for single units, nor does it mention any prerequisites like prior searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It mentions calling a local tool and converting data, but omits critical details: whether it downloads data from EasyEDA, overwrites files, requires network, has destructive potential, or how timeouts affect behavior. With 13 parameters and no schema descriptions, important behavioral context (e.g., side effects, permission needs) is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single Chinese sentence, which is concise but not structured. It is not front-loaded with a summary; a single imperative statement without breaks or emphasis on key aspects. While short, it sacrifices clarity and scannability. It is functional but could be more effective with separation of purpose, usage, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the existence of an output schema (not shown), the tool has high complexity (13 parameters, lengthy timeouts, local dependency) and a broad context of 25 sibling tools. The description only covers basic conversion purpose. It does not explain return values, error conditions, caching behavior, or differentiate from closely related tools (e.g., batch import, status check). The agent is left without enough information to safely and effectively invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% - none of the 13 parameters have descriptions in the input schema. The tool description itself provides zero additional meaning about parameters like 'identifier', 'preview', 'timeout', 'output_root', etc. The description fails to compensate for the absence of schema descriptions, leaving the agent with only parameter names and types (e.g., 'identifier' as a string, 'symbol_only' as a boolean) which are insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts EasyEDA data (for a specified C number/MPN) into Altium SchLib/PcbLib/3D files. It uses a specific verb ('convert') and resource ('EasyEDA data to Altium libraries'), and the purpose is distinct from sibling tools like szlcsc_altium_import_batch (batch import) or szlcsc_altium_smoke_test (testing). The Chinese wording is unambiguous for users familiar with the tool.
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?
The description has no explicit guidance on when to use this tool versus alternatives (e.g., szlcsc_altium_import_batch for multiple components, szlcsc_download_part for raw data). It implies a local dependency ('altium-cruncher') but does not state prerequisites, typical use cases, or exclusions. The agent receives no direct help in choosing this tool over siblings.
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 behavioral disclosure burden. It explains that missing price/inventory remain 'unknown' rather than '0', which is useful. However, it does not disclose read-only status, pagination, or sorting behavior inherent to the sort parameter. Adequate but incomplete.
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?
Two short sentences, no extraneous content, front-loaded with the core action. However, the first sentence is in Chinese which may reduce clarity for non-Chinese agents; still, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 9 parameters and a complex search tool, the description omits all filtering capabilities (sort, brand, package, stock, price, category). The existence of an output schema does not excuse the lack of guidance on parameter usage. Minimal coverage for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 9 parameters, yet the description offers no explanation for any parameter (query, sort, brand, package, etc.). The agent must infer meaning solely from parameter names, which is insufficient for correct invocation. Description fails to compensate for the lack of schema descriptions.
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?
Description clearly states 'search LCSC components, supplement inventory and pricing' which identifies the verb (search) and resource (components). However, it does not differentiate from siblings like szlcsc_parametric_search or szlcsc_get_part, missing explicit distinctions.
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?
Description provides no guidance on when to use this tool versus alternatives such as szlcsc_parametric_search or szlcsc_get_part. No when-to-use or when-not-to-use context is given; only a behavioral note on missing data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 'incrementally maintain' and 'sync', which implies non-destructive updates, but it does not explain whether it overwrites existing files, requires authentication, handles errors, or has rate limits. Critical behavioral information is missing given the absence of annotations.
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 a single short sentence, which is concise. However, it lacks structure (e.g., no front-loading of key details). It packs the core purpose and a usage hint in one line, so every word earns its place. It could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, low schema coverage, and the presence of an output schema, the description is incomplete. It does not explain the return value (the output schema exists but is unmentioned), prerequisites, or how the batch sync behaves. An agent would need to infer too much to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (identifiers, force, output_dir) with 0% description coverage. The description does not explain any parameter—neither the required 'identifiers' nor the optional 'force' and 'output_dir'. Without schema descriptions, the agent must guess the meaning of these parameters.
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 purpose: batch syncing datasheets to a directory and incrementally maintaining a manifest.json. This is a specific verb-resource pair that distinguishes it from siblings like szlcsc_download_part (single download) or szlcsc_search (search). However, it does not explicitly differentiate from szlcsc_download_parts, which could also be used for batch downloads.
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 mentions it is 'suitable for BOM/MPN list', giving context for when to use it (for lists of part numbers). However, it provides no guidance on when not to use it or what alternatives exist (e.g., using szlcsc_download_part for single parts). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'if provided by the component' for OBJ/STEP, but lacks details on mutation (downloads are read-only? destructive?), authentication, rate limits, or error handling. The behavioral profile is under-specified for a download 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 a single sentence that is front-loaded with the action. Every word is necessary; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, 1 required, and an output schema exists. The description covers none of the parameters or output structure. Despite the output schema existing, the description is too sparse to guide the agent on how to configure the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the six parameters (force, identifier, include_obj, output_root, include_step, include_svgs). The agent must infer meaning from parameter names alone, which is insufficient for correct invocation.
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 EasyEDA original EDA assets (CAD JSON, symbol/package SVG, OBJ/STEP), with a specific verb and resource. It distinguishes from sibling tools like szlcsc_download_part which likely download part data, not EDA assets.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., szlcsc_download_part, szlcsc_download_parts). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for communicating behavioral traits. It only mentions the output is not drop-in compatible. It does not disclose whether this tool requires authentication, what data sources it accesses, or any side effects (e.g., rate limits, caching behavior). The description is too sparse for a tool with no annotations.
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 very brief (two sentences) and immediately states the core function. However, it could have included parameter details or usage hints without losing conciseness. Still, it avoids fluff and gets to the point quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which could partially explain return values), the description fails to cover preconditions, required permissions, or edge cases. The tool has 3 parameters with 0% schema coverage, and the description does not compensate. The lack of context makes it difficult for the agent to decide when to invoke this tool over its many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should clarify the meaning of each parameter. The description does not explain what 'identifier' expects (e.g., part number, category), how 'max_results' affects sorting, or what 'in_stock_only' truly filters. The description adds almost no meaning beyond the raw schema, leaving the agent guessing.
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 retrieves alternative parts (替代料) from SZLCSC and ranks them. However, it does not explicitly distinguish how this tool differs from sibling tools like 'szlcsc_compare_parts' or 'szlcsc_search', both of which could also involve finding similar parts. The clarification that results are not 'drop-in' compatible is useful but not enough for 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some guidance by noting the output is not a drop-in compatibility guarantee, which implies the agent should verify before using. However, it does not specify when to prefer this tool over sibling alternatives like 'szlcsc_search' for general search or 'szlcsc_compare_parts' for direct comparison. No when-not-to-use or alternative tool 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?
The description explicitly marks the tool as read-only ('只读'), which partly compensates for the lack of readOnlyHint annotation. It discloses the audit focus areas. However, it does not explain behavioral traits such as whether the tool reaches out to the network, what happens if hashes mismatch, or what the output schema's fields mean. With no annotations provided, the description carries the full burden but only partially fulfills it.
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-line sentence that packs purpose, read-only nature, and audit scope. Every part earns its place. It is appropriately front-loaded with the key behavioral trait ('只读') and the action ('审计'). No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% parameter coverage, no annotations, and a non-trivial output schema that is entirely undocumented, the description is far from complete. It does not explain what the tool returns, how to interpret results, or how to correctly set parameters. The complexity is moderate, but the description leaves too many gaps for an agent to use this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining all three parameters. It only vaguely implies the tool checks integrity and mentions 'identifiers' in the context of library audit, but does not explain what 'identifiers' are (e.g., filenames, part numbers), how 'library_root' is used, or what 'verify_hashes' actually does. This is insufficient for correct invocation.
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 a read-only audit action on a library, and specifies three audit areas: 'classified/flat', 'CAD owner', and 'index and file integrity'. This differentiates it from the many sibling tools that write, sync, search, or import. However, the term '长期器件库' (long-term component library) is domain-specific and may not be universally understood by an AI agent.
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?
No guidance is provided on when to use this tool versus the many sibling tools such as szlcsc_library_status, szlcsc_library_sync, szlcsc_library_search, or szlcsc_library_repair. The agent is left to infer the purpose from the name and description alone. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It mentions 'real machine' (实机) implying it runs on a live Altium installation, which may have side effects, but it does not clarify whether the tool is destructive, read-only, or what permissions are needed. It also omits details on rate limits, error handling, or what happens to the system during the test.
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 a single sentence that packs key information about the tool's purpose, constraints, and options. It is concise and efficient, though it could be slightly better structured by front-loading the core action. Overall, it is not overly verbose and every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 1 required, 0% schema description coverage, and an output schema present), the description is insufficient. It provides a high-level overview but lacks details on parameter behavior, workflow steps, error conditions, and the exact meaning of 'smoke test' in this context. The agent would need additional information to use the tool 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?
Schema description coverage is 0%, so the description must compensate. It explains some parameters: 'up to 5 C numbers' hints at identifiers, 'optional 3D' maps to require_3d, and 'test merge' maps to test_merge. However, parameters like preview, timeout, and output_root are not addressed. The description adds value for some parameters but leaves others unexplained, resulting in only partial compensation.
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 it is a smoke test for Altium involving SchLib, PcbLib, report, optional 3D, and merge testing. It specifies a limit of 5 identifiers. However, it does not differentiate from sibling tools like szlcsc_altium_status, szlcsc_altium_review, or szlcsc_altium_import, which could confuse an agent about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for smoke testing with up to 5 identifiers and optional 3D/merge testing. It provides some context (max 5 C numbers, optional 3D, merge test) but no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent must infer the intended use case.
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 of behavioral disclosure. The description implies a write operation (downloading files to a local directory) but does not explicitly state whether it creates or modifies files, what permissions are required, or whether network access is needed. The output schema exists, but the description does not reference it. A score of 3 reflects minimal behavioral clarity with notable omissions.
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 efficiently communicates the core action and outputs. It is short, front-loaded, and contains no extraneous information. Every part serves a purpose, making it concise 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?
With an output schema present, the description does not need to detail return values. However, the tool has 3 parameters (1 required, schema coverage 0%) and no annotations, increasing complexity. The description is too minimal to be complete; it lacks parameter explanations, usage prerequisites, and behavioral notes (e.g., whether files are overwritten). A score of 3 reflects adequacy for a simple tool but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for any of the 3 parameters. The tool description does not explain any parameter semantics. 'identifier' is mentioned in the title but not defined; 'force' and 'output_root' are completely undocumented. This forces the agent to guess their meanings, which is poor usability.
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 downloads and organizes files for a single part (part.json, README.md, datasheet.pdf, product images). The verb '下载并整理' (download and organize) and the resource '器件' (part) are specific. However, the description lacks differentiation from sibling tools like szlcsc_get_part, which also retrieves a single part; the distinction in output files is implicit.
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?
The description does not provide any explicit guidance on when to use this tool versus its siblings. For example, it does not mention scenarios where downloading files is necessary compared to simply fetching part data with szlcsc_get_part. No alternatives, prerequisites, or exclusions are indicated, leaving the agent to infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While it mentions deduplication and optional Altium library generation, it fails to explain side effects (e.g., overwriting existing entries, file creation, required permissions) or the behavior of key flags like rebuild_cad or import_missing. The safety profile remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose and a few features, which is concise but not well-structured. It could be broken into clear statements for readability. There is no wasted text, but it does not earn a higher score due to missing logical separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the high parameter count (9) and absence of schema descriptions, the description should provide a usage overview or example. It does not explain the process of registering devices, the format of identifiers, or the effect of boolean parameters. The presence of an output schema does not compensate for the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly references identifiers (C number) and dedupe_cad (MPN+package). None of the other 7 parameters (e.g., preview, timeout, library_root, altium_output_root) are explained. This is insufficient given the parameter count.
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 registers devices into a local library, retains procurement metadata via C number, uses MPN+package for CAD deduplication, and can generate Altium libraries. This specific verb+resource combination differentiates it from sibling tools like szlcsc_library_search or szlcsc_library_sync.
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 for adding parts to a local library but does not explicitly state when not to use it or mention alternatives among the many sibling tools. It provides context about deduplication and Altium generation, but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals only that shared CAD is merged once and merging is by library classification. It does not disclose whether the operation is destructive, requires permissions, handles conflicts (despite a 'conflicts' parameter), or any side effects. The description provides minimal behavioral context beyond the basic action.
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. The first sentence defines the primary action clearly, and the second adds an important nuance about shared CAD. Every word serves a purpose; there is no fluff or repetition. It is well front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters and an output schema, the description is too brief. It does not explain when to provide a category, what conflict strategies exist, or where output is placed. The nuance about shared CAD is helpful but insufficient for an agent to use the tool correctly without guessing parameter behavior. The output schema exists but description doesn't reference it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description does not explain any of the 5 parameters (timeout, category, conflicts, output_dir, library_root). An agent gets no hints about how to set these options. The baseline for 0% coverage is that the description must compensate, but it fails entirely, leaving the agent to infer parameter meanings solely from names and defaults.
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 merges registered independent SchLib/PcbLib into a multi-device Altium library by classification. The verb 'merge' and resource 'libraries' are specific, and the nuance about shared CAD merging only once adds clarity. This distinguishes it from siblings like szlcsc_library_add (which adds individual parts) or szlcsc_library_sync (which synchronizes).
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 use when you have registered independent libraries and want to combine them, but it does not explicitly state when to avoid this tool or mention alternatives. There is no guidance on prerequisites, conflict scenarios, or comparisons with sibling library tools. The rule about shared CAD merging only once is a usage note but not comprehensive.
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 discloses that the tool performs a check and requires no parameters. Since there are no annotations provided, the description carries the burden. It correctly indicates that it is non-destructive (check only) but does not describe what happens if the check fails (e.g., error vs. return false), nor any side effects or output format. Basic transparency is present but lacks behavioral detail.
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 conveys the core functionality efficiently with no extraneous words. It appropriately front-loads the verb '检查' (check) and clearly specifies both sub-checks. Every character earns its place.
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 the tool has 0 parameters, a simple check task, and no input schema constraints, the description is mostly complete. However, it does not explain the return value behavior (output schema exists but is not described), nor does it mention what the agent should infer from the result (e.g., can we proceed with import?). With annotations absent, this gap slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters and schema coverage is 100%, so the description adds value by confirming the tool takes no arguments. The description does not need to explain parameter meanings beyond stating it is parameter-less, which it does implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool checks whether the optional altium-cruncher is installed and whether the easyeda-import subcommand is available. This is a clear verb-resource (check status) but lacks specificity on what exactly being checked means (e.g., file presence, version, etc.). It does not distinguish itself from the sibling tools like szlcsc_altium_setup or szlcsc_altium_smoke_test.
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?
The description provides no guidance on when to use this tool versus other altium-related tools (setup, smoke_test, review, import, etc.). It does not mention prerequisites, sequencing, or scenarios where this check is necessary (e.g., before calling import). The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. While it mentions the cache is SQLite-based, it does not reveal whether clearing or pruning is destructive (e.g., irreversible data loss), the scope of the cache (global or user-specific), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, but the semicolon separation between actions makes it slightly harder to parse quickly. It could be clearer with bullet points or separate sentences.
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 an output schema exists, the description does not need to document return values. However, the tool has two parameters with distinct actions and no guidance on combining them; also, no examples or default behavior (e.g., what happens if no args are passed) is provided.
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 description adds meaning beyond the input schema by explaining the role of each parameter ('clear' empties cache, 'prune_days' cleans old entries). Since schema coverage is 0%, this is essential and well-done.
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 is for viewing an SQLite request cache and specifies two distinct actions ('clear' and 'prune_days'), making the purpose clear. However, it doesn't explicitly differentiate from sibling tools, many of which also interact with cached or library data.
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 when to use the parameters (e.g., 'clear=true' for clearing, 'prune_days=N' for pruning old cache), but provides no guidance on when not to use this tool versus alternatives like 'szlcsc_library_repair' or when to prefer cache operations.
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 burden and discloses key behaviors: it refreshes metadata, does *not* rebuild CAD, and flags MPN/package changes for review. It lacks details on authentication, rate limits, or error handling, but the core behavioral traits are well covered.
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 two sentences that front-load the main action and follow with critical caveats. It is efficient with no word waste, though a bulleted or more structured format could improve scannability for the agent.
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?
The description covers the core operation and important behavioral nuances (no CAD rebuild, flagging). However, it fails to explain parameters or output schema (though output schema exists, its content is unknown), and omits usage boundaries relative to similar siblings, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—no parameter descriptions exist. The tool description does not explain any of the three parameters (dedupe_cad, identifiers, library_root). While parameter names offer some hint, the description adds no semantic value beyond the bare names.
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 refreshes library metadata (price, stock, datasheets) and explicitly notes it does not rebuild CAD. However, it does not distinguish this sync operation from sibling tools like szlcsc_library_search or szlcsc_library_add, leaving the agent to infer the difference.
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?
No guidance is provided on when to use this tool versus its many siblings (e.g., szlcsc_library_audit, szlcsc_library_merge). The description implies it is for refreshing existing library entries, but the agent receives no explicit when-not or alternative suggestions.
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 bears full responsibility. The word '查看' indicates a read-only operation, which is helpful, and the list of viewed aspects adds clarity. However, it does not disclose potential side effects, performance characteristics, or required setup (e.g., whether the library must be initialized first).
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 efficiently conveys the tool's purpose without superfluous words. It is well-structured and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has four parameters, no description coverage, and an output schema that is not referenced, the description is incomplete. It fails to provide parameter guidance or mention the return structure, leaving the agent with significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any of the four parameters (query, category, library_root, only_cad_owners). The agent must infer meaning solely from parameter names and defaults, which is insufficient for a tool with this many siblings and optional filters.
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 is for viewing local SZLCSC/Altium device library status, including index, classification, duplicate MPN/CAD groups, and registered devices. The verb '查看' (view) and resource specification distinguish it from sibling tools like szlcsc_library_search (search) and szlcsc_library_sync (sync).
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 for obtaining an overview of the library status, but it does not explicitly state when to use it over alternatives like szlcsc_library_audit or szlcsc_library_repair. No guidance on exclusions or prerequisites is provided.
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?
由于没有提供注解，描述承担了全部行为透明责任。描述明确指出了批量性、数量上限为50、逐器件执行和分别报告失败等关键行为，这些信息对代理选择工具有价值，但未说明是否具有破坏性、是否需要授权或速率限制等额外行为。
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?
描述由一句话构成，简洁明了，表达了核心功能和限制，没有冗余信息。但中文与英文混用（Altium库）可能造成理解障碍，且缺少对参数的解释，可能影响完整性。
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?
在无注解且有输出模式、7个参数且描述覆盖率为0%的情况下，描述基本说明了工具用途和主要限制，但未涵盖参数语义、输出结构（尽管有输出模式）或使用场景的完整上下文，对于复杂工具而言不够充分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式中7个参数的描述覆盖率为0%，而描述未提及任何参数的含义或用法，完全依赖于模式本身的名称和默认值。对于7个参数的工具，描述无法提供超出模式名称的价值，仅identifiers参数可以通过描述中的'器件'推测其内容。
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?
描述以中文明确说明该工具的功能是批量调用Altium库生成工具，并限定了操作范围（最多50个器件），但未完全与兄弟工具区分，例如szlcsc_altium_import功能类似，仅命名不同。
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?
描述中说明了数量限制（最多50个器件）和执行方式（逐个执行并分别报告失败），暗示适用于批量场景，但未明确何时应使用本工具而非单个导入工具（如szlcsc_altium_import），也未提及前置条件或失败处理建议。
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 convey behavioral traits. The description implies a filtering/querying behavior but does not disclose whether it modifies data, requires authentication, or has rate limits. It does not describe the output format or pagination behavior. The tool likely performs a read-only search, but this is not explicitly stated.
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 very short (two sentences) and front-loaded with the key purpose. The example is directly relevant to the most complex parameter. However, the description could be slightly more structured by separating the purpose from the example, and it uses Chinese characters which may not be universally accessible.
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 the complexity (8 parameters, required nested object, output schema exists), the description is incomplete. The output schema is provided but not referenced in the description. The description covers only the constraints parameter without explaining others. The tool is moderately complex but the description does not fully prepare the agent for correct 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?
Schema description coverage is 0% (no parameter descriptions in schema), so the description must compensate. The description only explains the 'constraints' parameter with an example, which is helpful. However, there are 7 other parameters (brand, query, package, in_stock, max_price, fetch_pool, max_results) that are not described at all. The example provides some meaning for constraints, but the overall parameter semantics are poorly documented.
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 '参数化选型' (parametric selection/search) which is a specific verb+resource combination. It distinguishes from siblings like szlcsc_search (generic search) and szlcsc_find_alternatives (alternative finding). However, it could be more explicit about the domain (e.g., electronic components).
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 a usage example of the constraints parameter, showing how to format filtering criteria. However, it does not explain when to use this tool vs. szlcsc_search or szlcsc_find_alternatives, nor does it specify prerequisites like required fields or common use cases. The example is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention if the tool is read-only or destructive, any authentication requirements, rate limits, or what happens if the identifier is invalid. For a tool that fetches data, at minimum a read hint should be noted.
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 a single sentence with no wasted words. It front-loads the key mechanism (identification type) and lists the output categories efficiently. Slightly verbose due to listing many return types, but appropriate for a data retrieval 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 has one parameter and a presumably rich output schema (not shown, but stated as present), the description clearly indicates what the tool returns. It provides enough context for an agent to select this tool for fetching full part data by identifier, though it could mention that the output schema defines the structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single parameter. It states '按 C 编号或明确 MPN 获取' which explains that identifier can be a C number or MPN, adding meaning beyond the bare schema type 'string'. This is adequate for one parameter.
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 retrieves details, parameters, inventory, price, product page, and Datasheet for a Chinese SZLCSC part using a C number or MPN. It specifies the two identification methods (C number or MPN) and the specific resources returned, distinguishing it from sibling tools like szlcsc_search or szlcsc_parametric_search.
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 use when you have a specific C number or MPN and need comprehensive part data, but lacks explicit guidance on when not to use it or alternatives. With many sibling tools, the description does not address scenarios where other tools (like szlcsc_search or szlcsc_find_alternatives) might be more appropriate.
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 indicates the search is offline and filters on CAD/archived assets, which is useful. However, it does not mention return limits, pagination, or performance characteristics. It does not contradict any annotations since none exist.
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 a single concise sentence covering the main purpose and filter dimensions. It is front-loaded and efficient, though it could be slightly more structured with lists or examples for clarity.
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 the tool has 14 parameters, an output schema, and many siblings, the description provides basic completeness by naming filter dimensions. However, it lacks information on what the output contains, how results are sorted, or how to effectively use the many filters. It is adequate for a search tool but not fully comprehensive.
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 description lists multiple filter dimensions (型号/品牌/封装/分类/库存/CAD与归档资产) that map to the 14 parameters. With 0% schema description coverage, the description partially compensates by stating the filtering capabilities, but it does not explain individual parameter usage or behavior (e.g., library_root default, sort_by options).
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 it is for offline searching of a long-term component library by multiple criteria (model/brand/package/category/inventory/CAD/archive assets). The verb '检索' (search) and resource '长期器件库' are specific, and it distinguishes this tool from its siblings, which are for downloading, parametric search, compare, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching within the offline library with various filters, but it does not explicitly state when to use this tool versus alternatives like szlcsc_search or szlcsc_parametric_search. It provides no guidance on when not to use it or mention of typical parameters to set.
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 fully cover behavioral traits. It describes the main action and the optional lookup side effect, but does not disclose error behavior (e.g., what happens on invalid text), return format beyond schema, or any side effects like network calls during lookup. Adequate but not thorough given zero annotation support.
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 a single sentence with key information front-loaded: the verb '解析' (parse), the resource type, and extracted fields. It efficiently adds the lookup behavior. Slightly more could be added for error cases, but it avoids verbosity.
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 moderate complexity (2 params, no enums, has output schema) and zero schema description coverage, the description covers the core purpose and the main optional behavior. With an output schema present, return values need not be detailed in text. It is sufficient for selecting the tool, though error handling or invalid input guidance is missing.
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 description coverage is 0%, so the description carries full burden for clarifying parameters. It explains 'raw' implicitly as the barcode text, and 'lookup' as an optional flag to fetch part details. This adds meaning beyond the bare schema types, meeting the compensation requirement well.
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 it parses barcode text from LCSC packaging and identifies the fields extracted (pc, pm, qty). It is specific about the resource (barcode text) and the action (parse). However, it does not explicitly distinguish itself from sibling tools, though its purpose is unique enough among them.
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 this tool is for decoding barcode text, which is its primary use. It mentions optional lookup behavior, but provides no guidance on when to use lookup=true versus false, nor contrasts with any sibling tool for fetching part details (e.g., szlcsc_get_part). Usage context is clear only for the core parsing function.
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 of behavioral disclosure. It adds one behavioral trait: 'will not automatically declare direct replaceability.' This is useful context, but the description does not disclose other aspects like safety (read-only vs. destructive), performance, or error conditions. The behavioral transparency is minimal but not misleading.
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 (two clauses) that front-loads the core action ('compare multiple specific parts side by side') and adds a key behavioral note. Every word earns its place; there is no redundancy or filler. It is appropriately brief for a simple 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 simplicity (one parameter, output schema present), the description covers the essential aspects: what it compares and what it returns. The output schema presumably documents the return structure, so the description does not need to repeat that. However, it could be more complete by specifying the expected format of identifiers, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'identifiers' parameter. The description refers to 'multiple specific parts' but does not explain the expected format of identifiers (e.g., part numbers, full IDs, or how many are allowed). The meaning is partially inferred but not explicitly clarified, which is insufficient for a tool with zero schema documentation.
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: comparing multiple specific parts side by side and returning differences in basic fields and same-name parameters. It distinguishes from sibling tools like szlcsc_find_alternatives (which finds replacements) and szlcsc_search (which searches broadly). The verb 'compare' and resource 'parts' are specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (i.e., when you want to compare specific parts) but does not explicitly state when not to use it or mention alternatives. While the purpose is clear, there is no guidance on choosing between this and similar tools like szlcsc_find_alternatives. The usage context is only hinted by the description itself.
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 carry full behavioral disclosure. It describes the tool as a lightweight check that does not read price/stock details, which is helpful for safe usage. However, it does not disclose what exactly 'healthcheck' returns (e.g., success/failure, latency), whether it modifies any state, or what side effects may occur. For a read-only health probe, minimal transparency, but no contradictions.
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: a single sentence with high information density. It front-loads the purpose ('轻量检查') and includes what is excluded ('不读取价格库存详情'). Every word earns its place with zero waste.
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 the tool is a simple health check with one optional parameter and an output schema exists (which presumably defines the return format), the description covers the essential behavioral boundaries. However, it does not explain how the output schema relates to the check results, nor does it address any prerequisites (e.g., must call this before others). For a no-annotation simple tool, this is minimally 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 0%, and the tool has only one parameter (query) with a default of 'STM32'. The description does not explain the meaning or purpose of the query parameter — e.g., whether it's used to test with a specific string or if it's irrelevant. Since the schema provides the name and default, but no description, the tool's doc adds zero semantic value beyond what the schema implicitly offers. Baseline 3 for low coverage is not met; however, the parameter is simple and self-explanatory for a healthcheck, so it is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a lightweight health check for the SZLCSC search interface and local cache, and explicitly notes what it does NOT do — reading price/stock details. This verb+resource+scope distinction is specific and distinguishes it from the many sibling tools that do involve searching, downloading, or library 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 implies usage for verifying availability of search interface and cache, with no exclusions. However, it provides no guidance on when to use this tool versus the similar szlcsc_cache_status (which likely focuses on cache alone) or szlcsc_search (which does actual searching). Without explicit when/why-not/alternatives, the agent may guess suboptimally.
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 reveals core behaviors: safe repair, dry-run by default, scope (flat + CAD consistency), and excluded actions. However, it omits the behavior when dry_run=false (actual repair could be destructive) and does not mention permissions or side effects.
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 single Chinese sentence is dense yet scannable, front-loading the purpose and key constraints. Every part adds value; there is no redundancy or fluff.
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?
For a 5-parameter tool with no schema descriptions, the description covers the main purpose and defaults but lacks details on identifiers and library_root. An output schema exists but is not leveraged in the description. The agent would need to infer parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for dry_run, repair_flat, and reconcile_cad by matching terms in the description, but does not explain identifiers or library_root. Thus it provides partial but incomplete parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool repairs the long-term component library, specifies exactly what it restores (flat image, CAD owner/index consistency) and excludes (download, CAD generation), and mentions default dry-run. This distinguishes it from sibling tools like szlcsc_library_add or szlcsc_library_sync.
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 the tool is for repair when library consistency issues exist, and notes the default safe dry-run behavior. However, it does not explicitly compare to siblings like szlcsc_library_audit or state when not to use it, leaving some ambiguity.
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 full burden for behavioral disclosure. It clearly states the tool is read-only ('不修改文件'), which is critical behavioral information. It also specifies that it reads already generated reports and summarizes specific warning types (pin/pad/3D placement). This provides sufficient behavioral context for an agent to understand its non-destructive nature.
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 conveys the tool's purpose, scope, and read-only nature. Every part earns its place: it states what it does (reads, summarizes), for which reports (Altium EasyEDA import), and key constraints (no file modification). 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?
Given the tool has an output schema (which likely describes the return values), the description doesn't need to explain output format. It explicitly addresses input expectations (already generated reports), behavioral constraint (read-only), and scope (pin/pad/3D warnings). The only gap is the unclear parameter semantics, which is already scored separately. Overall, the description is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no description for either parameter. The tool description does not explicitly explain what 'identifier' or 'output_root' mean. However, 'identifier' likely refers to a project or report identifier, and 'output_root' likely specifies where files are stored. Without any parameter info, the baseline is 3; the description adds no value beyond the schema, but the schema itself lacks descriptions.
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 specific verb '读取' (read), resource '已生成的 Altium EasyEDA 导入报告', and action '汇总 pin/pad/3D placement 告警'. It distinguishes itself from sibling tools like szlcsc_altium_import (which would create/modify) by explicitly stating it does not modify files, making its purpose unique 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?
The description implies this tool is for reviewing generated reports, not for creating or modifying them. It does not explicitly state when to use it over alternatives like szlcsc_altium_status or szlcsc_altium_smoke_test, but the focus on 'altium review' and '不修改文件' (no file modification) provides clear context for usage as a read-only review 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. It explicitly discloses a key behavior: this tool does not execute installation, only returns commands. This is valuable safety context. It doesn't mention other side effects, but the '返回命令' phrasing implies a read-only 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?
Single sentence, front-loaded with the tool's purpose, and every word earns its place. No fluff or repetition.
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 tool has no parameters and an output schema exists, the description sufficiently covers purpose and the key non-execution behavior. It's complete for a simple diagnostic/command-return 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 there is nothing to explain. Baseline of 4 applies since no parameter documentation is needed.
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?
Description tells us the tool returns diagnostics and safe install/upgrade commands, with a specific verb ('返回') and resource ('Altium 转换工具链'). It explicitly distinguishes itself from executing installation, which differentiates it from sibling tools like szlcsc_altium_import or szlcsc_altium_status.
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 statement '本工具本身不会执行安装' clearly tells the agent this tool is for retrieving commands, not performing installs. This implies when you need actual installation, you should look elsewhere, but explicit alternatives aren't named.
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:

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

Score Badge

Copy to your README.md:

[![szlcsc-mcp MCP server](https://glama.ai/mcp/servers/zhr1008/szlcsc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zhr1008/szlcsc-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/zhr1008/szlcsc-mcp'

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