EasyGerber brings AI printed circuit board (PCB) design, layout, and routing to MCP-compatible assistants. Describe a circuit or start from firmware pin assignments, search published electronic components, and build schematics using catalog parts with their footprints and available 3D models. Create and revise boards, generate layouts with automatic component placement and routing, inspect previews, and check saved layouts for blocking design issues. Export manufacturing ZIPs containing Gerber and drill files, a bill of materials, and component placement data, or download an editable EasyGerber (.egb) file.
Start without signing up. Your agent creates a private guest session for one board, including catalog access, edits, layout, checks, previews, and exports. Sign in through OAuth to work with saved account boards, access permitted organization boards, or save the guest design to your account. Guest support depends on your MCP client and installed integration.
Scored across 15 tools
The set has mostly distinct resource/action targets: board CRUD, layout jobs, layout checks, exports, catalog lookup, account/org reads, and feedback. There is minor overlap because get_board includes latest layout job info while get_generation reads job status, and check_board_layout vs export_board share layout-currentness prerequisites, but the descriptions make the boundaries workable.
All tools use a consistent snake_case verb_noun pattern, including check_board_layout, generate_layout, get_generation, search_parts, and submit_feedback. There are no mixed conventions or vague standalone verbs.
15 tools is well within a reasonable range for an end-to-end PCB design server and each tool maps to a distinct operation. The surface is not bloated; board, layout, catalog, account, and feedback operations each earn their place.
Core lifecycle coverage is strong: board create/read/update/delete/list, layout generate/status/stop/check/export, part search/get, account/org lookup, and feedback. Minor gaps exist around export management and guest-board claim/revocation lifecycle, but agents can still complete the main PCB workflows.
Checks a saved PCB layout at expectedRevision for manufacturing or layout review. Its geometry and applied electrical requirements must both be current. A missing or stale layout requires generate_layout and completion first; electrical_requirements_not_applied also requires regeneration before checking or manufacturing export. Reuses a current assessment or computes and saves one, which requires write access and normal compute capacity. If the board changes during the check, read get_board again. Returns hasBlockingIssues and actionable blockingIssues; no numeric score or deductions.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| expectedRevision | Yes | Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false with idempotentHint=true and destructiveHint=false; the description corroborates and enriches this by explaining that the tool reuses a current assessment or computes and saves one, and that this requires write access and normal compute capacity. It also discloses the return shape (hasBlockingIssues, actionable blockingIssues, no numeric score), though "normal compute capacity" stays vague and no latency/rate expectations are given.
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?
Front-loaded with the core action and then the prerequisites, with no filler sentences. It is dense — five clauses of preconditions and recovery steps — but each one carries actionable information rather than restating the schema.
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 two-parameter tool with full schema coverage, annotations, and an output schema, the description covers the remaining gaps: prerequisites, the caching/write-access model, and conflict recovery. An agent has everything needed to call it correctly and interpret failure modes.
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%, so both parameters are already documented in detail, including the revision_conflict behavior. The description only ties the check to expectedRevision ("at expectedRevision") without adding format or constraint detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ("Checks a saved PCB layout") plus the scope of the check (manufacturing or layout review). It also names the sibling it is not — generate_layout handles the missing/stale case — so an agent can route between them without opening schemas.
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?
Explicit when-to-use and when-not-to-use: a missing or stale layout requires generate_layout and completion first, and electrical_requirements_not_applied requires regeneration before checking or export. It also gives a recovery path (read get_board again if the board changes during the check), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a saved schematic from published catalog parts and verified pins. Supply a fresh private boardRef, name, requestId and intent. To make boardRef, generate 32 random bytes locally, encode as unpadded base64url and prepend egbr1_. The server uses the connected account when available; otherwise it establishes private board access automatically. Keep this SAME boardRef for all later reads, edits, status and export calls. Store it in this conversation or supported private execution state before submitting; do not discard it between isolated calls. Identical retries with the same boardRef, requestId and arguments recover the original creation. Do not use a new reference to recover existing work. Return the complete private board link to this user after creation so later turns can continue it; never log private references or put them in source files. Omit boardEdits unless physical customization is requested; server defaults supply settings, footprints, models and manufacturing limits. Account boards are personal unless organizationId is specified. Use returned revision as expectedRevision when starting layout. Use update_board for existing work. Thin intent format: each parts entry is an array of strings [id, dbId, value], with an optional fourth designator. Choose id as the design-local part ID; copy dbId from the catalog result's id; value is the required value/display label. Omit the fourth designator when it matches id. Each connections entry is {net, class, pins}; class is power, signal, or ground. Each pins entry is [partId, padId]: use the design-local part ID and copy padId from the catalog result's pins[].number, both as strings. Optional pinCurrentRequirements uses those same partId and padId identities with requiredCurrentA in amperes and direction into, out, or bidirectional relative to the net. Omit the list to retain existing values; a supplied list replaces it, and [] clears it. If validation rejects the proposal, preserve the schematic and valid catalog parts, correct the returned detailed issues, and keep the same boardRef. Use a new requestId when input changes; reuse the same requestId and arguments for an unchanged retry. Research again only when an issue needs missing part or pin information.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name for the board. | |
| intent | Yes | Complete initial schematic using published catalog IDs and verified pins. Parts and connections use the thin intent format described by this tool. | |
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| requestId | Yes | New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation. | |
| boardEdits | No | Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements and partClearances use design-local partId; keepouts, mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Keepout shape coordinates are board-plane mm; part clearance distances are in the part-local frame. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId. | |
| organizationId | No | Organization ID from list_organizations. Omit for personal account boards; guest sessions cannot use organizations. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, but the description adds real context beyond them: the server uses the connected account or auto-establishes private board access, identical retries with the same boardRef/requestId recover the original creation, and rejected proposals must preserve the schematic while issues are corrected. It never contradicts idempotentHint. It stops short of describing the returned payload's shape, relying on the output schema for that.
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?
Front-loaded with purpose and the critical boardRef constraint before any detail, and nearly every sentence carries actionable instruction. It is a dense unbroken block, though, and boardRef handling is restated in both the description and the schema, so a small amount of redundancy could be trimmed.
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 six-parameter tool with deeply nested objects, the description covers creation, reference lifecycle, idempotent retry, validation-failure recovery, and hand-off to later calls (using the returned revision as expectedRevision). Return values are delegated to the output schema, which is appropriate, so nothing essential 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%, so the baseline is 3, but the description contributes meaning the schema cannot: how to mint boardRef (32 random bytes, unpadded base64url, egbr1_ prefix) and the thin intent tuple semantics ([id, dbId, value], dbId copied from catalog result id, padId from pins[].number). It also explains replace-vs-omit behavior for pinCurrentRequirements, which is workflow knowledge rather than schema documentation.
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?
Opens with a specific verb plus resource: "Creates a saved schematic from published catalog parts and verified pins." It immediately distinguishes itself from the sibling update_board ("Use update_board for existing work"), so an agent can route between creation and modification without inspecting either schema.
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?
Explicit when-to-use (new schematic from catalog parts), when-not (existing work → update_board), and when to omit boardEdits (unless physical customization is requested). It also defines retry policy: reuse the same requestId and arguments for an unchanged retry, new requestId when input changes, and never a new boardRef to recover existing work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently deletes the specified saved account board when the user requests its removal. Requires explicit boards:delete authorization and personal ownership or organization owner/admin access; guest boards are unsupported. Read get_board first and pass its current revision. Deletion cancels active generation jobs and cannot be undone. A revision conflict requires reading the board again. Missing, already deleted or inaccessible boards return the same not_found error; this does not confirm that an earlier request succeeded. No requestId or replay receipt is supported.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| expectedRevision | Yes | Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing that deletion cancels active generation jobs, is irreversible, and that missing/already-deleted/inaccessible boards all collapse to the same not_found error, which does not confirm an earlier request succeeded. It also states no requestId or replay receipt exists, which is exactly the kind of context destructiveHint alone cannot convey. The only reason it is not a 5 is that the interaction between idempotentHint=true and the not_found-on-replay behavior is implied rather than spelled out.
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?
Front-loads the action and condition, then layers authorization, prerequisite read, side effects, and error semantics in a logical order with no filler. It is dense and slightly long, but each clause carries distinct operational information.
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 two-parameter destructive mutation, everything an agent needs is present: authorization, ownership rules, prerequisite read, side effects, reversibility, and conflict/not_found handling. An output schema exists, so the description is not obliged to explain return values.
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%, so the baseline is 3, but the description adds operational meaning: expectedRevision should come from get_board and a mismatch yields revision_conflict requiring a re-read. It does not add anything about boardRef beyond the schema, keeping it from a 5.
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?
States a specific verb and resource ('Permanently deletes the specified saved account board') plus the triggering condition ('when the user requests its removal'). No sibling tool performs deletion, and the description explicitly points to get_board as the prerequisite read, so an agent can place it precisely among the siblings.
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?
Gives explicit preconditions: boards:delete authorization, personal ownership or org owner/admin access, guest boards unsupported, and the requirement to read get_board and pass its current revision. It also handles the failure branch by naming revision_conflict and prescribing a re-read before retrying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a stable private download of a saved board as a manufacturing ZIP or editable .egb project backup. Read get_board for expectedRevision. Use format egb directly for project backups, including empty or incomplete projects and unapplied geometry or electrical changes; no layout generation or check is required. Manufacturing ZIPs require a current saved layout with applied electrical requirements; generate and wait for completion when needed, then read the new revision. Inherited licensing requires changeNote. New exports require current board access. Issued download links have no automatic expiry and retain this exact export after board edits, deletion, guest claim or cleanup. Only explicit download-link revocation or deletion of the exported file ends access. Keep each complete private URL unchanged, including its fragment; anyone with it can download the file.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | manufacturing: ZIP with Gerber, drill, BOM and placement files. egb: editable EasyGerber board file. | |
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| changeNote | No | Description of modifications, required when get_board returns inherited licensing. Added to the exported license notices. | |
| expectedRevision | Yes | Revision from get_board. A mismatch returns revision_conflict; read the board again before exporting. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it as non-read-only, non-idempotent, non-destructive, and closed-world; the description supplies the critical behavior: downloads are private, non-expiring, survive later board edits, deletion, guest claim, or cleanup, and remain accessible to anyone holding the full URL until explicit revocation or file deletion. That is substantial context beyond the annotations and does not contradict them.
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?
Purpose is front-loaded, then requirements, persistence, and security guidance follow in a logical order. The paragraph is dense, but its length is justified by the amount of access, licensing, and retention behavior an agent must know.
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?
With an output schema present, the description does not need to explain return values, and it covers the preconditions, format-specific requirements, licensing, retention, and URL handling needed to call this complex export tool correctly.
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%, so field meanings are already documented. The description still adds workflow meaning for format selection, expectedRevision validation via get_board, and changeNote under inherited licensing, though it adds little for boardRef beyond the schema.
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 first sentence names a specific verb and resource—creates a stable private download of a saved board—and immediately distinguishes the two export formats. This lets an agent tell export_board apart from get_board, generate_layout, and other siblings without opening the schema.
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 states when to use egb (project backups, including empty or incomplete projects and unapplied changes, with no layout generation or check) versus manufacturing (requires a current saved layout with applied electrical requirements, generating first if needed). It also names get_board as the prerequisite for expectedRevision and changeNote for inherited licensing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts one durable layout job for boardRef at expectedRevision and returns generation.id and generation.status without waiting. Use the latest revision from create_board, update_board or get_board. Read status with get_generation using the same boardRef; do not regenerate to inspect progress. Successful completion replaces the saved layout. A requestId supports IDENTICAL retries only; changed arguments need a new requestId. revision_conflict requires get_board; board_busy identifies the existing job to poll. Subject to normal compute capacity and board complexity limits, without AI credits.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| requestId | Yes | New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation. | |
| expectedRevision | Yes | Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, idempotent, non-read-only), the description discloses that completion replaces the saved layout, that requestId only supports IDENTICAL retries, and maps error tokens to recovery actions (revision_conflict → get_board; board_busy → poll the existing job). It also notes capacity/complexity limits and that no AI credits are consumed.
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?
It is front-loaded with the action and return shape, then layers retry, polling, and error-recovery rules — nearly every sentence carries an operational constraint. The error-token clause ("revision_conflict requires get_board; board_busy identifies…") is slightly compressed, but nothing is redundant.
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 destructive, asynchronous job tool with an output schema, it covers what an agent needs: preconditions (fresh revision), concurrency/idempotency (requestId semantics), progress-checking (get_generation), and failure recovery. Return-value detail is correctly omitted since an output schema exists.
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%, so 3 is the baseline, but the description adds cross-parameter meaning: expectedRevision must be the newest revision from a sibling call, and requestId's identical-arguments constraint is stated in prose alongside the error outcomes. It stops short of adding format/syntax detail beyond the schema, so it sits just above baseline.
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?
"Starts one durable layout job for boardRef at expectedRevision and returns generation.id and generation.status without waiting" names a specific verb (starts a job), the resource (layout job for a board revision), and the async contract. It is clearly distinguishable from siblings like get_generation and check_board_layout, which read or inspect rather than start work.
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 routes the agent: take the latest revision from create_board/update_board/get_board, and poll with get_generation "using the same boardRef; do not regenerate to inspect progress." That is a direct when-to-use / when-not-to-use rule with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the current revision, thin schematic, supported settings, physical context, layout freshness and latest layout job from one saved-state snapshot. Use the same boardRef before editing, checking or exporting. A completed older job does not imply a current layout. Use get_generation with boardRef for status, never generate_layout as a status probe. After account connection this read saves private work to the account when permitted; keep the same reference and use the returned revision. includePreview optionally adds a saved-layout image. Account cache misses render and store a private image; guest previews render per request without an image cache. Previewing does not change the board design or revision. Normal compute capacity limits apply.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| includePreview | No | Include an image of the current saved layout; omitted or false skips rendering. Returns preview: null when no current layout is available. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: account-connected reads can save private work, preview images may be cached or rendered per request, previewing does not alter board design or revision, and compute capacity limits apply. However, it does not reconcile the destructiveHint=true annotation with the read/preview framing or explain what destructive effect an agent should anticipate.
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?
The description is front-loaded with the core read operation and remains dense with operational guidance rather than filler. It is somewhat long and repeats the same-reference instruction, but nearly every sentence contributes useful behavioral or routing information.
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?
Given that an output schema exists and annotations already carry the basic safety profile, the description is complete enough for correct invocation: it covers freshness caveats, sibling-tool routing, preview behavior, caching side effects, and capacity limits. No critical invocation context appears 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%, so the baseline is 3, but the description adds useful meaning for includePreview: it adds a saved-layout image, returns preview: null when no current layout exists, and distinguishes account-cache versus guest rendering. It also reinforces boardRef continuity, though most boardRef semantics are already documented in the schema.
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 states a specific verb, 'Reads,' and enumerates the exact resources returned: current revision, thin schematic, supported settings, physical context, layout freshness, and latest layout job from a saved-state snapshot. It also distinguishes this tool from get_generation and generate_layout by naming their proper roles.
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 instructs using the same boardRef before editing, checking, or exporting, and it names the correct alternative for status checks: use get_generation with boardRef, never generate_layout as a status probe. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads stored layout generation status using the same boardRef. Omit generationId to read the active/latest layout job; supply it only to inspect that exact job. Returns generation:null if no layout job exists. While queued or running, wait pollAfterSeconds; stop polling at completed, failed or cancelled. Read get_board for current saved layout and revision after completion. Never call generate_layout to inspect status. Polling does not save private work to an account.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| generationId | No | Layout generation ID returned by generate_layout for this same board. Use the exact job ID when polling or stopping it. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real behavior: pollAfterSeconds wait cadence, the completed/failed/cancelled stop condition, generation:null when no job exists, and the privacy note that polling does not persist private work. That is substantial value beyond the annotations, though the return shape itself is partly carried by the output schema.
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?
Front-loaded with purpose, then parameter rule, then return/edge case, then polling lifecycle, then alternatives — a sensible ordering with almost no filler. Slightly dense, and the trailing privacy sentence is mildly tangential, but it still carries information an agent would not otherwise have.
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 two-parameter polling tool with a full output schema and rich annotations, everything the agent needs is present: empty-state behavior, poll cadence, terminal conditions, the handoff to get_board after completion, and sibling exclusions. No meaningful gap remains.
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%, so baseline is 3, but the description adds meaning the schema does not spell out: omitting generationId yields the active/latest job rather than an error, and it must belong to the same boardRef. That is genuine semantic guidance on top of a fully documented schema.
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?
Opens with a specific verb and resource ('Reads stored layout generation status') and pins the scope to the same boardRef. It explicitly distinguishes itself from two siblings, generate_layout and get_board, so an agent can route correctly without opening sibling schemas.
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?
States the exact selection rule for the optional parameter (omit to read active/latest, supply only to inspect that exact job) and gives a terminal-state polling rule. It also names the correct alternative for a different need ('Read get_board for current saved layout and revision after completion') and an explicit do-not-use ('Never call generate_layout to inspect status').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a published catalog part and verified pins. Skip this call when search_parts already supplied the needed pins and facts. Use the selected catalog result’s id; returned pins[].number is the padId used in board connections. Use search_parts to find alternatives. factQuery and factOffset select or page cached datasheet facts. An optional boardRef applies that board’s strict Part List restriction, when enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Catalog ID returned by search_parts. | |
| boardRef | No | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| factQuery | No | Terms for relevant facts omitted from the supplied bundle. | |
| factOffset | No | Continue at nextFactOffset with the same factQuery. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real operational context: factQuery/factOffset page cached datasheet facts via nextFactOffset, and boardRef conditionally enforces a strict Part List restriction. It does not describe failure modes for an unknown id or what happens when the board restriction blocks the part, which keeps it at a solid 3 rather than higher.
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?
Five tight sentences, front-loaded with the return value, then the skip condition, then id provenance, then paging, then the optional restriction. No filler or restated title.
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?
With an output schema present, return-value detail is not required, and the description still contributes the padId mapping and paging continuation protocol. Remaining gaps are minor: no guidance on error behavior for a stale or invalid id, or on requesting a full fresh bundle instead of a factQuery.
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%, so baseline is 3; the description earns above that by explaining behavior the schema cannot: factOffset continues 'at nextFactOffset with the same factQuery' and boardRef 'applies that board's strict Part List restriction, when enabled.' It also clarifies that the required id comes from search_parts and that pins[].number maps to padId in board connections.
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?
States a specific verb and resource ('Returns a published catalog part and verified pins') and immediately contrasts itself with the sibling search_parts. An agent can distinguish lookup-by-id from discovery without opening either schema.
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?
Gives an explicit when-not ('Skip this call when search_parts already supplied the needed pins and facts'), a named alternative ('Use search_parts to find alternatives'), and the source of the required id ('the selected catalog result's id'). Selection logic is fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the connected account identity. Requires account authorization; unauthenticated calls request OAuth. Public catalog browsing and creating a new board do not require probing account identity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds valuable auth context, including that unauthenticated calls request OAuth, though it does not describe other failure modes or token-scope requirements.
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?
The description is short and front-loaded, stating the purpose first and then the authorization and usage boundary. Every sentence adds useful selection context without repetition.
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 parameterless identity tool with an output schema, the description covers the key operational context: what it returns, the authorization requirement, and when not to call it. Nothing needed for correct invocation 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?
There are zero parameters, so there is no parameter meaning to add beyond the schema. The baseline for a parameterless tool is 4.
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 states a specific verb and resource: returns the connected account identity. It also distinguishes this identity-probing operation from public catalog browsing and board creation, which do not require it.
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 gives when-to-use context by saying account authorization is required and unauthenticated calls trigger OAuth. It also gives when-not-to-use guidance by noting that public catalog browsing and creating a new board do not require probing account identity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists accessible boards with their private boardRef, most recently updated first. A supplied boardRef selects only that board. Account access returns personal boards unless organizationId is specified. Without access, returns guidance, not a claim that an account has no boards. Continue existing work using its original boardRef or owning account. Continue with nextOffset until null, then use get_board for the selected board.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum boards to return; defaults to 20. | |
| offset | No | Zero-based offset; defaults to 0. Continue with returned nextOffset; null means no further page. | |
| boardRef | No | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| organizationId | No | Organization ID from list_organizations. Omit for personal account boards; guest sessions cannot use organizations. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and closed-world traits, so the bar is lower, and the description still adds real behavior: ordering, the boardRef-as-filter effect, and the important quirk that missing access returns guidance rather than implying the account has no boards. Pagination behavior is described but largely duplicates the schema's nextOffset wording.
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?
Core purpose and ordering are front-loaded, and most sentences carry distinct information. A few clauses are vague and loosely phrased ('continue existing work using its original boardRef or owning account') and could be tightened without losing meaning.
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?
With an output schema present, return values need not be explained, and the description still covers pagination, filtering, organization scoping, and the no-access case. The only soft spot is the ambiguous continuation guidance, which an agent may struggle to act on, but overall it is sufficient to invoke the tool correctly.
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%, so baseline is 3, but the description adds meaning the schema does not: boardRef acts as a single-board selector, and organizationId determines personal versus organization scope. That goes beyond the schema's field-level documentation of format and generation rules.
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?
States a specific verb and resource (lists accessible boards), plus the returned key (boardRef) and the sort order (most recently updated first). It also distinguishes itself from get_board by saying get_board is for the selected board, so an agent can separate the two without reading schemas.
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?
Gives concrete routing: use a supplied boardRef to narrow to one board, specify organizationId for org boards versus personal boards otherwise, and use get_board once a board is selected. It lacks an explicit statement of when not to use this tool (e.g., when the boardRef is already known and full detail is needed), but the practical guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the connected account’s organizations and membership roles. Requires account authorization. Use the returned organizationId with list_boards or create_board for organization work; omit organizationId for personal boards.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful constraint not present in structured data: 'Requires account authorization,' which affects whether the call can succeed.
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 tight sentences that front-load what the tool returns, then the authorization prerequisite, then how to use the result. No filler or restatement of the title.
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?
An output schema exists, so return values need not be described, and the description covers purpose, auth precondition, and follow-up usage. It omits pagination or failure behavior, but for a parameterless read that is a minor gap.
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?
The tool takes zero parameters, so there is no schema semantics for the description to compensate for; baseline for a zero-parameter tool is 4. The mention of organizationId is about the output, not an input, so it does not create ambiguity.
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?
States a specific verb and resource ('Returns the connected account's organizations and membership roles'), including the scope of what is returned. It is clearly distinguishable from the sibling list_boards, which operates on a different resource.
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?
Explicitly tells the agent what to do with the result: use organizationId with list_boards or create_board, and omit it for personal boards. This is strong downstream routing, though it does not state when this tool should not be called (e.g., if account is unauthorized) or name a more specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches published catalog components. The first candidate includes verified pins when available; other candidates may omit them. Reuse returned IDs, pins and facts; call get_part only when the selected candidate lacks needed pins or facts. Supplied filters apply together; query ranks matching candidates, while factQuery only selects cached facts for those candidates. An optional boardRef applies that board’s strict Part List restriction, when enabled. Check candidates against the requested component type and specifications. If results are unrelated, make at most two retries for that part using a simpler component name or a relevant category from the input schema. Preserve required specifications and explicit restrictions, including any boardRef Part List restriction, on every retry. If no suitable part is found, report that you could not find a suitable part rather than claiming the catalog lacks it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum catalog candidates to return, from 1 to 20; defaults to 3. | |
| query | No | PCB selection terms: MPN, manufacturer, description or package family. For exact MPNs omit unverified categories unless user-required. Preserve explicit filters and Part Lists; factQuery does not select parts. Required when factQuery is supplied. | |
| package | No | Exact catalog label; use query for package families. | |
| boardRef | No | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| category | No | Catalog category. | |
| factQuery | No | Cached-fact terms only; requires query. Omit for filter-only searches. It never changes which parts match. | |
| frequency | No | Hertz (8e6 = 8 MHz). | |
| inductance | No | Exact henries. | |
| resistance | No | Exact ohms (10000 = 10 kΩ). | |
| capacitance | No | Exact farads (1e-7 = 100 nF). | |
| jlcpcbBasic | No | Basic-only when true; otherwise leave unset. | |
| subcategory | No | Subcategory, e.g. chip_resistor, mlcc, ldo. | |
| mountingType | No | smt: surface mount; tht: through-hole; mixed: both. | |
| voltageRating | No | Rated volts. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive behavior beyond that: the first candidate carries verified pins while later candidates may omit them, query ranks matching candidates while factQuery only selects cached facts, supplied filters are conjunctive, and an optional boardRef imposes a strict Part List restriction. It also discloses retry limits and the recommended failure-reporting behavior.
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?
Front-loaded with the core purpose and the get_part split, then proceeds to filter semantics, retry policy, and failure reporting. It is long for a search tool, but nearly every sentence carries operational instructions; only the 'check candidates against the requested component type' line is somewhat generic advice.
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 14-parameter search tool with a full output schema, the description covers everything an agent needs that structured fields do not: candidate ordering quality, filter composition, retry bounds, restriction preservation across retries, and how to report a null result. Return-value details are correctly left to the output schema.
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%, so per-parameter meaning is already documented and the baseline is 3. The description adds cross-parameter semantics the schema states only in fragments: filters apply together, query drives ranking, factQuery never changes which parts match and is only for cached facts, and boardRef applies the board's Part List restriction only when enabled. It does not restate the numeric unit conventions, which the schema already handles.
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?
States a specific verb and resource ('Searches published catalog components') and immediately distinguishes itself from the sibling get_part by specifying that get_part is only for candidates lacking needed pins or facts. An agent can identify the tool's role without opening the schema.
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?
Gives explicit routing rules: reuse returned IDs/pins/facts, call get_part only when the selected candidate lacks needed data, retry at most twice with a simpler component name or a category from the schema, preserve required specs and boardRef restrictions on every retry, and report failure rather than asserting the catalog lacks the part. These are when-to-use and when-not-to-use rules plus alternatives, not just context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancels a queued or running layout generation belonging to the specified board; use get_generation when only checking progress. A completed, failed or already cancelled job retains its terminal status. Cancellation cannot be undone; starting again requires a new job. It can update the saved board revision, so read get_board before further edits. A later job is unaffected.
| Name | Required | Description | Default |
|---|---|---|---|
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| generationId | Yes | Layout generation ID returned by generate_layout for this same board. Use the exact job ID when polling or stopping it. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real context beyond them: terminal jobs keep their status (clarifying the idempotent no-op case), cancellation is irreversible, a new job ID is needed to restart, the saved board revision may be mutated by the call, and unrelated later jobs are unaffected. It also flags the side effect on board state that the annotations alone would not reveal.
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?
Front-loaded with the core action in the first clause, then alternatives, irreversibility, and side effects in descending priority. Five short clauses are all substantive, though the density of distinct facts in one block makes it slightly harder to scan than a tighter two-sentence version.
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?
An output schema exists and annotations cover the safety profile, so the description only had to carry the behavioural story — which it does, including failure modes (terminal states), irreversibility, and the board-revision side effect. Nothing an agent needs in order to call this correctly appears to be 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% and both parameter descriptions are detailed, so the baseline would be 3. The description adds a cross-parameter constraint not encoded in the schema: the generation must belong to the specified board, meaning the two identifiers are not independently valid. That is a modest but genuine semantic addition.
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?
States a specific verb ('Cancels') and resource ('a queued or running layout generation') with explicit scope ('belonging to the specified board'). It also names the sibling it is not — 'use get_generation when only checking progress' — so an agent can separate it from the read-only polling tool without inspecting schemas.
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?
Gives an explicit alternative and the condition that selects it ('use get_generation when only checking progress'), plus a follow-up prerequisite ('read get_board before further edits'). It also tells the agent how to resume work after cancellation ('starting again requires a new job'), which is the main post-call decision an agent faces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a bug report, feature request or general feedback to EasyGerber only when the user asks or agrees to report it. Send only the approved message; never automatically attach private board content, raw diagnostics, transcripts or exports. No account, board or guest session is required. A connected account attributes the report to that account; otherwise an optional existing guestToken attributes it to that guest. Reuse requestId with the identical category and message on retries. Returns a submission receipt, without promising a response. Account feedback is limited to 10/hour and 50/day; guest and anonymous feedback share those limits by network.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | User-approved feedback, 10–2000 Unicode characters after trimming. Include only what the user agreed to send; do not automatically include private board content, credentials, transcripts or diagnostics. | |
| category | Yes | bug reports a problem; feature_request proposes a change; general shares other EasyGerber feedback. | |
| requestId | Yes | Unique UUID for this report. Reuse it with the identical category and message after an uncertain result; use a new UUID for a different report. | |
| guestToken | No | Optional existing guest-session capability for attribution when no account is connected. Omit for anonymous or account feedback; never start a session solely to submit feedback or print this token. Invalid tokens are rejected. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing rate limits (10/hour, 50/day shared across account, guest and anonymous by network), attribution behavior (account vs. guestToken vs. anonymous), idempotent retry semantics, and the fact that the receipt does not promise a response. Nothing here conflicts with the declared hints.
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?
Front-loaded with the consent constraint and the prohibition on auto-attaching private data before any mechanics. Every sentence carries distinct information (consent, privacy, auth model, retry semantics, return shape, rate limits) with no filler.
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 four-parameter mutation with an output schema and full annotation coverage, the description supplies everything an agent needs: consent gate, privacy boundaries, attribution paths, idempotency rule, rate limits, and return expectations. No material gap remains.
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%, so baseline is 3, but the description adds real meaning: the requestId reuse rule is tied to "identical category and message," and guestToken is framed as an optional attribution capability that should not be minted solely for feedback. It also reinforces the 10–2000 character and user-approval constraint on message.
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?
States a specific verb and resource ("Sends a bug report, feature request or general feedback to EasyGerber") and enumerates the three categories handled. No sibling tool overlaps this function, and an agent can immediately tell this is the outbound feedback channel rather than a board/session operation.
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?
Explicitly gates invocation on user consent ("only when the user asks or agrees to report it") and on scope ("Send only the approved message"), which is the key when-to-use condition. It also gives the when-not in concrete terms: never auto-attach private board content, diagnostics, transcripts or exports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edits a saved board at expectedRevision; supply at least one of name, intent or boardEdits. Read get_board first. Omitted fields are preserved; schematic edits require the complete replacement thin intent, while boardEdits is a physical patch. Schematic changes can discard an old layout; physical changes can make it stale. Use generate_layout if a current layout is needed afterward. A stale expectedRevision requires a fresh get_board. Thin intent format: each parts entry is an array of strings [id, dbId, value], with an optional fourth designator. Choose id as the design-local part ID; copy dbId from the catalog result's id; value is the required value/display label. Omit the fourth designator when it matches id. Each connections entry is {net, class, pins}; class is power, signal, or ground. Each pins entry is [partId, padId]: use the design-local part ID and copy padId from the catalog result's pins[].number, both as strings. Optional pinCurrentRequirements uses those same partId and padId identities with requiredCurrentA in amperes and direction into, out, or bidirectional relative to the net. Omit the list to retain existing values; a supplied list replaces it, and [] clears it. If validation rejects the proposal, preserve the schematic and valid catalog parts, correct the returned detailed issues, and keep the same boardRef. Use a new requestId when input changes; reuse the same requestId and arguments for an unchanged retry. Research again only when an issue needs missing part or pin information.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for the board. | |
| intent | No | Complete replacement schematic, including every part and connection to retain. Omit for name-only or physical-only edits. | |
| boardRef | Yes | Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment. | |
| requestId | Yes | New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation. | |
| boardEdits | No | Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements and partClearances use design-local partId; keepouts, mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Keepout shape coordinates are board-plane mm; part clearance distances are in the part-local frame. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId. | |
| expectedRevision | Yes | Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation. |
| Name | Required | Description |
|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past destructiveHint=true by naming what is actually lost: schematic edits can discard an old layout, physical edits can make it stale. It also states that omitted fields are preserved and that a supplied pinCurrentRequirements list replaces prior entries while [] clears them. It stops short of describing the returned result, but an output schema exists, so that is acceptable.
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?
The operative instruction and the sibling routing are front-loaded in the first three sentences, and there is no filler. It loses a point because the long mid-section re-explaining the thin intent tuple layout, connections shape and pins pairs largely restates schema descriptions, pushing it toward a dense wall of text.
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 six-parameter mutation tool with deep nesting, revision locking and destructive semantics, the description covers ordering against get_board and generate_layout, conflict recovery, validation-failure recovery with the same boardRef, and requestId idempotency. With an output schema present it need not describe return values, so nothing an agent needs 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%, so the baseline is 3; the description earns an upgrade by supplying cross-tool provenance the schema cannot express, e.g. 'copy dbId from the catalog result's id' and 'copy padId from the catalog result's pins[].number'. It also clarifies omit-vs-replace semantics for pinCurrentRequirements and that the fourth parts designator may be omitted when it matches id.
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?
Opens with a specific verb and resource plus the concurrency contract: 'Edits a saved board at expectedRevision; supply at least one of name, intent or boardEdits.' It also distinguishes the two mutation modes (thin intent = complete replacement schematic, boardEdits = physical patch), which an agent cannot infer from the name alone.
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?
Explicit prerequisites ('Read get_board first'), explicit routing to a sibling ('Use generate_layout if a current layout is needed afterward'), explicit conflict recovery ('A stale expectedRevision requires a fresh get_board'), and explicit retry protocol (new requestId when input changes, reuse on unchanged retry). This is the when/when-not/alternative pattern in full.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_board_layout2 fields changedOutput schema / properties / data / properties / validation / properties / blockingIssues / items / properties / refs / properties / keepoutsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / data / properties / validation / properties / blockingIssues / items / properties / refs / properties / zonesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}create_board1 field changedOutput schema / properties / data / properties / validation / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "blockingIssues": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "location": {
- "additionalProperties": false,
- "properties": {
- "x": {
- "type": "number"
- },
- "y": {
- "type": "number"
- }
- },
- "required": [
- "x",
- "y"
- ],
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "refs": {
- "additionalProperties": false,
- "properties": {
- "layers": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "nets": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "parts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "pins": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "traces": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "vias": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "hasBlockingIssues": {
- "type": "boolean"
- }
- },
- "required": [
- "hasBlockingIssues",
- "blockingIssues"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "blockingIssues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "refs": {
+ "additionalProperties": false,
+ "properties": {
+ "keepouts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "layers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "nets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pins": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "traces": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vias": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "zones": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hasBlockingIssues": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "hasBlockingIssues",
+ "blockingIssues"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]get_board1 field changedOutput schema / properties / data / properties / validation / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "blockingIssues": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "location": {
- "additionalProperties": false,
- "properties": {
- "x": {
- "type": "number"
- },
- "y": {
- "type": "number"
- }
- },
- "required": [
- "x",
- "y"
- ],
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "refs": {
- "additionalProperties": false,
- "properties": {
- "layers": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "nets": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "parts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "pins": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "traces": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "vias": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "hasBlockingIssues": {
- "type": "boolean"
- }
- },
- "required": [
- "hasBlockingIssues",
- "blockingIssues"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "blockingIssues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "refs": {
+ "additionalProperties": false,
+ "properties": {
+ "keepouts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "layers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "nets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pins": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "traces": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vias": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "zones": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hasBlockingIssues": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "hasBlockingIssues",
+ "blockingIssues"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]update_board1 field changedOutput schema / properties / data / properties / validation / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "blockingIssues": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "id": {
- "type": "string"
- },
- "location": {
- "additionalProperties": false,
- "properties": {
- "x": {
- "type": "number"
- },
- "y": {
- "type": "number"
- }
- },
- "required": [
- "x",
- "y"
- ],
- "type": "object"
- },
- "message": {
- "type": "string"
- },
- "refs": {
- "additionalProperties": false,
- "properties": {
- "layers": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "nets": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "parts": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "pins": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "traces": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "vias": {
- "items": {
- "type": "string"
- },
- "type": "array"
- }
- },
- "type": "object"
- }
- },
- "required": [
- "id"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "hasBlockingIssues": {
- "type": "boolean"
- }
- },
- "required": [
- "hasBlockingIssues",
- "blockingIssues"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "blockingIssues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "refs": {
+ "additionalProperties": false,
+ "properties": {
+ "keepouts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "layers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "nets": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parts": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pins": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "traces": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vias": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "zones": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "hasBlockingIssues": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "hasBlockingIssues",
+ "blockingIssues"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]check_board_layout6 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "expectedRevision"
-]New value: +[
+ "expectedRevision",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / requiredPrevious value: -[
- "boardRevision",
- "validation"
-]New value: +[
+ "boardRevision",
+ "validation",
+ "boardRef"
+]claim_guest_boardcreate_board9 fields changedInput schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestCreationKeyRemoved value: -{
- "description": "Required only for a NEW board without an account or guestToken. Generate 32 random bytes locally and encode as unpadded base64url (43 characters). Retain this private recovery key with requestId and the exact arguments until the result is known; identical retries recover the same board and guest access. Never print, log or save it in a repository. Omit for account or existing guest work.",
- "pattern": "^[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]$",
- "type": "string"
-}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "requestId",
- "name",
- "intent"
-]New value: +[
+ "requestId",
+ "name",
+ "intent",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / properties / generationAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "properties": {
+ "boardId": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "boardId",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / data / properties / guestAccessRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "expiresAt": {
- "anyOf": [
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "guestToken": {
- "type": "string"
- },
- "limits": {
- "additionalProperties": false,
- "properties": {
- "boards": {
- "const": 1,
- "type": "number"
- }
- },
- "required": [
- "boards"
- ],
- "type": "object"
- }
- },
- "required": [
- "guestToken",
- "expiresAt",
- "limits"
- ],
- "type": "object"
-}Output schema / properties / data / properties / pollAfterSecondsAdded value: +{
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Output schema / properties / data / requiredPrevious value: -[
- "id",
- "organizationId",
- "ownerUserId",
- "createdByUserId",
- "name",
- "revision",
- "url",
- "intent",
- "settings",
- "physicalContext",
- "layout",
- "validation"
-]New value: +[
+ "id",
+ "organizationId",
+ "ownerUserId",
+ "createdByUserId",
+ "name",
+ "revision",
+ "url",
+ "intent",
+ "settings",
+ "physicalContext",
+ "layout",
+ "validation",
+ "boardRef"
+]delete_board5 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved account board ID from list_boards or get_board. Deletion requires personal ownership or organization owner/admin access.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "boardId",
- "expectedRevision"
-]New value: +[
+ "expectedRevision",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / requiredPrevious value: -[
- "boardId",
- "deleted"
-]New value: +[
+ "boardId",
+ "deleted",
+ "boardRef"
+]export_board6 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Accessible saved board ID from get_board, create_board, or list_boards.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "expectedRevision",
- "format"
-]New value: +[
+ "expectedRevision",
+ "format",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / requiredPrevious value: -[
- "name",
- "mimeType",
- "url",
- "expiresAt",
- "boardRevision"
-]New value: +[
+ "name",
+ "mimeType",
+ "url",
+ "expiresAt",
+ "boardRevision",
+ "boardRef"
+]generate_layout6 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "expectedRevision",
- "requestId"
-]New value: +[
+ "expectedRevision",
+ "requestId",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / requiredPrevious value: -[
- "generation",
- "boardRevision"
-]New value: +[
+ "generation",
+ "boardRevision",
+ "boardRef"
+]get_board8 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId"
-]New value: +[
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / properties / generationAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "properties": {
+ "boardId": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "boardId",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / data / properties / pollAfterSecondsAdded value: +{
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Output schema / properties / data / requiredPrevious value: -[
- "id",
- "organizationId",
- "ownerUserId",
- "createdByUserId",
- "name",
- "revision",
- "url",
- "intent",
- "settings",
- "physicalContext",
- "layout",
- "validation"
-]New value: +[
+ "id",
+ "organizationId",
+ "ownerUserId",
+ "createdByUserId",
+ "name",
+ "revision",
+ "url",
+ "intent",
+ "settings",
+ "physicalContext",
+ "layout",
+ "validation",
+ "boardRef"
+]get_generation11 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "generationId"
-]New value: +[
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / properties / generation / additionalPropertiesRemoved value: -{
- "$ref": "#/$defs/__schema0"
-}Output schema / properties / data / properties / generation / anyOfAdded value: +[
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "properties": {
+ "boardId": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "boardId",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / generation / propertiesRemoved value: -{
- "boardId": {
- "type": "string"
- },
- "id": {
- "type": "string"
- },
- "status": {
- "type": "string"
- }
-}Output schema / properties / data / properties / generation / requiredRemoved value: -[
- "id",
- "boardId",
- "status"
-]Output schema / properties / data / properties / generation / typeRemoved value: -"object"Output schema / properties / data / requiredPrevious value: -[
- "generation",
- "boardRevision"
-]New value: +[
+ "generation",
+ "boardRevision",
+ "boardRef"
+]get_part3 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Optional saved board ID requiring that board’s account or guest access. Enforces its strict Part List when enabled; omit for public catalog browsing.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}list_boards5 fields changedInput schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredAdded value: +[]Output schema / properties / data / properties / boards / items / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / properties / boards / items / requiredPrevious value: -[
- "id",
- "organizationId",
- "ownerUserId",
- "createdByUserId",
- "name",
- "revision",
- "url"
-]New value: +[
+ "id",
+ "organizationId",
+ "ownerUserId",
+ "createdByUserId",
+ "name",
+ "revision",
+ "url",
+ "boardRef"
+]search_parts4 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Optional saved board ID requiring that board’s account or guest access. Enforces its strict Part List when enabled; omit for public catalog browsing.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredAdded value: +[]start_guest_sessionstop_generation6 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "generationId"
-]New value: +[
+ "generationId",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / requiredPrevious value: -[
- "generation",
- "boardRevision"
-]New value: +[
+ "generation",
+ "boardRevision",
+ "boardRef"
+]update_board8 fields changedInput schema / properties / boardIdRemoved value: -{
- "description": "Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session.",
- "format": "uuid",
- "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
- "type": "string"
-}Input schema / properties / boardRefAdded value: +{
+ "description": "Private board reference. For a new board generate 32 random bytes, encode as unpadded base64url, and prepend egbr1_. Keep this same value for creation retries and every later board operation. Copy returned references unchanged. Keep it in this conversation or supported private execution state; never put it in logs or source files. A private board link may carry it in its fragment.",
+ "pattern": "^(?:egbr1_[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]|egba1_[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\.[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048])$",
+ "type": "string"
+}Input schema / properties / guestTokenRemoved value: -{
- "description": "Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository.",
- "maxLength": 200,
- "minLength": 32,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "boardId",
- "expectedRevision",
- "requestId"
-]New value: +[
+ "expectedRevision",
+ "requestId",
+ "boardRef"
+]Output schema / properties / data / properties / boardRefAdded value: +{
+ "type": "string"
+}Output schema / properties / data / properties / generationAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": {
+ "$ref": "#/$defs/__schema0"
+ },
+ "properties": {
+ "boardId": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "boardId",
+ "status"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / data / properties / pollAfterSecondsAdded value: +{
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Output schema / properties / data / requiredPrevious value: -[
- "id",
- "organizationId",
- "ownerUserId",
- "createdByUserId",
- "name",
- "revision",
- "url",
- "intent",
- "settings",
- "physicalContext",
- "layout",
- "validation"
-]New value: +[
+ "id",
+ "organizationId",
+ "ownerUserId",
+ "createdByUserId",
+ "name",
+ "revision",
+ "url",
+ "intent",
+ "settings",
+ "physicalContext",
+ "layout",
+ "validation",
+ "boardRef"
+]check_board_layout1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."claim_guest_board1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."create_board3 fields changedInput schema / properties / guestCreationKeyAdded value: +{
+ "description": "Required only for a NEW board without an account or guestToken. Generate 32 random bytes locally and encode as unpadded base64url (43 characters). Retain this private recovery key with requestId and the exact arguments until the result is known; identical retries recover the same board and guest access. Never print, log or save it in a repository. Omit for account or existing guest work.",
+ "pattern": "^[A-Za-z0-9_-]{42}[AEIMQUYcgkosw048]$",
+ "type": "string"
+}Input schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."Output schema / properties / data / properties / guestAccessAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "expiresAt": {
+ "anyOf": [
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "guestToken": {
+ "type": "string"
+ },
+ "limits": {
+ "additionalProperties": false,
+ "properties": {
+ "boards": {
+ "const": 1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "boards"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "guestToken",
+ "expiresAt",
+ "limits"
+ ],
+ "type": "object"
+}export_board1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."generate_layout1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."get_board1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."get_generation1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."get_part2 fields changedInput schema / properties / boardId / descriptionPrevious value: -"Optional saved board ID. Enforces that board’s strict Part List when enabled; omit to use the full published catalog."New value: +"Optional saved board ID requiring that board’s account or guest access. Enforces its strict Part List when enabled; omit for public catalog browsing."Input schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."list_boards3 fields changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."Output schema / properties / data / properties / accessAdded value: +{
+ "const": "anonymous",
+ "type": "string"
+}Output schema / properties / data / properties / messageAdded value: +{
+ "type": "string"
+}search_parts2 fields changedInput schema / properties / boardId / descriptionPrevious value: -"Optional saved board ID. Enforces that board’s strict Part List when enabled; omit to use the full published catalog."New value: +"Optional saved board ID requiring that board’s account or guest access. Enforces its strict Part List when enabled; omit for public catalog browsing."Input schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."stop_generation1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."update_board1 field changedInput schema / properties / guestToken / descriptionPrevious value: -"Private guest-session capability returned by start_guest_session. Never print it or save it in a repository."New value: +"Private continuation capability from create_board.guestAccess.guestToken or start_guest_session. Reuse it for this guest board. Never print it or save it in a repository."create_board5 fields changedInput schema / properties / boardEdits / descriptionPrevious value: -"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements uses design-local partId; mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."New value: +"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements and partClearances use design-local partId; keepouts, mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Keepout shape coordinates are board-plane mm; part clearance distances are in the part-local frame. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."Input schema / properties / boardEdits / properties / keepoutsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "remove": {
+ "description": "Remove listed id only.",
+ "items": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "type": "array"
+ },
+ "upsert": {
+ "description": "Upsert by id; retain omitted fields.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Board-fixed exclusion region. New items require name, x, y, rotationDeg, shape, restrictions, partSide and copperLayers. Nested objects replace complete fields; omission retains existing values.",
+ "properties": {
+ "addedAt": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "copperLayers": {
+ "description": "Selected physical copper layers; must exist on the board when restricting copper.",
+ "items": {
+ "enum": [
+ "F.Cu",
+ "In1.Cu",
+ "In2.Cu",
+ "B.Cu"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "name": {
+ "minLength": 1,
+ "pattern": "^[^\\u0000\\ud800-\\udfff]*$",
+ "type": "string"
+ },
+ "partSide": {
+ "enum": [
+ "top",
+ "bottom",
+ "both"
+ ],
+ "type": "string"
+ },
+ "restrictions": {
+ "additionalProperties": false,
+ "description": "Complete restriction set; at least one must be true.",
+ "properties": {
+ "copperFills": {
+ "type": "boolean"
+ },
+ "parts": {
+ "type": "boolean"
+ },
+ "tracks": {
+ "type": "boolean"
+ },
+ "vias": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "parts",
+ "tracks",
+ "vias",
+ "copperFills"
+ ],
+ "type": "object"
+ },
+ "rotationDeg": {
+ "description": "CCW board-plane degrees.",
+ "type": "number"
+ },
+ "shape": {
+ "description": "Complete replacement shape; omitted retains the current shape.",
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "heightMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "kind": {
+ "const": "rectangle",
+ "type": "string"
+ },
+ "widthMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "widthMm",
+ "heightMm"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "diameterMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "kind": {
+ "const": "circle",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "diameterMm"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "fileName": {
+ "minLength": 1,
+ "pattern": "^[^\\u0000\\ud800-\\udfff]*$",
+ "type": "string"
+ },
+ "kind": {
+ "const": "custom",
+ "type": "string"
+ },
+ "profile": {
+ "additionalProperties": false,
+ "description": "Complete custom keepout profile in mm; scaled width and height 0.1–1000, ≤2000 total segments.",
+ "properties": {
+ "cutouts": {
+ "description": "Closed voids ([]=none); prefer clockwise. Strictly inside; no touching, overlap or nesting.",
+ "items": {
+ "$ref": "#/$defs/outlineContour"
+ },
+ "maxItems": 1999,
+ "type": "array"
+ },
+ "outer": {
+ "$ref": "#/$defs/outlineContour",
+ "description": "Closed boundary; normalized CCW, lower-left (0,0)."
+ }
+ },
+ "required": [
+ "outer",
+ "cutouts"
+ ],
+ "type": "object"
+ },
+ "scalePercent": {
+ "description": "Uniform scale of the original profile; omitted is 100.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "sourceBase64": {
+ "description": "Existing retained DXF source only; never invent source bytes.",
+ "maxLength": 2796204,
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "profile",
+ "fileName"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / boardEdits / properties / partClearancesAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "remove": {
+ "description": "Remove listed partId only.",
+ "items": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "type": "array"
+ },
+ "upsert": {
+ "description": "Upsert by partId; retain omitted fields.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Part-attached clearance without pinning the part. New items require clearanceMm, linked, restrictions and copperLayers. Nested objects replace complete fields; omission retains existing values.",
+ "properties": {
+ "addedAt": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "clearanceMm": {
+ "additionalProperties": false,
+ "description": "Distances from the catalog body in its local frame; front is +Y before placement rotation or bottom-side reflection.",
+ "properties": {
+ "back": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "front": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "left": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "right": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "front",
+ "back",
+ "left",
+ "right"
+ ],
+ "type": "object"
+ },
+ "copperLayers": {
+ "description": "Selected physical copper layers; must exist on the board when restricting copper.",
+ "items": {
+ "enum": [
+ "F.Cu",
+ "In1.Cu",
+ "In2.Cu",
+ "B.Cu"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled": {
+ "type": "boolean"
+ },
+ "linked": {
+ "description": "Linked sides must have equal clearance distances.",
+ "type": "boolean"
+ },
+ "partId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "restrictions": {
+ "additionalProperties": false,
+ "description": "Complete restriction set; at least one must be true.",
+ "properties": {
+ "copperFills": {
+ "type": "boolean"
+ },
+ "parts": {
+ "type": "boolean"
+ },
+ "tracks": {
+ "type": "boolean"
+ },
+ "vias": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "parts",
+ "tracks",
+ "vias",
+ "copperFills"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "partId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / intent / properties / connections / items / properties / requiredCurrentA / descriptionPrevious value: -"Continuous A, all pins (mA/1000); omit for class widths."New value: +"Legacy net-wide current; preserve existing values only. Author new current requirements with pinCurrentRequirements."Input schema / properties / intent / properties / pinCurrentRequirementsAdded value: +{
+ "description": "Complete per-pin requirement list. Omit to preserve existing valid requirements; [] clears all. A supplied list replaces all prior entries. Use catalog pad numbers, one entry per partId/padId.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "direction": {
+ "description": "Conventional current relative to the net copper: into supplies it, out draws from it, bidirectional requires either direction.",
+ "enum": [
+ "into",
+ "out",
+ "bidirectional"
+ ],
+ "type": "string"
+ },
+ "padId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "partId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "requiredCurrentA": {
+ "description": "Required continuous current in amperes (mA/1000); zero is allowed.",
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "partId",
+ "padId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}export_board4 fields changedOutput schema / properties / data / properties / expiresAt / anyOfAdded value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / data / properties / expiresAt / formatRemoved value: -"date-time"Output schema / properties / data / properties / expiresAt / patternRemoved value: -"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$"Output schema / properties / data / properties / expiresAt / typeRemoved value: -"string"get_part3 fields changedInput schema / properties / factOffset / descriptionPrevious value: -"Zero-based fact offset; defaults to 0. Continue with datasheetFacts.nextFactOffset and the same factQuery."New value: +"Continue at nextFactOffset with the same factQuery."Input schema / properties / factQuery / descriptionPrevious value: -"Terms selecting relevant cached datasheet facts for this part; omit for the default fact bundle."New value: +"Terms for relevant facts omitted from the supplied bundle."Input schema / properties / id / descriptionPrevious value: -"Exact published catalog ID returned by search_parts."New value: +"Catalog ID returned by search_parts."search_parts8 fields changedInput schema / properties / capacitance / descriptionPrevious value: -"Exact capacitance in farads (1e-7 = 100 nF)."New value: +"Exact farads (1e-7 = 100 nF)."Input schema / properties / category / descriptionPrevious value: -"Exact catalog category; omit when unknown."New value: +"Catalog category."Input schema / properties / frequency / descriptionPrevious value: -"Exact frequency in hertz (8e6 = 8 MHz)."New value: +"Hertz (8e6 = 8 MHz)."Input schema / properties / inductance / descriptionPrevious value: -"Exact inductance in henries (1e-6 = 1 µH)."New value: +"Exact henries."Input schema / properties / jlcpcbBasic / descriptionPrevious value: -"Restrict to JLCPCB Basic parts when true; false or omission leaves this filter unset."New value: +"Basic-only when true; otherwise leave unset."Input schema / properties / resistance / descriptionPrevious value: -"Exact resistance in ohms (10000 = 10 kΩ)."New value: +"Exact ohms (10000 = 10 kΩ)."Input schema / properties / subcategory / descriptionPrevious value: -"Exact catalog subcategory, such as chip_resistor, mlcc, or ldo."New value: +"Subcategory, e.g. chip_resistor, mlcc, ldo."Input schema / properties / voltageRating / descriptionPrevious value: -"Exact voltage rating in volts."New value: +"Rated volts."update_board5 fields changedInput schema / properties / boardEdits / descriptionPrevious value: -"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements uses design-local partId; mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."New value: +"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements and partClearances use design-local partId; keepouts, mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Keepout shape coordinates are board-plane mm; part clearance distances are in the part-local frame. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."Input schema / properties / boardEdits / properties / keepoutsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "remove": {
+ "description": "Remove listed id only.",
+ "items": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "type": "array"
+ },
+ "upsert": {
+ "description": "Upsert by id; retain omitted fields.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Board-fixed exclusion region. New items require name, x, y, rotationDeg, shape, restrictions, partSide and copperLayers. Nested objects replace complete fields; omission retains existing values.",
+ "properties": {
+ "addedAt": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "copperLayers": {
+ "description": "Selected physical copper layers; must exist on the board when restricting copper.",
+ "items": {
+ "enum": [
+ "F.Cu",
+ "In1.Cu",
+ "In2.Cu",
+ "B.Cu"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "name": {
+ "minLength": 1,
+ "pattern": "^[^\\u0000\\ud800-\\udfff]*$",
+ "type": "string"
+ },
+ "partSide": {
+ "enum": [
+ "top",
+ "bottom",
+ "both"
+ ],
+ "type": "string"
+ },
+ "restrictions": {
+ "additionalProperties": false,
+ "description": "Complete restriction set; at least one must be true.",
+ "properties": {
+ "copperFills": {
+ "type": "boolean"
+ },
+ "parts": {
+ "type": "boolean"
+ },
+ "tracks": {
+ "type": "boolean"
+ },
+ "vias": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "parts",
+ "tracks",
+ "vias",
+ "copperFills"
+ ],
+ "type": "object"
+ },
+ "rotationDeg": {
+ "description": "CCW board-plane degrees.",
+ "type": "number"
+ },
+ "shape": {
+ "description": "Complete replacement shape; omitted retains the current shape.",
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "heightMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "kind": {
+ "const": "rectangle",
+ "type": "string"
+ },
+ "widthMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "widthMm",
+ "heightMm"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "diameterMm": {
+ "maximum": 1000,
+ "minimum": 0.1,
+ "type": "number"
+ },
+ "kind": {
+ "const": "circle",
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "diameterMm"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "fileName": {
+ "minLength": 1,
+ "pattern": "^[^\\u0000\\ud800-\\udfff]*$",
+ "type": "string"
+ },
+ "kind": {
+ "const": "custom",
+ "type": "string"
+ },
+ "profile": {
+ "additionalProperties": false,
+ "description": "Complete custom keepout profile in mm; scaled width and height 0.1–1000, ≤2000 total segments.",
+ "properties": {
+ "cutouts": {
+ "description": "Closed voids ([]=none); prefer clockwise. Strictly inside; no touching, overlap or nesting.",
+ "items": {
+ "$ref": "#/$defs/outlineContour"
+ },
+ "maxItems": 1999,
+ "type": "array"
+ },
+ "outer": {
+ "$ref": "#/$defs/outlineContour",
+ "description": "Closed boundary; normalized CCW, lower-left (0,0)."
+ }
+ },
+ "required": [
+ "outer",
+ "cutouts"
+ ],
+ "type": "object"
+ },
+ "scalePercent": {
+ "description": "Uniform scale of the original profile; omitted is 100.",
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "sourceBase64": {
+ "description": "Existing retained DXF source only; never invent source bytes.",
+ "maxLength": 2796204,
+ "type": "string"
+ }
+ },
+ "required": [
+ "kind",
+ "profile",
+ "fileName"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "x": {
+ "type": "number"
+ },
+ "y": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / boardEdits / properties / partClearancesAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "remove": {
+ "description": "Remove listed partId only.",
+ "items": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "type": "array"
+ },
+ "upsert": {
+ "description": "Upsert by partId; retain omitted fields.",
+ "items": {
+ "additionalProperties": false,
+ "description": "Part-attached clearance without pinning the part. New items require clearanceMm, linked, restrictions and copperLayers. Nested objects replace complete fields; omission retains existing values.",
+ "properties": {
+ "addedAt": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "clearanceMm": {
+ "additionalProperties": false,
+ "description": "Distances from the catalog body in its local frame; front is +Y before placement rotation or bottom-side reflection.",
+ "properties": {
+ "back": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "front": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "left": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "right": {
+ "maximum": 1000,
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "front",
+ "back",
+ "left",
+ "right"
+ ],
+ "type": "object"
+ },
+ "copperLayers": {
+ "description": "Selected physical copper layers; must exist on the board when restricting copper.",
+ "items": {
+ "enum": [
+ "F.Cu",
+ "In1.Cu",
+ "In2.Cu",
+ "B.Cu"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "enabled": {
+ "type": "boolean"
+ },
+ "linked": {
+ "description": "Linked sides must have equal clearance distances.",
+ "type": "boolean"
+ },
+ "partId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "restrictions": {
+ "additionalProperties": false,
+ "description": "Complete restriction set; at least one must be true.",
+ "properties": {
+ "copperFills": {
+ "type": "boolean"
+ },
+ "parts": {
+ "type": "boolean"
+ },
+ "tracks": {
+ "type": "boolean"
+ },
+ "vias": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "parts",
+ "tracks",
+ "vias",
+ "copperFills"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "partId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}Input schema / properties / intent / properties / connections / items / properties / requiredCurrentA / descriptionPrevious value: -"Continuous A, all pins (mA/1000); omit for class widths."New value: +"Legacy net-wide current; preserve existing values only. Author new current requirements with pinCurrentRequirements."Input schema / properties / intent / properties / pinCurrentRequirementsAdded value: +{
+ "description": "Complete per-pin requirement list. Omit to preserve existing valid requirements; [] clears all. A supplied list replaces all prior entries. Use catalog pad numbers, one entry per partId/padId.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "direction": {
+ "description": "Conventional current relative to the net copper: into supplies it, out draws from it, bidirectional requires either direction.",
+ "enum": [
+ "into",
+ "out",
+ "bidirectional"
+ ],
+ "type": "string"
+ },
+ "padId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "partId": {
+ "$ref": "#/$defs/boardIdentifier"
+ },
+ "requiredCurrentA": {
+ "description": "Required continuous current in amperes (mA/1000); zero is allowed.",
+ "minimum": 0,
+ "type": "number"
+ }
+ },
+ "required": [
+ "partId",
+ "padId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}check_board_layout1 field changedInput schema / properties / expectedRevision / descriptionPrevious value: -"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."New value: +"Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation."create_board2 fields changedInput schema / properties / boardEdits / properties / settings / properties / copperPourClearanceMmAdded value: +{
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Copper pour clearance in mm to foreign copper: 0.10–1.00 for 1oz, 0.20–1.00 for 2oz; default 0.20. Null selects Automatic. Existing values outside this range remain valid when unchanged. Changes require regenerating the board."
+}Input schema / properties / intent / properties / suggestedNameRemoved value: -{
- "type": "string"
-}delete_board1 field changedInput schema / properties / expectedRevision / descriptionPrevious value: -"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."New value: +"Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation."generate_layout1 field changedInput schema / properties / expectedRevision / descriptionPrevious value: -"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."New value: +"Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation."update_board3 fields changedInput schema / properties / boardEdits / properties / settings / properties / copperPourClearanceMmAdded value: +{
+ "anyOf": [
+ {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Copper pour clearance in mm to foreign copper: 0.10–1.00 for 1oz, 0.20–1.00 for 2oz; default 0.20. Null selects Automatic. Existing values outside this range remain valid when unchanged. Changes require regenerating the board."
+}Input schema / properties / expectedRevision / descriptionPrevious value: -"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."New value: +"Latest saved revision from create_board, update_board or get_board. Reuse it if no intervening change is known. A mismatch returns revision_conflict; read the board again before preparing a new operation."Input schema / properties / intent / properties / suggestedNameRemoved value: -{
- "type": "string"
-}submit_feedbackcheck_board_layout2 fields changedInput schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / expectedRevision / descriptionAdded value: +"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."create_board5 fields changedInput schema / properties / boardEdits / descriptionAdded value: +"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements uses design-local partId; mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."Input schema / properties / intent / descriptionAdded value: +"Complete initial schematic using published catalog IDs and verified pins. Parts and connections use the thin intent format described by this tool."Input schema / properties / name / descriptionAdded value: +"Display name for the board."Input schema / properties / organizationId / descriptionAdded value: +"Organization ID from list_organizations. Omit for personal account boards; guest sessions cannot use organizations."Input schema / properties / requestId / descriptionAdded value: +"New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation."delete_boardexport_board4 fields changedInput schema / properties / boardId / descriptionAdded value: +"Accessible saved board ID from get_board, create_board, or list_boards."Input schema / properties / changeNote / descriptionAdded value: +"Description of modifications, required when get_board returns inherited licensing. Added to the exported license notices."Input schema / properties / expectedRevision / descriptionAdded value: +"Revision from get_board. A mismatch returns revision_conflict; read the board again before exporting."Input schema / properties / format / descriptionAdded value: +"manufacturing: ZIP with Gerber, drill, BOM and placement files. egb: editable EasyGerber board file."generate_layout3 fields changedInput schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / expectedRevision / descriptionAdded value: +"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."Input schema / properties / requestId / descriptionAdded value: +"New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation."get_board2 fields changedInput schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / includePreview / descriptionAdded value: +"Include an image of the current saved layout; omitted or false skips rendering. Returns preview: null when no current layout is available."get_generation2 fields changedInput schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / generationId / descriptionAdded value: +"Layout generation ID returned by generate_layout for this same board. Use the exact job ID when polling or stopping it."get_part4 fields changedInput schema / properties / boardId / descriptionAdded value: +"Optional saved board ID. Enforces that board’s strict Part List when enabled; omit to use the full published catalog."Input schema / properties / factOffset / descriptionAdded value: +"Zero-based fact offset; defaults to 0. Continue with datasheetFacts.nextFactOffset and the same factQuery."Input schema / properties / factQuery / descriptionAdded value: +"Terms selecting relevant cached datasheet facts for this part; omit for the default fact bundle."Input schema / properties / id / descriptionAdded value: +"Exact published catalog ID returned by search_parts."list_boards3 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum boards to return; defaults to 20."Input schema / properties / offset / descriptionAdded value: +"Zero-based offset; defaults to 0. Continue with returned nextOffset; null means no further page."Input schema / properties / organizationId / descriptionAdded value: +"Organization ID from list_organizations. Omit for personal account boards; guest sessions cannot use organizations."search_parts14 fields changedInput schema / properties / boardId / descriptionAdded value: +"Optional saved board ID. Enforces that board’s strict Part List when enabled; omit to use the full published catalog."Input schema / properties / capacitance / descriptionAdded value: +"Exact capacitance in farads (1e-7 = 100 nF)."Input schema / properties / category / descriptionAdded value: +"Exact catalog category; omit when unknown."Input schema / properties / factQuery / descriptionPrevious value: -"Cached-fact terms only; requires query. Omit for filter-only searches."New value: +"Cached-fact terms only; requires query. Omit for filter-only searches. It never changes which parts match."Input schema / properties / frequency / descriptionAdded value: +"Exact frequency in hertz (8e6 = 8 MHz)."Input schema / properties / inductance / descriptionAdded value: +"Exact inductance in henries (1e-6 = 1 µH)."Input schema / properties / jlcpcbBasic / descriptionAdded value: +"Restrict to JLCPCB Basic parts when true; false or omission leaves this filter unset."Input schema / properties / limit / descriptionAdded value: +"Maximum catalog candidates to return, from 1 to 20; defaults to 3."Input schema / properties / mountingType / descriptionAdded value: +"smt: surface mount; tht: through-hole; mixed: both."Input schema / properties / package / descriptionAdded value: +"Exact catalog label; use query for package families."Input schema / properties / query / descriptionPrevious value: -"PCB selection terms: MPN, manufacturer, description or package family. For exact MPNs omit unverified categories unless user-required. Preserve explicit filters and Part Lists; factQuery does not select parts."New value: +"PCB selection terms: MPN, manufacturer, description or package family. For exact MPNs omit unverified categories unless user-required. Preserve explicit filters and Part Lists; factQuery does not select parts. Required when factQuery is supplied."Input schema / properties / resistance / descriptionAdded value: +"Exact resistance in ohms (10000 = 10 kΩ)."Input schema / properties / subcategory / descriptionAdded value: +"Exact catalog subcategory, such as chip_resistor, mlcc, or ldo."Input schema / properties / voltageRating / descriptionAdded value: +"Exact voltage rating in volts."stop_generation2 fields changedInput schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / generationId / descriptionAdded value: +"Layout generation ID returned by generate_layout for this same board. Use the exact job ID when polling or stopping it."update_board6 fields changedInput schema / properties / boardEdits / descriptionAdded value: +"Physical patch; omitted fields retain existing values. settings changes only supplied app-supported settings (dimensions in mm). outline replaces the outline with a library choice or complete generated profile including retained cutouts. fixedPlacements uses design-local partId; mountingHoles, silkscreenTexts, and silkscreenSvgs use item id. Each collection uses upsert to add or merge items and remove to remove only listed IDs, not replace the collection. Removing a fixed placement unpins the part without deleting it. Positions are in board-plane mm; rotationDeg is counterclockwise degrees. Attached DXF and new SVG assets are unavailable through MCP. Existing SVG artwork can be edited or removed by item id; omit assetId."Input schema / properties / boardId / descriptionAdded value: +"Saved board ID from list_boards, create_board, claim_guest_board, or an account board URL. Must be accessible to the current account or guest session."Input schema / properties / expectedRevision / descriptionAdded value: +"Saved revision returned by get_board. A mismatch returns revision_conflict; read the board again before preparing a new operation."Input schema / properties / intent / descriptionAdded value: +"Complete replacement schematic, including every part and connection to retain. Omit for name-only or physical-only edits."Input schema / properties / name / descriptionAdded value: +"Display name for the board."Input schema / properties / requestId / descriptionAdded value: +"New UUID for this operation. Reuse it with identical arguments when retrying an uncertain result; use a new UUID for a different operation."check_board_layoutclaim_guest_boardcreate_boardexport_boardgenerate_layoutget_boardget_generationget_partget_profilelist_boardslist_organizationssearch_partsstart_guest_sessionstop_generationupdate_boardDesign, route, check, review and export manufacturable PCBs from plain language; KiCad import.
Design and revise PCBs from plain language, track jobs, and retrieve design artifacts.
AI electronics blueprint generator — BOM, wiring, firmware, renders for Arduino/ESP32/RPi.
Turn your offers into an AI agent. Set it up from your MCP assistant, answer customer questions, collect enquiries and connect with other agents via A2A. OAuth sign-in; free plan available.
Add one secure layer between your agents and this server.
