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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'frozen vocabulary' and lists response components (effective date, rule-set version, source page), but it does not explicitly state that this is a read-only operation, how errors or not-found cases are handled, or any permissions/rate limits.

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 a single, compact sentence with no filler. It front-loads the core resource and then lists the key data returned. It is appropriately sized, though it sacrifices some instructive detail for brevity.

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 three required parameters, no schema descriptions, and no annotations, the description leaves the agent without enough context to correctly form a request. The output schema exists, so return format is covered, but parameter semantics and error behavior are absent, making the tool hard to invoke correctly on the first attempt.

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 0%, and the description adds no meaning beyond the parameter names. 'Substance', 'pathway', and 'jurisdiction' appear in the description but without any definition, valid formats, examples, or constraints. The 'frozen vocabulary' note appears to refer to the status values, not the input parameters.

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 resource: the status of a substance on one pathway in one jurisdiction. It is distinguishable from siblings like get_availability or get_price by the pathway/jurisdiction focus, but it does not explicitly name any alternatives or use a verb like 'retrieve', so it stops short of full differentiation.

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?

There is no guidance on when to use this tool versus alternatives such as get_substance_record or get_item, nor any mention of prerequisites or exclusions. The description only defines what the tool returns, leaving the selection criteria to the agent's inference.

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