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

Annotations only supply destructiveHint=true, so the description carries most of the burden and does well: it discloses that writing triggers an acknowledgment mailing unless ack_template_name is set to 'do_not_ack' — an important side effect not encoded anywhere structured — plus the underlying POST endpoint. It does not state what happens on duplicate external_id or whether the call is idempotent.

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?

Five dense sentences with the operation type front-loaded as a 'WRITE:' marker, zero filler, and each sentence carrying a distinct piece of usable information (scope, negative constraint, required field, id/name duality, opt-out sentinel).

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 26-parameter mutation with no output schema, the description covers the critical decisions: what it writes, what it does not do, the required identifier, the id-vs-name convention, and the acknowledgment side effect. It omits error/duplicate behavior and does not confirm whether the created gift's id is returned, which an agent would want before chaining calls.

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 only 58% across 26 params, so added meaning matters. The description clarifies the non-obvious pairing semantics (fund, campaign, appeal, event, gift category and payment type may each be supplied by id OR exact name), flags gift_type_id/name as required, and explains the ack_template_name sentinel — all information the schema does not convey.

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?

Opens with an explicit 'WRITE: record a gift' verb+resource and enumerates the gift kinds (donation, pledge payment, in-kind), which immediately distinguishes it from the read-side siblings lgl_get_gift, lgl_list_constituent_gifts and lgl_search_gifts. The negative clarifier ('does NOT charge a card or move money') further sharpens what kind of record is being written.

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 a clear when-to-use boundary — recording an already-completed gift rather than processing a payment — and points to lgl_list_type_values with type=gift_types to obtain the required gift type. It stops short of naming an alternative tool for the cases it excludes (e.g., where to go to actually charge a card), so it is strong but not fully exhaustive.

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