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

Annotations only declare readOnlyHint=true, and the description adds real behavioral context: results are restricted to 'active' constituents, at least one search term is mandatory, and the underlying call is GET /api/v1/constituents/search. It does not describe the return shape or pagination semantics, but the term-scoping behavior is well disclosed.

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?

Front-loads purpose, then the common-case params, then the required term-field catalog, and ends with the API reference. Dense but every clause earns its place given the schema's reliance on the description; only minor tightness is lost in the long field enumeration.

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 many-field search tool with no output schema and only a readOnly hint, the definition is largely self-sufficient, covering term fields, formats, and the mandatory-term rule. It stops short of explaining the result envelope or how name/email/terms combine, which would fully close the gap.

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 100%, but the schema for `terms` explicitly defers to the description ('See the tool description for the available fields'). The description delivers exactly that authoritative field list with formats, operators, and value mappings (membership_status 0/1, constituent_type 0/1, date patterns), which the schema cannot supply on its own.

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 and resource ('Search active constituents') plus the scope ('active') and concrete examples of what a constituent is (donors, members, volunteers, organizations). The plural/search framing distinguishes it cleanly from the single-record lgl_get_constituent sibling.

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?

Offers invocation guidance ('Give name and/or email for the common case, or raw terms') and an operational constraint ('At least one term is required'), which implies usage. However, it never names an alternative tool or states when-not-to-use it (e.g., vs. lgl_get_constituent or the list_* siblings), so guidance stays implicit.

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