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

With no annotations, the description carries the behavioral burden itself. It signals a read-only lookup ('from the register') and specifies the scope of the result (eligibility and applicable standard). It does not mention edge cases, authorization requirements, error behavior, or explicitly state that no data is modified, but the get/from-the-register language makes a read-only interpretation reasonable.

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 one focused sentence that front-loads the core outcome and adds a useful enumeration of the relevant standards (503A/503B, provincial, magistral, Specials). There is no filler, and every phrase contributes meaning.

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 lookup, this description is minimally complete, especially given that an output schema exists to document return values. However, it lacks guidance on parameter value formats, relationships to sibling tools, and behavior for invalid or unknown inputs, which leaves an agent to infer important invocation details.

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 0%, so the description is the only source of parameter meaning. It does give both parameters clear semantic roles: a 'substance' that may be compounded and a 'jurisdiction' in which that determination is made. It stops short of providing accepted formats, examples, or constraints, so it only barely reaches an adequate level.

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 purpose: determining whether a substance may be lawfully compounded in a jurisdiction and which regulatory list or standard applies. It is specific and not easily confused with other substance-related tools, though it does not explicitly reference or differentiate from sibling tools.

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: call this tool when you need compounding eligibility for a substance in a given jurisdiction. However, there is no explicit when-to-use/when-not-to-use guidance, and no mention of alternatives such as get_substance_record or resolve_jurisdiction, leaving sibling selection to inference.

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