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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious provenance: the data comes from word-by-word breakdowns of ~30,000 verses and reflects translator-assigned meanings rather than dictionary glosses — a critical caveat that shapes how results should be interpreted. It stops short of describing result ordering or limits beyond the examples cap.

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 tight paragraphs: the first front-loads the return payload, the second supplies the corpus-provenance caveat and usage triggers. No sentence is filler; each adds either scope or behavioral context.

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 compensates by naming the four result components (spellings, meanings, gloss counts, examples), and it explains the data's origin so an agent knows what to trust. Nothing needed to invoke the tool 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?

Schema description coverage is 100%, including script/IAST guidance, the examples default of 5, and the non-filter nature of the language enum, so the schema already carries parameter meaning. The description adds no parameter-level detail beyond framing the term concept, which is the correct baseline when the schema does the work.

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 (look up) and resource (Sanskrit word) and enumerates exactly what is returned: cross-script spellings, corpus meanings, verse gloss counts, and occurrence examples. It also draws a sharp boundary against a lexicon ('not a lexicon's list of everything it could mean'), so an agent can distinguish this from generic search or its own translation attempt.

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 clear positive triggers: 'Use it before translating a term yourself, and whenever the user asks what a word means.' That is actionable context lacking in most definitions, but it never names a sibling alternative (e.g., search_texts for non-Sanskrit scripts) inside the description, so exclusion guidance is left to the schema.

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