Search the PartReel registry of verified KiCad components (footprint + symbol + 3D STEP/GLB, no login, CC-BY-4.0). Returns matching parts with ids. Use get_part for download URLs. Example queries: 'usb-c', 'jst ph 4pin', 'esp32', 'microsd', 'screw terminal'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text (name, family, keywords, pin count) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses no login requirement, licensing, and that results include ids but not download URLs. It adds context about verified KiCad components and their composition, but lacks details on pagination or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place. The description is front-loaded with the core action and resource, followed by key constraints and a clear pointer to get_part, then practical examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description sufficiently explains what is returned (matching parts with ids) and how to proceed (use get_part). Example queries cover diverse use cases. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single query parameter. The description adds value by providing concrete example queries ('usb-c', 'jst ph 4pin') and indicating that search covers names, families, keywords, and pin counts, reinforcing the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the PartReel registry of verified KiCad components' with a specific verb and resource. It distinguishes from siblings by noting that get_part provides download URLs, implying search_parts is for discovery. Examples clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to get_part for download URLs, identifying a key alternative. It implies use when searching for components and provides example queries, but does not explicitly contrast with list_parts or state when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct action in the part lifecycle: discovery (list, search, get), acquisition (request, submit), guidance (how_to_contribute), and feedback (report_feedback). No two tools overlap in purpose, and descriptions clearly indicates when to use each.
Most tools follow a consistent verb_noun pattern (get_part, list_parts, search_parts, request_part, submit_part, report_feedback). The exception is how_to_contribute, which breaks the pattern but remains readable and clear.
Seven tools is well-scoped for a component registry, covering discovery, contribution, and feedback without redundancy or bloat. Each tool earns its place in the workflow.
The toolset fully covers the core domain: searching and retrieving parts, handling missing parts via parametric generation or user submission, and recording real-world feedback. The lack of update/delete tools is appropriate for a CI-promoted registry, and feedback is tied to parts via the public GitHub system.