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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: the catalogue's inclusion/exclusion scope, that the connection cannot take orders or payments, and the rule that exclusions are explained rather than probed with empty searches. Most of this policy concerns sibling tools, but it is real context an agent would not get from 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?

Roughly a dozen sentences of catalogue policy precede the one sentence that defines the tool, so the purpose is back-loaded and an agent skimming the first line would misidentify it as a scope statement. Large portions (offer pricing, delivery_text, claim-source evidence) belong to get_beverage and get_claim, not here.

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 no annotation detail about the response, the description should say what the ontology payload contains (entity types, relationship types, semantic scales) and how to use it — it lists these terms only in the final clause without explaining their structure or how an agent should consult them when interpreting other tools' results.

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 single 'format' parameter (enum json | json-schema) has 0% schema description coverage, so the description must compensate — and it says nothing about the parameter or what the two formats return. The agent is left to guess what json-schema output means in this context.

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 actual function is only stated in the final sentence: 'Retrieve the Beyond Wine ontology, entity types, relationship types, and semantic scales.' Everything before it describes the catalogue's domain scope and refusal policy rather than what the tool does. There is no differentiation from siblings like get_graph or get_context, so an agent cannot tell from this text which tool yields the ontology versus the graph.

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 is full of when-to-refuse guidance, but almost none of it tells an agent when to call get_ontology versus get_graph, get_context, or list_entities. The one relevant implication is that ontology knowledge underpins valid entity/relationship types, but that is never stated as invocation guidance.

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