Skip to main content
Glama
flaco-source

altium-mcp

by flaco-source
OverviewSchemaRelated ServersScoreDiscussions
Local

Schematic sheet (filtered export)

get_schematic_data
Read-onlyIdempotent

Export schematic sheet data with optional include filters, preventing large sheets from flooding the agent context. Useful for BOM, wiring checks, and verifying edits.

Instructions

Purpose: Export schematic sheet content with optional filtering so large sheets do not flood the agent context.

When to use: BOM/placement review, wiring checks, sheet size for placement, or verify edit_schematic results. Prefer include_queries with a small subset on busy designs.

Parameters (all optional):

  • schematic_full_path: absolute path to one .SchDoc in an open project (slashes / or ). Preferred for multi-project workspaces.

  • project_full_path: absolute path to open .PrjPcb / .PrjScr. Use with schematic_sheet_file_name or alone for all SCH sheets in that project.

  • schematic_sheet_file_name: file name only (e.g. Sheet1.SchDoc). Requires focused project or project_full_path.

  • include_queries: string array selecting what to return. Omit entirely for legacy JSON (backward compatible): only { components, drawing_objects }. If present, response uses schematic_data_mode "filtered" and only the requested buckets (plus include_queries echo). Token all expands to every supported bucket. Supported tokens: sheet | components | wires | buses | net_labels | power_ports | text_labels | junctions | ports | off_sheet_connectors | sheet_symbols | directives | figures | harness | drawing_objects. harness currently returns an empty array (placeholder for future API). drawing_objects is the combined non-component list (same mix as legacy). sheet returns sheets[] with one object per matched .SchDoc (size in mils, grids, borders, template path, etc.).

Resolution order: schematic_full_path wins; else project_full_path + optional sheet file name; else focused project. Without schematic_full_path / sheet file name, all SCH documents in the chosen project are scanned (aggregated arrays / multiple sheets[] entries).

Primitive shape (per object): object_kind, object_id, bbox_*_mils, plus type-specific fields (vertices_mils for wire/bus/polyline, x1/y1/x2/y2 for line/bus entry, text for net labels / power / text labels, etc.) — same as legacy drawing_objects entries.

Prerequisites: Target project must be open in Altium. Does not require active PCB.

Errors: ERROR: NO_WORKSPACE, NO_FOCUSED_PROJECT, PROJECT_NOT_FOUND, SCHEMATIC_NOT_IN_OPEN_PROJECTS (Delphi); bridge errors otherwise.

Notes: Invalid include_queries tokens only (no matches) fall back to legacy mode. Does not flatten pins inside components or sheet entries inside sheet symbols.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
include_queriesNoFilter what to return. Omit for legacy shape { components, drawing_objects }. Use ["all"] for every split bucket + sheets[]. Otherwise pick one or more: sheet (size/grids per .SchDoc), components, wires, buses, net_labels, power_ports, text_labels, junctions, ports, off_sheet_connectors, sheet_symbols, directives, figures, harness (placeholder []), drawing_objects (combined primitives as before).
project_full_pathNoAbsolute path to an open .PrjPcb or .PrjScr. Required when using schematic_sheet_file_name without a focused project, or to read another open project.
schematic_full_pathNoAbsolute path to one .SchDoc that is a logical document of an open project. Use forward or backslashes. Example: D:/Design/Board/Sheet1.SchDoc
schematic_sheet_file_nameNoOnly the file name of the sheet (e.g. Sheet1.SchDoc). Scope: focused project or project_full_path. Ignored if schematic_full_path is set.

Tool Definition Quality

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral details beyond these: error code names, fallback to legacy mode on invalid include_queries, the placeholder behavior of 'harness', the limitation of not flattening pins/sheet entries, and the resolution order. There is no contradiction with annotations.

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

Conciseness5/5

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

The description is long but appropriately structured with labeled sections (Purpose, When to use, Parameters, Resolution order, Primitive shape, Prerequisites, Errors, Notes). It is front-loaded with the most important usage guidance, and every sentence provides operational value—e.g., the 'harness' placeholder, error codes, and non-flattening note prevent confusion. No filler or redundancy.

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

Completeness5/5

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

For a tool with 4 optional parameters, no output schema, and moderate complexity, the description covers all necessary aspects: what it returns (legacy vs. filtered shapes, primitive structure), how to disambiguate multiple projects, error codes, and prerequisites (open project, no active PCB needed). This is sufficient for an agent to correctly invoke the tool and interpret results.

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

Parameters5/5

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

Although schema description coverage is 100%, the description adds crucial semantics: the legacy vs. filtered mode distinction based on including include_queries, the exact effect of 'all', the resolution order hierarchy (schematic_full_path wins, then project_full_path + sheet file name, then focused project), and the relationship between sheet file name and project path. These go far beyond the schema's per-parameter descriptions.

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

Purpose5/5

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

The description opens with a specific verb+resource: 'Export schematic sheet content with optional filtering'. It clearly states the purpose of avoiding context flooding, and differentiates from sibling tools by mentioning 'verify edit_schematic results' and by focusing on schematic sheet data, unlike get_pcb_layers or get_pcb_rules.

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

Usage Guidelines5/5

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

It explicitly provides a 'When to use' section: 'BOM/placement review, wiring checks, sheet size for placement, or verify edit_schematic results.' It also advises to 'Prefer include_queries with a small subset on busy designs', giving clear guidance on when and how to use the filtering. The resolution order and prerequisites offer additional unambiguous usage context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/flaco-source/altium-mcp'

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