PartsPlan

List where figures, pin descriptions and application circuits sit in an archived datasheet

get_datasheet_map

Read-onlyIdempotent

Locates datasheet captions and section headings, plus a separate paginated visual_navigation inventory. Graphics remain visible without a caption or interpretable values, including vector curves and image-only pages. Unknown/failed/uninspected pages are explicit. kind filters text headings only, never hides unclassified visual regions. Nearby text is an unverified clue. navigation_scope describes geometry extent, not precision; broad regions can contain multiple items. each page_text_request reads that page with get_page_blocks bound to the same artifact; get_page_image opens original pixels when available. No graph values or verified specifications. Items can also carry located headings, tables and figures with role (section|table|figure) and bbox_rel (0-1000 page box), and outline lists every located heading, table and figure, including sections with no kind.

Input Schema

Name	Required	Description
`kind`	No	filter; omit for all. figure/pinmap/app_circuit are captions and headings for drawings; the rest are section headings (abs_max, elec_char, rec_op, thermal, ordering, package, marking, features, timing, truth_table; land_pattern = recommended PCB land pattern / footprint, layout = PCB layout guidelines — these two only when a printed heading names them). pinmap/app_circuit also return figure captions that name one ("Figure 25: Enable Input drive circuit")
`detail`	No	default compact: outline entries omit kinds when empty, title/block_id when null and title_check when "exact"; bookmarks omit block_id when null and title_check when "exact". full returns every field.
`max_items`	No	default 100
`doc_sha256`	Yes
`outline_limit`	No	outline entries per response, default 100
`outline_offset`	No	continue the outline list from this entry (use outline_next_offset); requires expected_map_snapshot_sha256
`bookmarks_limit`	No	bookmarks entries per response, default 100
`bookmarks_offset`	No	continue the bookmarks list from this entry (use bookmarks_next_offset); requires expected_map_snapshot_sha256
`visual_start_page`	No	First physical page of visual inventory; default 1. visual_navigation.next_start_page gives the start page for later pages.
`visual_artifact_sha256`	No	On continuation pass the previous document.artifact_sha256; a changed artifact is rejected.
`expected_map_snapshot_sha256`	No	map_snapshot_sha256 from the first response; a changed map is rejected instead of mixing lists

Output Schema

Name	Required	Description	Default
`note`	No
`items`	No
`ai_map`	No
`counts`	No
`detail`	No
`reason`	No
`status`	Yes
`message`	No
`outline`	No
`pdf_url`	No
`document`	No
`bookmarks`	No
`retryable`	No
`doc_sha256`	No
`request_id`	No
`total_items`	No
`citation_url`	No
`outline_total`	No
`outline_offset`	No
`retry_after_ms`	No
`withdrawn_note`	No
`bookmarks_total`	No
`bookmarks_offset`	No
`bookmarks_origin`	No
`truncated_output`	No
`outline_truncated`	No
`visual_navigation`	No
`bookmarks_truncated`	No
`map_snapshot_sha256`	No
`outline_next_offset`	No
`short_document_read`	No
`bookmarks_next_offset`	No
`withdrawn_documents_omitted`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026
- addedOutput schema / properties / items / items / properties / evidence_block_ids
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
First observedOct 10, 2026

TDQS

A3.7/5.0

Behavior4/5

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 adds real behavioral context: unclassified visual regions stay visible, unknown/failed/uninspected pages are explicitly reported, nearby text is unverified, and continuation passes are hash-pinned via artifact/map snapshots. That is meaningful disclosure beyond the annotation set, though the telegraphic phrasing makes some of it hard to parse.

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

Conciseness3/5

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

The core purpose is front-loaded, but the remainder is a dense run-on of clipped clauses ('get_page_blocks bound to the same artifact') that reads as notes rather than structured guidance. Little is wasted, but readability and logical grouping suffer.

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 an output schema present, return values need not be explained, and the description still covers the key output concepts an agent must interpret: outline entries, role (section|table|figure), bbox_rel, and pagination continuation. Combined with the schema and annotations, an agent has enough to call it correctly, though the continuation contract is only lightly described.

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 coverage is already 91%, so baseline is 3. The description goes further by explaining that kind filters text headings only and never hides unclassified visual regions, and that navigation_scope describes geometry extent rather than precision. These are semantic nuances not derivable from the enum alone.

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

Purpose4/5

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

Opens with a clear verb+resource: it locates captions and section headings and returns a paginated visual_navigation inventory, which an agent can distinguish from search_datasheet or find_datasheet. The title reinforces the scope (figures, pin descriptions, application circuits). It never explicitly names a sibling it is not, so differentiation relies on inference.

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

Usage Guidelines3/5

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

It routes follow-up work ('each page_text_request reads that page with get_page_blocks... get_page_image opens original pixels') and rules out graph values and verified specs, implying get_figure_data is the alternative for values. But there is no explicit when-to-use statement against the other retrieval siblings like search_datasheet or reference_circuits; usage is implied rather than stated.

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

All PartsPlan tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?