Proposition 65

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

Annotations declare readOnlyHint and openWorldHint, and the description adds substantial behavioral detail: it returns every matching entry with specific fields (toxicity endpoint, mechanism, date listed, safe-harbour level, delisted status) and clarifies the meaning of not_found. This goes far beyond the structured annotations.

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?

Three sentences, front-loaded with the purpose, and every sentence carries necessary information. The important caveat about not_found is included without any waste.

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?

Even with an output schema present, the description thoroughly explains return-value semantics, including the list of fields, delisted entries, and the scope limitation ('this edition of this one list'). It covers all necessary context for a tool of this complexity.

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 schema already fully describes the single query parameter with examples ('A CAS number such as 71-43-2, or a chemical name such as Benzene'). The description repeats this but does not add new meaning, 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?

The description uses the specific verb 'look up' and clearly identifies the resource: a chemical on California's Proposition 65 list. It distinguishes itself from sibling tools like search_prop65 by focusing on a targeted lookup/report for a single chemical and enumerating the output fields.

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?

Explicitly states the intended use: 'Use this when deciding whether a product sold into California needs a warning label.' This provides clear context, but it does not mention when not to use it or mention alternative tools, so it stops 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.

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

The description discloses behavioral traits beyond the provided annotations: it specifies that it 'reports on the data only and cannot tell you whether any product requires a warning,' and it details the return contents ('counts of total, active and delisted entries...'). This adds context about limitations and scope that readOnlyHint and openWorldHint do not fully capture.

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 three sentences, each earning its place: purpose, usage, and output/limitations. It is front-loaded with the main action and uses no wasted words.

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 metadata tool with an output schema, the description is complete. It covers what the tool does, when to use it, what it returns, and its limitations. The sibling context is also clear from the description's differentiation.

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 input schema has 0 parameters, and baseline for 0 params is 4. The description does not need to explain parameters. It focuses on behavior and output, which is sufficient and appropriate.

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 clearly states the tool's function: 'Report the size and edition of the embedded Proposition 65 list, and what the listing-mechanism codes mean.' This is a specific verb and resource, and it distinguishes the tool from siblings like check_prop65 or search_prop65 which focus on individual entries.

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 description gives explicit use cases: 'Use this to check how current the data is before relying on a lookup, or to interpret the `AB`, `SQE`, `FR` and `LC` codes on an entry.' It also provides a when-not-to-use boundary: 'cannot tell you whether any product requires a warning.' However, it does not explicitly name alternative sibling tools, so it falls 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.

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

Even with readOnlyHint=true, the description adds valuable behavioral details: returns active listings only, orders newest first, includes dates, and reports how many entries lack parseable dates and are excluded. This goes well beyond annotations and gives a clear picture of 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.

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

The description is three sentences, front-loaded with the core action, and each sentence serves a distinct purpose: usage, rationale, output behavior, and a limitation. No wasted words.

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?

Given the simple single-parameter schema, rich annotations, and presence of an output schema, the description covers usage context, output specifics, and caveats (missing dates, product-inapplicability). It is fully sufficient for an agent to select and invoke correctly.

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 schema already provides 100% coverage for the 'since' parameter, including type, range, and context. The description only paraphrases 'on or after a given year' without adding new parameter-level semantics, so the baseline of 3 is appropriate.

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 clearly states the tool lists chemicals added to Proposition 65 on or after a given year, with a specific verb+resource+scope. It distinguishes itself by emphasizing 'recent additions' and 'active listings only,' which separates it from sibling tools like search_prop65.

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 description explicitly says to use this for finding recent additions and explains the compliance-clock relevance. It notes what it does not do ('does not tell you whether any particular product is affected'), though it doesn't name an alternative tool for product-specific queries, so it falls slightly short of full alternative guidance.

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

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

The description goes well beyond the readOnlyHint by disclosing the name-only search behavior, the synonym limitation, the `truncated` flag behavior, and the returned fields (CAS, toxicity endpoints, listing dates, delisted flags). It even notes that a result is not a determination that a warning is required. This is rich behavioral context with no contradiction to annotations.

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 three sentences, front-loaded with the core action, then usage context, then limitations and return behavior. Every sentence adds value without redundancy, making it appropriately sized and well-structured.

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 simple two-parameter search tool with an output schema and strong annotations, the description covers use cases, constraints, and result interpretation. It mentions the truncated flag and the non-determinative nature of the result, which is essential for agents to set expectations.

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 input schema already documents both parameters with descriptions (term as a fragment, limit as max results), so baseline is 3. However, the description adds the important behavioral detail that results are capped and `truncated` is set when there are more matches, which clarifies the effect of the limit parameter beyond the schema's wording.

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 opens with a specific verb and resource: 'Search the Proposition 65 list for chemicals whose name contains a fragment.' It clearly distinguishes from siblings like check_prop65 (exact lookup) and list_recent_listings by emphasizing partial-name matching and family surveys.

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 description explicitly states when to use the tool: 'Use this when you do not have an exact name or a CAS number, or to survey a family of related substances.' It also gives a clear exclusion: the tool searches names only and will miss synonyms, implying that other tools are better for exact or synonym-based queries.

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