Skip to main content
Glama
Sign In
oaslananka

easyeda-mcp-pro

by oaslananka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set schematic title block fields

easyeda_schematic_set_title_block

Update EasyEDA Pro schematic title block fields for Company, Version, Drawn, Reviewed, and Page Size while protecting read-only layout elements.

Instructions

Update schematic title block text fields (Company, Version, Drawn, Reviewed, Page Size). Only these 5 are exposed — writing Symbol/Border/Device/etc once corrupted a real title block; those are read-only natively and must be fixed via the EasyEDA Pro UI.

Input Schema

NameRequiredDescriptionDefault
fieldsYesMap of title block field name to the sub-fields to change, e.g. { "Company": { "value": "ACME", "showValue": true } }
confirmWriteYesMust be the literal boolean true (not the string "true") to allow this write.
showTitleBlockNoShow/hide the whole title block

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.19.3
    • removedInput schema / properties / fields / additionalProperties / properties / value / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]
    • addedInput schema / properties / fields / additionalProperties / properties / value / type
      Added value: +[
+  "string",
+  "number"
+]
  2. Changed2 schema fields changedv0.19.2
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv0.19.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations mark this as a non-read-only, non-idempotent write, and the description adds genuinely new behavioral context beyond that: the write surface is deliberately restricted and out-of-scope writes have caused real corruption. It stops short of describing failure behavior or what a successful write returns, though the presence of an output schema offsets that omission.

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

Conciseness4/5

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

Two sentences, front-loaded with the action and its scope; the corruption anecdote is unusually long for a description but it earns its place as a safety warning. The parenthetical field list slightly duplicates the schema enum.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety semantics and an output schema covering returns, the description's job is largely the write-boundary warning, which it delivers. An agent still lacks any note on whether a transaction or save step is required after this write.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: why the propertyNames enum is limited to those five keys and what happens if an agent tries to exceed it. The confirmWrite gate and showTitleBlock are left to the schema, which documents them adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource ("Update schematic title block text fields") and enumerates exactly which five fields are touched. No sibling tool covers title block fields, so the definition is unambiguous against the surrounding catalogue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description sets a clear boundary: only these 5 fields are writable, and other title block attributes must be edited in the EasyEDA Pro UI instead. It gives the reason (a prior write corrupted a real title block), which functions as an explicit when-not. It does not, however, state prerequisites such as needing a transaction or a live bridge connection.

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

Deploy Server

Other Tools