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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing the safety profile. The description adds value beyond these by stating the data source (EMBL-EBI ChEMBL), licensing (CC BY-SA 3.0), and that no authentication is required. It also promises 'full' data, which implies comprehensive coverage. These additions are useful for an agent deciding to invoke the tool. There is no contradiction with 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 moderately long due to the enumerated return fields, but it is front-loaded with the core purpose and then lists specific data items. Each sentence earns its place: purpose, return list, usage hint, and source/licensing. It is not overly verbose for the amount of detail provided, and the structure is logical. It could be slightly tighter by grouping fields, but it remains efficient.

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 that an output schema exists, the description does not need to explain return values in detail, but it still lists the key fields, which is helpful. It covers usage prerequisites (ID discovery via search), authentication (none), and data source. For a simple single-parameter lookup tool, the description is complete. Nothing essential for an agent to call it correctly is missing.

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 provides a detailed description for chembl_id with examples. The description reinforces this by giving explicit example IDs (CHEMBL25, CHEMBL521) and directing the agent to the search tool for ID discovery. This adds context beyond the schema's generic 'ChEMBL molecule identifier' note. Given 100% schema coverage, the description's contribution is supplementary but genuinely helpful.

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 retrieves full structural and pharmacological data for a specific ChEMBL molecule, enumerating the specific fields returned. This distinguishes it from sibling tools like chembl.molecules.search, which is explicitly referenced for ID discovery, and other chemistry detail tools. The verb 'Retrieve' plus the resource 'specific ChEMBL molecule' makes the purpose unambiguous.

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 instructs to use chembl.molecules.search to discover ChEMBL IDs and provides the ID format (e.g., CHEMBL25). It also notes that no auth is required, which is a usage consideration. While it does not explicitly state when not to use the tool, the tool's narrow scope (single molecule by ID) makes the usage context clear. It could be improved by mentioning that it is for individual molecule lookups rather than batch queries, but the guidance is adequate.

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