Skip to main content
Glama
Sign In

SDSentry: Safety Data Sheet Lookup, GHS Pictograms & HazCom

by com.0xpi.sdsentry
OverviewDiscussionsAdmin

Search safety data sheets (SDS) by product or manufacturer

search_sds
Read-onlyIdempotent

Find a safety data sheet (SDS) by product name or manufacturer, using the same lookup that powers SDSentry's free /sds-search page plus matching sheets already in SDSentry's shared SDS library. Returns up to 5 matches with product, manufacturer, whether the PDF is manufacturer-hosted or a third-party copy, the revision date printed on the sheet when it has been read, the SDS PDF link, a public page to view or print it, and a link to SDSentry's free, no-signup printable GHS secondary-container label maker for that product (with language "es", the best match also carries the manufacturer's own Spanish SDS link when one was found and read, never a machine translation, and the Spanish label maker) (it fills the label from the sheet when the sheet's Section 1 is confirmed; otherwise the hazard classes are ticked by hand). A product that cannot be identified reliably is reported as not found, never guessed. Read-only, free, no signup.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum matches to return (default 5).
queryYesProduct name and/or manufacturer, e.g. "WD-40" or "Clorox bleach".
languageNoOptional output language. "es" adds the manufacturer's own Spanish SDS link when one was found and read, and the label elements in the official UN GHS Spanish wording. Default "en".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
+  "description": "Optional output language. \"es\" adds the manufacturer's own Spanish SDS link when one was found and read, and the label elements in the official UN GHS Spanish wording. Default \"en\".",
+  "enum": [
+    "en",
+    "es"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A3.7/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld/destructive, yet the description still adds real substance: a 5-match cap, the exact fields returned (product, manufacturer, manufacturer-hosted vs third-party PDF, printed revision date), and the deliberate 'reported as not found, never guessed' failure policy. It also discloses provenance rules for the Spanish link ('manufacturer's own ... never a machine translation') and the conditional label auto-fill, which an agent could not learn from structured fields.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a single run-on sentence with stacked parentheticals nested inside parentheticals, making the return-value and Spanish-language behavior hard to parse on first read. The same information would fit in half the words with bullet-like separation.

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 no output schema, the description does the necessary work of enumerating return fields and the not-found case, and it explains the language='es' behavior, so an agent can call it and interpret results. Minor gaps remain around match ranking and whether results are paginated beyond the 5-match cap.

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 coverage is 100%, so the schema already documents query, limit and the en/es enum, establishing a baseline of 3. The description adds only marginal meaning beyond it, chiefly 'never a machine translation' and the label-maker consequence of language='es'; limit and the query syntax are left entirely to the schema.

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?

States a specific verb+resource ('Find a safety data sheet (SDS)') and the two lookup axes (product name or manufacturer), plus the dual source (SDSentry's free search page plus its shared library). It does not differentiate itself from close siblings like find_safety_data_sheet or find_sds_for_inventory, so an agent must still guess which of the three lookup tools to pick.

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?

Usage is only implied: the agent can infer it is for looking up an SDS by product/manufacturer, and it learns the tool is read-only, free and no-signup. There is no explicit when-to-use statement, no exclusions, and no routing guidance relative to the sibling SDS lookup tools.

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

All SDSentry: Safety Data Sheet Lookup, GHS Pictograms & HazCom toolsInspect
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