Skip to main content
Glama

partreel

by io.github.mingyo186

submit_part

Upload a part you built so it is SHARED IMMEDIATELY (status 'staging', unverified). It becomes searchable and downloadable right away; hourly CI then runs the full quality gates and opens a PR to promote it to the verified registry. Provide the full text of the .kicad_sym and .kicad_mod files plus metadata. Cite real datasheet dimensions in dimensions_source — copies of the official KiCad (CC-BY-SA) library are auto-rejected at promotion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYespart id: lowercase letters/digits/underscore, 3-64 chars, e.g. 'ti_sn74lvc1g08_sot23'
nameYeshuman-readable name / MPN
symbolYesfull .kicad_sym file text
licenseYesCC-BY-4.0 for original work; MIT/Apache-2.0/CERN-OHL-P/CC-BY for imports
categoryYesone of: connector, discrete, ic, passive, switch, module, etc
datasheetNodatasheet URL (optional)
footprintYesfull .kicad_mod file text
descriptionYes
dimensions_sourceYesdatasheet URL + page/figure the dimensions came from (min 20 chars)

TDQS

A4.6/5.0
Behavior5/5

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

Even without annotations, the description discloses the staging status, immediate searchability, hourly CI quality gates, and the auto-rejection of official library copies. This gives the agent a clear model of what happens on submission.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, front-loaded with the key outcome (SHARED IMMEDIATELY), then the promotion workflow and parameter guidance. 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 9 parameters and no output schema, the description covers the input requirements and post-submission process adequately. It could mention the immediate response/return value, but the lifecycle is well explained.

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 to dimensions_source by requiring real datasheet citations and warns that official library copies are rejected, clarifying the expected quality of that parameter. It also explicitly mentions providing full file text for symbol and footprint, reinforcing those schema fields.

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 that the tool uploads a part for immediate sharing (status 'staging'), differentiating it from read-only siblings like get_part/search_parts and from request_part which asks for a part. The verb 'Upload' and specific resource 'part' are explicit.

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 use when you have built a part and want to share it, and even warns that copies of the official KiCad library will be auto-rejected, serving as a condition for acceptable submissions. It does not name alternative tools explicitly, but the sibling set and workflow make the context clear.

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

All partreel toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Resources