Skip to main content
Glama

Whatic IC Datasheets

by io.whatic

get_image

Fetch datasheet figure images (PNG/JPEG) for opaque ref tokens obtained from search/lookup/get_segments. Returns each image plus its caption/description/page metadata. Only type='image' segments have image data; a ref that is not one comes back as an error record whose available_images lists the document's figures nearest that ref's page and section, closest first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refsYesOpaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / refs / description
      Previous value: -"Opaque `ref` tokens (from search/lookup/get) of image segments; non-image segments return an error record."New value: +"Opaque `ref` tokens (from search/lookup/get_segments) of image segments; non-image segments return an error record."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly explains return contents (image plus caption/description/page metadata), the type constraint (only type='image' segments), and the error behavior with available_images fallback. This is detailed and honest about edge cases.

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 three sentences with no filler. The core action and subject are front-loaded, followed by return details and edge-case behavior. Every sentence contributes directly to correct tool usage.

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 single-parameter tool with no output schema and no annotations, the description provides all essential context: input provenance, expected segment type, return metadata, and error handling. An agent can select and invoke this tool correctly without additional information.

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 100%, so the parameter refs is already documented. The description adds meaningful context beyond the schema: refs are opaque tokens from prior searches, image segments are required, and non-image tokens produce error records. This helps the agent construct valid inputs.

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

Purpose5/5

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

The description clearly states the tool's function: fetching datasheet figure images (PNG/JPEG) for opaque ref tokens. It also differentiates itself from siblings by specifying the token source (search/lookup/get_segments) and the segment type requirement, making its scope unambiguous.

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 gives clear context on when to use the tool: after obtaining ref tokens from search/lookup/get_segments, and specifically for image segments. It also explains the failure mode for non-image segments, but does not explicitly name an alternative tool for those cases.

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

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Each tool maps to a distinct retrieval mode (parametric search, ranking comparison, corpus search, segment expansion, image fetching, canonical specs), but lookup/search/get_segments overlap somewhat in scope. The descriptions mitigate this by directing when to prefer lookup vs search.

Naming Consistency4/5

Most tools follow a clear snake_case verb_noun structure (find_parts, compare_parts, get_image, get_segments, get_specs), with lookup and search as shorter imperative verbs. This is readable and predictable, though not perfectly uniform.

Tool Count5/5

Seven tools cover the datasheet workflow without redundancy: search, lookup, specs, images, compare, and parametric find. The count is appropriate for a focused IC datasheet domain.

Completeness5/5

The tool set covers the full retrieval workflow from unknown-part corpus search to known-part spec lookup, segmented content, and figure images. Parametric search and part comparison add high-level selection capabilities, with explicit fallback guidance preventing dead ends.

Resources