Skip to main content
Glama

Technical datasheet of a Siemens product

siemens_product_datasheet
Read-onlyIdempotent

Returns the technical datasheet of one Siemens industry product by its article number (MLFB, for example "6EP3436-8SB00-0AY0") as structured data: sections of properties with values and units (supply voltage, currents, power loss, dimensions, ambient conditions, ...), eClass and ETIM classes and certificates. Use it to check ratings, compare products or verify that devices fit together, for example summing the 24 V DC current of controllers against a power supply rating. When the user only names a product family or a rating, find the article number first with siemens_search and scope "articles". Some product families publish their data only as PDF: then "hasTechnicalData" is false; give the user "datasheetPdfUrl" and do not guess values. Do not use it for prices, availability or delivery times, which it does not return, or for non-Siemens products.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "articleNumber": "<articleNumber>"
    },
    "name": "siemens_product_datasheet"
  }
}

Input Schema

NameRequiredDescriptionDefault
sectionNoOnly return sections whose name contains this text (case-insensitive), for example "supply voltage" or "ambient". Omit for the full datasheet; "availableSections" lists all names.
languageNoDatasheet language: en (default), de, fr, es, it or zh. Property names and text values are translated; numbers and units stay the same.
articleNumberYesSiemens article number (MLFB) exactly as in the catalog, for example "6ES7214-1AG40-0XB0" or "3RV2021-4EA10". Case and extra spaces do not matter.

Output Schema

NameRequiredDescriptionDefault
hintYes
sourceYes
languageYes
sectionsYes
productUrlYes
certificatesYes
lastModifiedYesDate the datasheet data was last changed, as printed.
articleNumberYes
propertyCountYes
classificationsYes
datasheetPdfUrlYes
hasTechnicalDataYesfalse when the HTML datasheet carries no technical data table; then only the PDF datasheet may have it.
shortDescriptionYes
availableSectionsYesAll section names of the datasheet, also when filtered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description still adds real behavioral context beyond them: the shape of the payload (property sections with values and units, eClass/ETIM, certificates) and the PDF-only edge case where hasTechnicalData is false and datasheetPdfUrl must be surfaced instead of guessing values. It does not mention call limits or partial-failure behavior, keeping it short of a 5.

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?

Front-loaded with the verb and resource, then prerequisites, then the PDF caveat and exclusions — a logical routing order. It is longer than average, and the electrical-summing example could be trimmed, but every sentence carries operational information.

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?

An output schema exists, yet the description still characterizes the returned sections and classes so the agent knows what is usable. Combined with the prerequisite routing, the missing-data fallback, and the negative scope, nothing needed to call it correctly is absent.

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

Parameters3/5

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

Schema description coverage is 100%, so articleNumber, section and language are already fully documented, including format examples, the fallback to availableSections, and the note that only text is translated. The description reinforces the article-number format but adds no new meaning for section or language, so the baseline 3 applies.

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 specific verb and resource (returns the technical datasheet of one Siemens industry product) with the exact key (article number / MLFB) and an example value. It is clearly distinguishable from siemens_search, which is named as the tool for finding the article number.

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?

Gives positive use cases (check ratings, compare products, verify fit, e.g. summing 24 V DC currents), an explicit prerequisite path (use siemens_search with scope "articles" when only a family or rating is named), and explicit exclusions (not for prices, availability, delivery times, or non-Siemens products).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources