Peptlas: is this peptide legal?

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 safety profile needs no restating. The description earns credit for what annotations cannot convey: the shape of the answer (per-jurisdiction status with a plain-language note), the deeper U.S. payload (compounding rules, latest FDA advisory vote, next dated event), the inclusion of primary sources, and the last-verified date.

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 sentence, but it is front-loaded with the resource and scope before the jurisdiction list and return details. The list of eleven regulators plus example blends is long, yet each item is load-bearing for an agent deciding whether the jurisdiction it needs is covered.

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 and only annotations on the input side, the description carries the return-shape burden and does so: per-place status, plain-language notes, U.S. deep-dive fields, sources, and a verification date. It also flags a real coverage limitation ('Brazil, where covered'), which is exactly the kind of caveat an agent needs.

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%, so both parameters are already fully documented with examples and the omit-for-every-place convention. The description restates that same information ('or in the one place you name') without adding format, casing, or matching rules, so it sits at the high-coverage baseline rather than above it.

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 combination: the legal status of one peptide/GLP-1 drug/named blend, enumerated across seven named jurisdictions plus a caller-specified one. The explicit 'one peptide' scope also separates it from list_compounds, and the jurisdiction enumeration separates it from the narrower status_in_place.

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 a clear usage fork: name one place for a single-jurisdiction answer, or omit it for every place, which is genuine when-to-use guidance. It does not, however, name the alternatives (status_in_place, recent_changes) or state when a different sibling would be the better choice.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the shape of the payload (alias names, per-compound U.S. status, page link) and the fixed catalog size, which matters because there is no output schema.

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?

Two sentences, no filler, and the content inventory is front-loaded before the usage cue. Every clause carries information (catalog size, alias types, per-item fields, purpose).

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 and only one optional parameter, the description adequately covers what a caller gets back and why to call it. It falls short only in not stating the unfiltered default behavior or how it relates to the status-lookup siblings.

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?

There is a single optional us_status filter at 100% schema coverage with an enum, so the schema fully documents it. The description never mentions the filter or its semantics, adding nothing beyond the structured field — the baseline 3 for high schema coverage.

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 states a clear resource — a catalog of 26 compounds and 3 blends with aliases, U.S. status and page links — so an agent knows this enumerates the coverage universe. It does not explicitly name or contrast itself against the siblings (check_legal_status, recent_changes, status_in_place), so differentiation is only implied.

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 to see what is covered" gives a directional usage cue, but there is no when-not guidance and no mention of the alternative tools for looking up a single compound's status. Usage is implied rather than specified.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered externally. The description adds the ordering guarantee ('newest first') and the breadth of the feed, but says nothing about pagination behavior, result volume, or coverage windows — modest added value over the 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?

Two sentences, front-loaded with the resource and content, then the filter options. The parenthetical '(or a blend, meaning all its ingredients)' is slightly clunky but earns its place by clarifying a real ambiguity. 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?

With no output schema, the description does the work of describing the return content (dated regulatory event types, newest-first) which is what an agent needs. It omits how many results come back by default and what an empty feed means, but the essentials for correct invocation are present.

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 baseline is 3, and the description goes beyond it by explaining that passing a blend name returns events for all its ingredients and that filtering is optional/latest-first. That blend semantics is genuinely non-obvious and not inferable from 'Only this compound' in 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 concrete verb+resource ('Dated regulatory events from the Peptlas changelog') and enumerates the event types returned (advisory votes, list changes, comment deadlines, warning letters), so an agent knows exactly what comes back. It does not name or differentiate itself from the closely related siblings check_legal_status and status_in_place, which is the only thing keeping this below a 5.

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 trigger phrasings ('Use it for "what changed" or "any news on BPC-157"'), which maps user intent to this tool clearly. It stops short of exclusions or routing rules — nothing says when to prefer this over check_legal_status for a status question.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds that results carry a status and a note, and that the status filter is optional, but says nothing about result size, pagination, or behavior for unrecognized places. Modest added value on top of 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?

A single sentence that front-loads what is returned and follows with concrete example queries. No padding, though the phrase "in one place" is a slightly cutesy echo of the place parameter that costs a moment of parsing.

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 two-parameter, read-only lookup with no output schema, the description conveys the returned fields (status plus a note) and the filtering behavior, which is enough to invoke it correctly. It omits any indication of result volume or coverage limits of "tracked peptides", a minor 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 description coverage is 100% and the enum values are fully documented in the schema, so parameter semantics are already handled structurally. The description's "Optionally only one status" merely restates the optional status filter without adding syntax, defaults, or matching behavior. 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 states the resource returned (every tracked peptide with its status and a note) filtered by place, which tells an agent exactly what the call yields. It does not, however, differentiate itself from the sibling check_legal_status, which sounds like it could do the same thing. Clear purpose, missing sibling disambiguation.

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 explicitly gives use cases ("which peptides are legal in Australia", "what does WADA ban") and notes the optional single-status narrowing, which is genuine when-to-use guidance. It stops short of naming when NOT to use it or pointing at check_legal_status as the alternative.

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