SDS lookup, GHS pictograms, HazCom dates; customers: list my chemicals, sheets due, PPE, hazards.
Scored across 10 tools
Two pairs overlap meaningfully: find_safety_data_sheet vs search_sds (both free product-name lookups returning SDS links, pictograms and label-maker links) and check_hazcom_readiness vs hazcom_2024_deadlines (both about OSHA's 2024 HazCom dates). The descriptions do differentiate them (single best match vs up to 5 matches; readiness program vs raw dates), but an agent can plausibly pick the wrong one for a simple 'find the SDS for X' or 'what are the HazCom dates' request.
All names are snake_case and readable, with no case mixing. The construction varies between verb-first (find_safety_data_sheet, list_my_chemicals, check_hazcom_readiness) and noun-phrase (ghs_pictogram, ppe_for_chemical, sheets_due_for_review), which is a minor deviation but still predictable.
Ten tools is well within the ideal band and each has a clear job: lookup (single/batch/search), reference (pictograms, deadlines), compliance readiness, and per-account inventory reads. No filler tools are present.
Coverage of lookup, GHS reference, HazCom compliance and account inventory reads is solid, including batch inventory lookup and review-reminder listing. Gaps exist on the write side: there is no way to add a chemical to the inventory, mark a sheet reviewed (a dead end implied by sheets_due_for_review), or retrieve SDS sections beyond 2 and 8.
Explains the OSHA Hazard Communication (HazCom) 2024 update employer dates (employers update as necessary by 20 Nov 2026 for substances and by 19 May 2028 for mixtures) and what a facility that stores chemicals needs in place (current safety data sheets, GHS container labels, a written program, and documented employee training), then points to a free, no-signup readiness self-audit. Does NOT invent fines, statistics, or legal conclusions. Use it when someone asks what their business needs under OSHA HazCom or how to prepare for those dates.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | Optional: the kind of facility (e.g. "auto repair shop"), used only to tailor the wording. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: the response content (dates, required controls, pointer to a free no-signup self-audit) and an explicit honesty constraint ("Does NOT invent fines, statistics, or legal conclusions"), which is a meaningful guardrail. It does not describe the format or depth of the audit pointer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The compliance dates and required controls are front-loaded in the first sentence, with usage guidance last, so an agent can extract the essentials quickly. The single dense sentence carries a lot of parenthetical detail but almost every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns, and it does so by naming the three deliverable pieces (dates, required controls, self-audit pointer). The only gap is that it does not say what form the self-audit pointer takes or how exhaustive the requirements list is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one optional parameter, so the schema fully documents "industry" including its tailoring-only purpose. The description does not reference the parameter at all, so it adds nothing beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-and-resource framing: it explains the OSHA HazCom 2024 employer compliance dates and the controls a facility needs, then points to a self-audit. That is clearly more than a restated name. It never explicitly distinguishes itself from the sibling hazcom_2024_deadlines, though the added requirements/audit scope implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when someone asks what their business needs under OSHA HazCom or how to prepare for those dates" gives a concrete trigger condition. There is no explicit when-not or routing to hazcom_2024_deadlines for date-only questions, so the overlap with that sibling is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the safety data sheet (SDS/MSDS) for a workplace chemical or product by name. Returns the product name, manufacturer, CAS number(s), EPA registration where applicable, a link to the actual SDS PDF, whether that PDF is manufacturer-hosted or a third-party copy, the revision date printed on it, the signal word and GHS pictograms when they could be read from the sheet, and a confidence level. For a sheet it finds it also returns two links: SDSentry's free, no-signup printable GHS secondary-container label maker for that product (it fills the label from the sheet when the sheet's Section 1 is confirmed and its label elements were read; otherwise the hazard classes are ticked by hand), useful when someone needs to label a spray bottle, jug or other workplace container; and the public result page showing the host and revision date, plus the pictograms and Section 1 check when the sheet has been read. If the product cannot be identified reliably it says so plainly rather than guessing — a wrong SDS is worse than none. With language "es" it also returns the manufacturer's own Spanish SDS link when SDSentry has found and read one (its Spanish Section 1 names the same product and maker; never a machine translation), says plainly when none was found or the sheet has not been checked yet, and gives the label's signal word, pictogram names and hazard statements in the official UN GHS Spanish wording for each code, with the label link pointing at the Spanish label maker. Free, no signup. Use it when someone needs hazard or handling information, or the SDS, for a chemical they keep on site.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | The chemical or product name to look up (at least 2 characters). | |
| language | No | 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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, so the safety profile is covered; beyond that the description adds genuine behavior: a confidence level, an explicit refusal to guess when the product can't be identified, disclosure of whether the linked PDF is manufacturer-hosted or a third-party copy, and what happens with language=es (never a machine translation, says plainly when none found or unchecked). That is substantive context an agent could not infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One enormous run-on paragraph of roughly 250 words, with several very long sentences whose clauses nest (the label-maker sentence alone carries multiple parenthetical conditionals). The core purpose is front-loaded, but the label-maker and result-page plumbing occupy far more space than an agent needs to select and call the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does it thoroughly: field list, link types, confidence level, and the failure mode of not guessing. Complete enough to call correctly; only the sibling-selection guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented; the description nonetheless adds meaning to language=es by spelling out the concrete consequences (manufacturer's own Spanish SDS link, official UN GHS Spanish wording for signal word, pictogram names and hazard statements, Spanish label link). The product parameter gets no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: look up an SDS/MSDS for a workplace chemical or product by name, and enumerates what comes back (product name, manufacturer, CAS, EPA reg, PDF link, revision date, signal word, pictograms, confidence). It never names or distinguishes itself from the obvious siblings search_sds and find_sds_for_inventory, so an agent cannot tell from the text which lookup to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence gives a use case (hazard or handling information, or the SDS, for a chemical kept on site) and the language branch hints at a second use, but there are no exclusions and no named alternatives despite two near-identical siblings. Usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the safety data sheet (SDS) for a LIST of workplace chemicals or products at once, e.g. the product-name column of a chemical inventory spreadsheet. Returns one row per product: whether a manufacturer-hosted SDS PDF was found (a third-party copy is marked as such), the manufacturer, the revision date printed on the sheet, and the PDF link, using the same rules as find_safety_data_sheet (an unidentifiable product is reported as not found, never guessed). Up to 10 products per call; call again for the rest (items still being searched at the call's time limit are listed as not looked up yet, to send again). For up to 5 products with a manufacturer-hosted SDS it also lists a free, no-signup printable GHS secondary-container label link. With language "es" each row also carries the manufacturer's own Spanish SDS link when one was found and read (or says none was found / not checked yet), and the label links open the Spanish label maker. Free, no signup. Use it when someone has several chemicals or an SDS binder/inventory to fill in.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 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". | |
| products | Yes | Chemical or product names, one per item (max 10 per call; extra items are listed as not looked up). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, yet the description still adds substantial non-obvious behavior: third-party copies are marked as such, unidentifiable products are reported as not found and never guessed, partial results from the time limit are flagged 'not looked up yet' and can be resent, and label links cap at 5. These are exactly the runtime traits an agent cannot infer 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and most sentences carry real information, but the body is a dense run-on of stacked parentheticals about third-party copies, time limits, label caps, and Spanish variants, which hurts scannability. It could be broken into shorter clauses without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-shape burden itself — and it does: one row per product with found/not-found status, third-party flag, manufacturer, revision date, PDF link, plus the optional label link and Spanish-specific fields. Batch limits and partial-result handling are also covered, leaving nothing critical unstated for a 2-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum for language is documented, so the baseline is 3. The description goes slightly beyond the schema by explaining what 'es' actually changes downstream (Spanish label links open the Spanish label maker, per-row Spanish SDS link or 'not checked yet'), which helps an agent anticipate the output difference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (look up SDS for a LIST of products) and immediately frames the batch scope with a concrete example (product-name column of a spreadsheet). It explicitly ties itself to the singular sibling by saying it uses 'the same rules as find_safety_data_sheet', so an agent can distinguish batch from single lookup without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Closes with a clear usage trigger: 'Use it when someone has several chemicals or an SDS binder/inventory to fill in,' and gives operational guidance on chunking (up to 10 per call, call again for the rest). It implies but never explicitly states the inverse case (one product → use the singular tool), so exclusions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a GHS pictogram code (GHS01 to GHS09) or its name (for example "flame over circle", "skull and crossbones"), returns what it means, the hazard classes it covers as listed on OSHA's pictogram QuickCard (OSHA 3491, 2024), whether OSHA's Hazard Communication Standard requires it, and SDSentry's guide page for it. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
| pictogram | Yes | GHS code (GHS01-GHS09) or pictogram name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the 'Read-only, free' clause mostly restates them (though 'free' is new). The description earns credit for disclosing provenance and currency of the data (OSHA QuickCard 3491, 2024) and that a guide page link is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that opens with the input contract before listing outputs. It is dense but every clause (input forms, returned fields, data source) carries information; only the trailing 'Read-only, free' is close to redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup with no output schema, the description fully enumerates what comes back: meaning, hazard classes, OSHA HCS requirement, and a guide page. It omits behavior for unrecognized or ambiguous pictogram input, which is the only notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single parameter with examples, so the baseline is 3. The description adds only the explicit GHS01-GHS09 range and a couple of name-form examples, which is marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: given a GHS pictogram code or name, returns its meaning. The scope is unambiguous and clearly distinct from the SDS-search siblings, which deal with documents rather than pictogram semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Makes the triggering context clear (you have a pictogram code GHS01-GHS09 or a colloquial name and want its meaning), and enumerates accepted input forms. It stops short of naming when to use a sibling tool instead or what to do if the pictogram isn't valid, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the hazards printed in Section 2 of the SDS on file for a product in your own SDSentry inventory: signal word, hazard statements (H-code and wording), GHS pictograms (only when confirmed from the sheet) and precautionary statement codes, with a link to the sheet. When Section 2 cannot be read, the answer says to see SDS Section 2. Needs a personal SDSentry access token (created by the account owner in SDSentry, Admin, AI assistants) and an account on a free trial or a paid plan. Read-only; reads only that account's data.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product name as it appears in your SDSentry inventory, e.g. "Acetone". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already declare read-only, idempotent, non-destructive, closed-world), the description discloses auth and plan requirements, the data boundary ('reads only that account's data'), a data-honesty rule (pictograms only when confirmed from the sheet), and graceful degradation behavior when Section 2 is unreadable. That is exactly the kind of operational context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The return contents are front-loaded in one dense but well-ordered sentence, followed by the fallback case and then requirements. Slightly long and clause-heavy, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values and does so explicitly, plus covers auth, plan gating and the partial-data fallback. Nothing material an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the baseline is 3; the description adds a genuine constraint by requiring the name to match the caller's own SDSentry inventory rather than an arbitrary product string. It does not, however, describe matching behavior (exact vs. fuzzy name) when a name is ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Return the hazards printed in Section 2 of the SDS on file' — and enumerates exactly what is returned (signal word, H-codes, pictograms, precautionary codes, link). It is clearly narrower than siblings like ghs_pictogram or ppe_for_chemical, but it never names an alternative to reinforce that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It scopes usage to 'a product in your own SDSentry inventory' and states prerequisites (personal access token, trial or paid plan), which is useful context. However, it gives no explicit when-to-use/when-not guidance relative to the overlapping siblings (ghs_pictogram, ppe_for_chemical, find_sds_for_inventory), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the compliance dates of OSHA's 2024 Hazard Communication Standard update (29 CFR 1910.1200) as extended by 91 FR 1695 (January 15, 2026): for chemical manufacturers/importers/distributors and for employers, for substances and for mixtures, with days remaining. Notes that OSHA State Plans may set different dates. Read-only, free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful context beyond annotations with the legal extension citation, covered roles, days-remaining return content, and State Plan caveat, though 'free' is minor repetition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core return value and legal basis, then adds the State Plan caveat and access notes. Every clause contributes useful information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational lookup with no output schema, the description sufficiently explains what is returned, for whom, under what legal extension, and with the State Plan caveat. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so parameter semantics are trivially satisfied. The description adds no parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns OSHA HazCom 2024 compliance dates under 29 CFR 1910.1200 as extended by 91 FR 1695. It clearly scopes the content to manufacturers/importers/distributors and employers, substances and mixtures, but does not explicitly distinguish itself from the sibling check_hazcom_readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the stated return value (compliance dates with days remaining), and the State Plan caveat helps set expectations. However, it gives no explicit when-to-use guidance or comparison with siblings such as check_hazcom_readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the chemicals in your own SDSentry inventory: product, manufacturer, location, storage spot, whether an SDS is on file, the revision date recorded for the sheet, and a link to each sheet. Optional "location" narrows the list to locations whose name contains that text. Needs a personal SDSentry access token (created by the account owner in SDSentry, Admin, AI assistants) and an account on a free trial or a paid plan. Read-only; reads only that account's data.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Optional: part of a location name in your account, e.g. "Main clinic". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered by structured data. The description adds genuinely non-schema information: it requires a personal SDSentry access token created by the account owner under Admin > AI assistants, requires a free-trial or paid plan, and reads only that account's data. It does not mention result size limits or pagination, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph that front-loads the returned fields, then the filter, then the access and plan prerequisites. Every clause carries information an agent needs; nothing is restated from the title or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only listing tool with no output schema, the description compensates well by enumerating returned fields and stating auth and plan prerequisites. The only omission is behavior for large inventories, such as pagination or caps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents the single "location" parameter as a partial location name with an example. The description repeats the contains-text matching idea ("locations whose name contains that text") but adds no case-sensitivity, multi-word, or empty-string behavior beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List the chemicals in your own SDSentry inventory") and enumerates exactly what each row contains: product, manufacturer, location, storage spot, SDS status, revision date, and sheet link. It also implicitly separates itself from the find_*/search_sds siblings by framing this as an unfiltered listing of the caller's own inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for use: it lists your own account's inventory, with the optional "location" argument described as a narrowing filter. It never explicitly names find_sds_for_inventory or search_sds as the alternative when you don't want to enumerate everything, so the when-not-to-use guidance is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the personal protective equipment and exposure-control lines printed in Section 8 of the SDS on file for a product in your own SDSentry inventory (eye/face, hand, skin and body, respiratory, engineering controls, hygiene), copied as printed, with a link to the sheet. When Section 8 cannot be read, the answer says to see SDS Section 8; nothing is inferred from the product name. Products you do not hold are not looked up here (use find_safety_data_sheet). Needs a personal SDSentry access token (created by the account owner in SDSentry, Admin, AI assistants) and an account on a free trial or a paid plan. Read-only; reads only that account's data.
| Name | Required | Description | Default |
|---|---|---|---|
| product | Yes | Product name as it appears in your SDSentry inventory, e.g. "Acetone". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description is not needed for the safety profile. It nonetheless contributes beyond them: the authentication token and its creation path, the plan eligibility gate, per-account data scoping, the no-inference rule from product name, and the degraded answer when Section 8 can't be read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what is returned and the source location, then prerequisites and exclusions, which is the right order. A few clauses are arguably redundant with annotations, notably the closing 'Read-only; reads only that account's data', which repeats readOnlyHint and the earlier inventory scoping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description covers the return shape: the lines copied as printed plus a link to the sheet, along with the degraded answer text. For a one-parameter read tool with full annotation coverage, nothing the agent needs to invoke or interpret it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already carries an example, so the baseline is 3. The description adds real meaning by constraining the value to a name in the caller's own SDSentry inventory and warning that nothing is inferred from the product name, which tells the agent exact-match entry matters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: returns the PPE and exposure-control lines from Section 8 of the SDS on file, enumerating the sub-sections (eye/face, hand, skin and body, respiratory, engineering controls, hygiene). It also scopes itself to the caller's own inventory and names the sibling (find_safety_data_sheet) that handles everything else, so an agent can pick between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing ('Products you do not hold are not looked up here (use find_safety_data_sheet)') plus the prerequisite conditions: a personal SDSentry access token created by the account owner, and a free-trial or paid plan. It even states the fallback behavior when Section 8 is unreadable, which is when-not guidance in practice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return (default 5). | |
| query | Yes | Product name and/or manufacturer, e.g. "WD-40" or "Clorox bleach". | |
| language | No | 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". |
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.
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.
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.
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.
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.
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.
List the safety data sheets in your own SDSentry inventory that need attention, each with a link: sheets whose file changed at their SDS link since the copy on record, sheets not marked reviewed in the last 365 days (SDSentry's review reminder interval), sheets whose text may not name the product, and products with no SDS on file. Needs a personal SDSentry access token (created by the account owner in SDSentry, Admin, AI assistants) and an account on a free trial or a paid plan. Read-only; reads only that account's data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely non-derivable context: a personal access token created by the account owner, a free-trial-or-paid plan requirement, and that only that account's data is read — plus the 365-day reminder interval that defines one of the categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and the four qualifying conditions are front-loaded in the first sentence, with auth and plan prerequisites trailing. The enumeration is long but each item earns its place as a distinct trigger; the sentence is dense enough to require a careful read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the definition covers what is returned (each item carries a link), who may call it (token and plan), and the scope of data. Pagination and response volume for large inventories are left unstated, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. It correctly avoids inventing filter options that the empty schema does not support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (safety data sheets in the caller's own SDSentry inventory) and enumerates the four exact conditions that qualify a sheet, which goes well beyond restating the title. It never names a sibling tool, so an agent must infer the boundary against find_sds_for_inventory or check_hazcom_readiness on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The enumerated triggers (file changed, not reviewed in 365 days, text missing product name, no SDS on file) make the intended use clear in context, and the phrase 'your own inventory' scopes it. There is no explicit when-not guidance and no routing to alternatives among the nine sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
hazards_for_chemicallist_my_chemicalsppe_for_chemicalsheets_due_for_reviewfind_safety_data_sheet1 field changedInput schema / properties / languageAdded 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"
+}find_sds_for_inventory1 field changedInput schema / properties / languageAdded 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"
+}search_sds1 field changedInput schema / properties / languageAdded 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"
+}ghs_pictogramhazcom_2024_deadlinessearch_sdsfind_sds_for_inventorycheck_hazcom_readinessfind_safety_data_sheetConstruction safety, training compliance and operations for your company (OAuth sign-in).
Search customers, manage quotes, work orders, action items, and calendar events for your business
Read Safefood 360 documents, complaints, suppliers, materials; create complaints, update documents.
Read SafetyChain food safety records, CAPAs, forms, suppliers, items, locations and equipment.
Add one secure layer between your agents and this server.
