little-green-light

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

Only destructiveHint=true is provided, so the description usefully labels the operation as a WRITE and gives the underlying endpoint (POST /api/v1/constituents). However it says nothing about permissions/auth, whether a duplicate is rejected or silently created, or what the call returns after the write — the gaps an agent most needs when annotations alone only say 'destructive'.

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?

Three short, front-loaded sentences: write nature first, optional payloads second, duplicate-avoidance and endpoint last. Every sentence earns its place except the inaccurate required-fields claim, which occupies space while misleading.

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 25-parameter mutation tool with no output schema, the definition covers purpose, optional sub-resources and duplicate avoidance, but leaves out the response shape (e.g. whether the new constituent id is returned for follow-up calls), permission requirements, and duplicate-handling behavior. Adequate but with clear gaps for a tool of this complexity.

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 64%, so the description does add value by summarizing that email addresses, phones, addresses and group memberships are optional attachments. But it also asserts that 'LGL's schema marks first_name, last_name and email_addresses as required', and the schema requires only first_name and last_name — a misleading statement that could push the agent into supplying email_addresses unnecessarily. That inaccuracy keeps this below a 4.

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 a specific verb+resource ('WRITE: add a new constituent (person or organization) to the account') and enumerates the sub-resources it can carry. It is clearly distinguishable from lgl_update_constituent, lgl_get_constituent and lgl_search_constituents without opening any schema.

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?

Explicitly names the alternative (lgl_search_constituents) and the condition that selects it ('Search first ... to avoid creating a duplicate'), which is the primary risk in a create tool. Nothing about when to reach for search versus create is left to inference.

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

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

The 'WRITE:' prefix and the disclosed endpoint (POST /api/v1/constituents/{id}/contact_reports) go beyond the destructiveHint annotation by telling the agent this is a mutating create scoped to a constituent. It does not mention permissions or rate limits, but the mutation semantics are clear and consistent 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?

A compact two-part description: the operation and its field guidance first, then the raw endpoint. Every clause carries information, though the trailing URL could be dropped without much loss.

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 mutation tool with no output schema, the description covers the required fields, the type-resolution path, and the underlying request, which is enough to call it correctly. Return behavior and permissions are the only omissions, and neither is essential here.

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 already 86%, so the baseline is 3; the description adds that text is mandatory and that the report type may be passed as either id or name, plus how to look up valid names. That is meaningful guidance layered on top of the schema.

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 ('log a contact report') and defines the concept inline ('a call, email or meeting with a constituent'), which disambiguates it from the adjacent lgl_create_note sibling. An agent can tell what this creates without opening the schema.

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 operative context: text is required, the type may be supplied by id or name, and it routes the agent to lgl_list_type_values with type=contact_report_types for valid values. It does not state when to prefer a contact report over a note, but the context is otherwise actionable.

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

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

With destructiveHint=true already given, the description adds real context: it is a CRM write, not a money movement, and it explains the id-or-exact-name resolution rule and the 'do_not_ack' sentinel. It does not contradict the annotation (this is a write) and goes beyond it usefully, though return/permission behavior is unstated.

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?

Dense but front-loaded with the WRITE: action and the core caveat, followed by required-parameter and resolution guidance in tight sentences. Every sentence earns its place, though the packed run-on list of id/name fields is slightly heavy to parse.

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 essential calling semantics (required type, id/name duality, ack opt-out). It omits auth expectations and any return confirmation, leaving a small but non-critical 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 58%, so the description carries weight: it documents the id-or-exact-name pattern shared by fund/campaign/appeal/event/category/payment type, and notably declares gift_type_id/name required even though the schema required-list shows only constituent_id. This adds genuine meaning beyond the schema.

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 (record/write) and resource (a gift on a constituent's record), and disambiguates from payment tools by clarifying it 'does NOT charge a card or move money.' An agent can distinguish this from lgl_create_constituent and lgl_get_gift without opening either schema.

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?

Clearly frames the context: it records a gift that already happened rather than processing a payment, and points to lgl_list_type_values (type=gift_types) for the required type lookup. It does not, however, name alternatives for updating or retrieving gifts, so the routing is implied rather than exhaustive.

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

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

Annotations only expose destructiveHint=true, so the description carries most of the burden. It usefully signals the write nature and the POST endpoint, but it does not state whether notes can later be modified or removed, whether external_id changes idempotency/dedup behavior, or any permission requirements.

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 the WRITE marker and requirement facts in one dense sentence, then closes with the endpoint. No filler text, though the raw endpoint path is marginal value for an agent.

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 6-parameter mutation tool with no output schema and thin annotations, the description covers required fields and type resolution but omits the purpose of external_id and the behavioral/safety details of creating a note. Adequate to invoke correctly, but not fully complete.

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 67%, and the description compensates by confirming text and original_date as required and clarifying the id-vs-name duality for note type, which is the main ambiguity in the schema (note_type_id vs note_type_name). It leaves external_id unexplained, but adds real meaning beyond the schema for the key parameters.

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?

Starts with an explicit operation marker ('WRITE: add a note to a constituent's record'), naming both the verb and the target resource. It is clearly distinguishable from siblings such as lgl_list_constituent_notes and lgl_update_constituent, and it even names the underlying endpoint.

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?

Explains the note-type resolution path (by id or name, e.g. 'General') and routes the agent to lgl_list_type_values with type=note_types for valid values. It gives clear context for how to supply types but does not state when to prefer this tool over listing/updating notes.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description goes beyond the annotation by disclosing the breadth of returned data (groups, memberships, custom attributes), which is meaningful context for a read whose return shape is not defined by an output schema. No auth or rate-limit detail, but the entity scope is well conveyed.

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?

A single dense sentence that front-loads the action and resource, then lists the returned fields, followed by the API endpoint reference. No padding or redundancy; every clause earns its place.

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 simple one-arg read with annotations covering the safety profile and no output schema, the description supplies enough: what it fetches, by what key, and what data comes back. Missing only explicit guidance on sourcing the id (e.g., via search) and error behavior for an unknown id.

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% and the single 'id' parameter is documented as an integer constituent id in the schema. The description's 'by LGL id' matches the schema without adding format, source, or lookup details beyond it, so baseline 3 is appropriate.

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 ('Full details for one constituent by LGL id') and enumerates the returned entity scope (names, salutations, addresses, phones, emails, groups, memberships, custom attributes). This clearly contrasts with the sibling search_constituents by implying a single-record lookup, though it never names that sibling explicitly.

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?

Usage is implied by 'one constituent by LGL id' – the agent infers this is a single-record fetch rather than a bulk or search operation. However, there is no explicit when-to-use guidance, no note that the id must first be obtained via search_constituents, and no exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing what comes back (amount, deductible amount, dates, fund/campaign/appeal/event, payment type, acknowledgment template, tribute and custom fields) — meaningful for a tool with no output schema — though it omits any note on auth, rate limits, or behavior for a missing id.

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?

One front-loaded sentence leading with the retrieval intent, plus a compact endpoint reference. The middle field enumeration is dense but each item earns its place by compensating for the absent output schema.

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 one-parameter read tool with annotations covering safety and no output schema, the description supplies the return-field inventory an agent needs and the endpoint mapping. Only the lack of error/not-found behavior keeps it from being fully complete.

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% and the sole parameter's type and constraint are fully documented in the schema. The description only restates 'by id' without adding format or validity details beyond that, so the baseline 3 applies.

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 ('Full details for one gift by id') and enumerates the returned fields, which cleanly separates it from the list-oriented siblings lgl_list_constituent_gifts and lgl_search_gifts. The API endpoint mapping reinforces the single-resource scope.

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 phrase 'by id' implies the caller must already have a gift id, which is useful implicit guidance. However, it names no alternatives and does not say when to prefer this over lgl_search_gifts or lgl_list_constituent_gifts, leaving the routing decision to inference.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the backend mapping (GET /api/v1/appeals), confirming a read operation and no contradiction. It says nothing about pagination behavior or result volume, which would have added real value beyond 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?

Two compact sentences plus the endpoint reference; the resource definition is front-loaded and nothing is redundant. Slightly dense in the field listing, but no wasted text.

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 zero-required-parameter read-only list endpoint with no output schema, the description covers the entity, its attributes and the endpoint. Missing only return-format/pagination shape, which for a simple list tool is a minor 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%, and both limit and offset carry full descriptions including defaults and next_item guidance, so the schema does the heavy lifting and a baseline 3 applies. The description adds no pagination syntax or semantics of 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?

The title supplies the verb ('List') and the description defines the resource richly — fundraising appeals are mailings, emails and asks, with campaign, date, goal, cost and active flag. It does not, however, distinguish itself from siblings like lgl_list_campaigns or lgl_list_funds, which an agent could confuse since 'campaign' appears as a property here.

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 sentence 'Use the ids and names when recording gifts or filtering searches' gives downstream usage context, implying the results feed lgl_create_gift and search filters. It stops short of stating when to call this versus lgl_list_campaigns or other list endpoints, so usage is only implied.

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

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

readOnlyHint=true already establishes it as a safe read, and the description adds genuine value by enumerating the fields the records contain plus the underlying endpoint (GET /api/v1/campaigns). It says nothing about pagination behavior or typical result volume, but the return-content disclosure is meaningful given there is no output schema.

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 compact sentences plus an endpoint reference; the resource and fields are front-loaded and nothing is padded. The opening is a noun fragment rather than a full statement, a minor structural weakness.

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 field enumeration carries the return-shape burden and largely does so. Pagination is covered by the schema, leaving little an agent would still need to know before calling it.

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%, so both limit and offset are fully documented in the schema (ranges, defaults, next_item usage). The description adds no parameter-level information beyond that, so the baseline 3 applies.

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 names the resource (campaigns) and enumerates the fields returned (start/end dates, financial goal, code, active flag), which distinguishes it from sibling list tools like lgl_list_appeals and lgl_list_funds. The verb is only implied by the title rather than stated, so it falls short of a 5.

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?

It hints at downstream use ('Use the ids and names when recording gifts or filtering searches') but gives no guidance on when to pick this over sibling list tools or when not to use it. Usage is implied rather than stated as an explicit condition.

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

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

The readOnlyHint annotation already establishes this is a safe read, so the description's lower bar is met by adding useful context: the record types returned and the projected fields (type, date, text, team member). It stops short of describing pagination behavior, result ordering, or empty-result handling.

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 compact sentences with the payload contents front-loaded and the API binding trailing. Nothing is redundant or padded.

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 simple filtered-list tool with fully covered parameters, a readOnly annotation, and no output schema, the description supplies the field-level return contents an agent would otherwise lack. Slight gap in not stating pagination/result-size behavior, though the schema largely covers it.

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%, so limit, offset, and constituent_id are fully documented in the schema itself. The description only restates the constituent path binding via the endpoint string and adds no new parameter semantics, which is the expected baseline when the schema does the heavy lifting.

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 names a specific resource (contact reports: calls, emails, meetings) scoped to one constituent, and lists the returned fields, so an agent knows exactly what this produces. It does not explicitly contrast with the many sibling list tools (notes, gifts, memberships), but the resource noun is distinctive enough to separate it.

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?

There is no statement of when to use this versus alternatives such as lgl_list_constituent_notes or lgl_create_contact_report, and no prerequisites or exclusions. Usage is only implied by the resource name, so the agent must infer intent from the tool name alone.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is the REST endpoint (GET /api/v1/constituents/{constituent_id}/gifts) and the field list, which is useful because no output schema exists. It adds no notes on ordering, pagination behavior, permissions, or empty results.

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 sentences, front-loaded with what the tool returns before the endpoint reference. Nothing is wasted, though the raw endpoint string is arguably debug-oriented filler rather than agent-facing guidance.

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, enumerating the returned gift fields is a real contribution and covers the main gap. However it says nothing about pagination semantics (the schema defines limit/offset but not how to page through a long giving history) or result ordering.

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% — limit, offset and constituent_id are all documented in the schema — so the schema carries the parameter burden. The description adds no syntax or filtering detail beyond what the schema already says, making the baseline 3 appropriate.

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 states a specific verb+resource ('A constituent's giving history: every gift...') and enumerates the fields returned, which separates it from lgl_get_gift (single gift) and lgl_search_gifts (cross-constituent). It does not explicitly name those siblings as alternatives, so it stops just short of a 5.

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?

There is no when-to-use guidance: nothing tells the agent to prefer this over lgl_search_gifts when it already has a constituent_id, and no prerequisites or exclusions are stated. The intended usage (fetch all gifts belonging to one constituent) is only implied by the phrase 'giving history'.

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

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

readOnlyHint=true already tells the agent this is a safe read, lowering the bar. The description does add value beyond the annotation by disclosing the returned fields and their relevance to determining current/lapsed status, which matters because there is no output schema. It says nothing about pagination limits or empty-result behavior, so it's adequate but not rich.

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?

One compact sentence front-loads the resource and the returned fields, then the endpoint line maps it to the LGL API. Nothing is wasted, though the trailing "LGL: GET ..." is largely redundant for an agent that already has the tool name.

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 read-only list tool with full schema coverage, safety annotations, and no output schema, the description tells the agent what comes back and why it would call it. Pagination behavior is handled by the schema, so nothing critical 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% – limit, offset, and constituent_id all carry their own descriptions including defaults and pagination semantics. The description adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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 names a specific resource (a constituent's memberships) and enumerates the returned fields (level, start date, finish date), so an agent knows exactly what this returns. It doesn't explicitly contrast itself with siblings like lgl_get_constituent or lgl_list_constituent_gifts, but the resource naming is unambiguous enough to separate it.

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?

"use it to see whether someone is current or lapsed" supplies one concrete use case, which is more than nothing. It offers no exclusions or named alternatives (e.g., when to prefer lgl_get_constituent for basic member data), so the routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the returned field set (type, text, original date) and the underlying API endpoint, but says nothing about pagination behavior, ordering, or empty results beyond what the schema's limit/offset params imply.

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 compact sentences: the first front-loads what is returned, the second supplies the API endpoint for cross-referencing. No filler or redundancy.

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 simple read-only list endpoint with a fully documented schema and an annotation covering safety, the description is nearly sufficient, and it usefully names the return fields in the absence of an output schema. Minor gaps are ordering/pagination semantics, which are only partly implied by the schema.

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%, with limit, offset, and constituent_id each fully documented in the schema, so the baseline is 3. The description adds no parameter-level meaning (e.g., whether notes are ordered by date, which affects offset use), so it does not rise above baseline.

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 resource (notes on a constituent) and enumerates the returned fields, so an agent can distinguish it from the many sibling list tools (gifts, contact reports, memberships) by resource alone. The verb 'list' is implied rather than stated, but the scope is 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?

Usage is implied by the resource-scoped name and stated scope; an agent can infer it lists notes for a given constituent. However, there is no explicit when-to-use guidance, no mention of alternatives such as lgl_create_note for writing notes, and no indication of prerequisites or when this list would be empty.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered without the description's help. The description adds useful content — the exact entity shape and the note that the returned ids/names feed gift recording and search filters — but says nothing about volume, pagination behavior, or whether results are sorted.

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?

Three tight sentences, front-loaded with the entity and its fields, followed by downstream-use advice and the API endpoint. No padding, though the endpoint string is marginal value for an agent that only sees the tool interface.

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?

There is no output schema, so the description carries the return-shape burden and does so adequately by enumerating the fields. Combined with annotations covering read-only safety and a fully documented 2-param schema, an agent has enough to call this correctly; only sorting/ordering and result volume are unaddressed.

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% and both parameters (limit, offset) are fully documented in the schema, including LGL's default of 25 and the next_item usage pattern. The description contributes nothing about limit/offset, so the baseline 3 applies.

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 names the resource (events) and enumerates the meaningful fields returned (dates, campaign, event type, goal, active flag), plus the underlying endpoint GET /api/v1/events. It never states the verb explicitly — 'list' comes only from the title — but the noun phrase plus endpoint make the operation unambiguous and distinguishable from lgl_list_campaigns/funds.

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?

'Use the ids and names when recording gifts or filtering searches' is guidance about consuming the output downstream, not about when to call this tool versus a sibling. There is no trigger condition, prerequisite, or exclusion stated, so the agent must infer when a listing of events is appropriate.

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

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

readOnlyHint=true already covers the safety profile, and the description adds useful context by naming the returned fields and the underlying endpoint (GET /api/v1/funds). It does not mention pagination behavior or default page size, so it adds modest value beyond 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?

Two tight sentences plus an endpoint reference; the field list comes first and the downstream-use hint second. No filler, though the endpoint string is redundant metadata for an agent.

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?

There is no output schema, and the description compensates by naming the fields returned and the ids/names an agent should reuse. Pagination is fully handled by the schema's limit/offset descriptions, so a read-only list tool is adequately covered.

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% — both limit and offset are fully documented with ranges and defaults in the schema — so the baseline of 3 applies. The description adds no extra meaning about pagination semantics beyond what the schema already provides.

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 clear resource ('funds, where gifts are designated') and enumerates the fields it carries (campaign, code, financial goal, active flag), which distinguishes funds from the sibling list_campaigns and list_appeals. It never uses an explicit verb like 'list', but the resource and scope are unambiguous for an agent.

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 sentence 'Use the ids and names when recording gifts or filtering searches' gives a downstream-use hint, tying it to lgl_create_gift and search tools, but it never states when to call this versus a sibling list endpoint (campaigns, appeals, groups) or any exclusion condition.

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

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

The readOnlyHint annotation already establishes this as a safe read. The description adds that it is a GET request and that results carry ids and keys, which is useful, but says nothing about pagination behavior despite the schema exposing limit/offset.

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?

Three short, front-loaded sentences with no filler; the trailing 'LGL: GET /api/v1/groups.' is a minor endpoint mapping rather than an explanation, but it is brief enough not to hurt.

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 simple read-only list tool with no output schema, the description supplies the essential return shape (ids, names, keys) and use context; pagination is covered by the schema. Adequate without over-explaining.

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%, so limit and offset are already fully documented in the schema. The description adds no additional parameter meaning, making the baseline 3 appropriate.

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 the resource precisely ('Constituent groups') and gives concrete examples (Board Member, Staff, Volunteer) plus the fields returned (ids, keys). Sibling tools use the same lgl_list_* pattern, so it is distinguishable, though differentiation rests mainly on the resource noun.

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 tells the agent what to do with the output ('Use the ids and names when recording gifts or filtering searches'), which implies why one would call it, but gives no explicit when-to-use/when-not-to-use guidance or named alternatives among the many list/search siblings.

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

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

readOnlyHint=true already establishes safety, and the description adds meaningful context beyond that: the exact fields returned (name, email, admin flag) and the upstream API path. With no output schema, disclosing the returned field set is genuinely useful; it only lacks notes on ordering or default result size (though the schema covers limit/offset).

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?

Three compact sentences with no filler, front-loading what the tool returns and following with usage and the API path. The opening is a noun fragment rather than a full clause, a minor stylistic wart, but nothing is wasted.

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 simple, annotation-covered list endpoint with two fully documented optional params, the description supplies everything else an agent needs: what the resource is, what fields come back, and how the ids are consumed downstream. No output schema is required given the field enumeration.

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% and both limit and offset are fully documented there, including defaults and the next_item pagination hint. The description adds no parameter-level detail, so the baseline 3 applies.

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 the resource precisely (LGL user accounts on the team) and enumerates the returned fields (name, email, admin flag), so an agent knows exactly what this list tool yields. It also distinguishes itself from siblings by explaining the resource is the referent of a gift's or contact report's team_member, and cites the underlying endpoint.

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?

Explicitly tells the agent when to reach for it: to obtain the ids and names needed when recording gifts or filtering searches, which routes usage toward lgl_create_gift and the search tools. It stops short of naming an alternative tool or stating when not to use it, so it is clear context rather than full routing guidance.

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

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

readOnlyHint=true already covers the safety profile, so the description's added value is the endpoint-routing detail (which types come from dedicated endpoints, which from /types/{type}) and the fact that these are static configured lookup values. It does not discuss pagination behavior or whether results are cached, but for a read-only reference call the disclosed context is solid.

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-loaded with the core purpose, but the long parenthetical listing raw endpoint paths and re-enumerating all fourteen type values duplicates the enum already in the schema. That bulk dilutes rather than helps the agent.

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 usefully says the return is ids and names, and pagination is fully specified in the input schema. Complete enough to call correctly, though it could note result ordering or an approximate size of each lookup.

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%, so the baseline is 3; the schema already documents type, limit, offset, and the gift_type_id filter. The description's note that gift_categories can be 'optionally filtered by gift_type_id' merely restates what the schema says, adding no format or edge-case detail.

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 ('the account's configured lookup values for one type') and immediately clarifies what the caller gets back ('the ids and names other tools accept'). It is clearly distinguished from siblings, which are list/get tools for domain entities rather than this reference-data endpoint.

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 phrase 'the ids and names other tools accept' communicates the purpose context (resolve valid IDs before calling create/update tools), and the description routes each type to its backing endpoint. However, it never states explicitly when to reach for this tool versus just calling a sibling list tool, so guidance is clear but not exhaustive.

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

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

readOnlyHint already covers the safety profile, and the description adds real behavioral context beyond it: results are limited to *active* constituents, at least one term is mandatory, and exact date formats (YYYY-MM-DDTHH:MM:SSZ vs YYYY-MM-DD) are specified. It stops short of describing return shape or result caps.

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-loaded: purpose and the common-case input pattern come first, then the reference list. The term enumeration is a dense run-on but every token is a usable field/value spec, so it earns its space despite packing a lot into one paragraph.

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?

There is no output schema, so the description should carry the burden; it covers input semantics thoroughly and the offset parameter hints at paging via 'the previous page's next_item'. It never states what a result object contains, which is the one material gap for an agent assembling a query.

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%, so 3 is the baseline, but the description goes well past the schema by enumerating every valid `terms` field and its value grammar (0 lapsed/1 active, 2-letter state, comma-separated ids, key|op|value for custom_attr). The `terms` schema entry itself defers to this description, making it load-bearing rather than redundant.

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+resource ('Search active constituents') plus the entity types covered (donors, members, volunteers, organizations). It is clearly distinguishable from siblings like lgl_get_constituent (single fetch) and lgl_list_constituent_gifts (related records).

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?

Guides input choice explicitly: 'Give `name` and/or `email` for the common case, or raw `terms`', and states the hard prerequisite 'At least one term is required.' It does not, however, say when to prefer this over sibling search/fetch tools such as lgl_get_constituent.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real behavioral context beyond that: results are limited to *active* gifts, and at least one filtering term is mandatory, which means this cannot be used as a bare enumeration. Return format and pagination semantics are left unstated.

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?

Purpose and the required-term precondition are front-loaded, and the term-field enumeration is dense but each entry earns its place by teaching operators the schema does not. The single long comma-chained list is a wall of text, which keeps it out of 5 territory.

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 read-only search tool with no output schema, it covers purpose, mandatory input, the term mini-language, and the underlying LGL endpoint. It omits response shape and pagination mechanics, though offset/limit in the schema hints at paging.

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%, so the baseline would be 3, but the description absorbs the semantics of the `terms` parameter: the schema merely says 'See the tool description for the available fields,' and the description then enumerates each field and its operator syntax (gt/lt/btw/in/ni, date formats). That is genuine added meaning above the schema.

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 gifts across the account') and gives two concrete usage examples (everything in a date range, or gifts to a fund/campaign). It does not differentiate itself from the sibling lgl_list_constituent_gifts, which is the likely confusion point, so it stops short of 5.

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?

Clearly states how to invoke it (supply date/updated bounds and/or raw `terms`) and enforces a hard precondition ('At least one term is required'). It never names an alternative tool or a when-not condition, so it is clear context without routing guidance.

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

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

With only destructiveHint=true in annotations, the description usefully adds PATCH/partial-update semantics ('only the fields you pass are sent') and the required-field quirk. It does not cover auth needs or rate limits, but it meaningfully exceeds the annotation baseline.

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?

Four tight sentences, front-loaded with the 'WRITE:' marker, each carrying distinct information (scope, partial-update, required-field caveat, endpoint). Nothing redundant.

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 22-param mutation with no output schema and minimal annotations, the description covers the crucial behaviors an agent needs: write nature, partial update, required fields, and exclusion of contact data. Return format is unnecessary since no output schema exists.

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 59% across 22 params, so the description must help. It explains the important first_name/last_name required-even-when-unchanged behavior and enumerates representative editable scalar fields, adding value beyond the schema for the parameters that matter most.

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 (change/update) and resource (scalar fields on an existing constituent) with concrete example fields. It clearly delimits scope by excluding addresses, emails and phones, though it does not name the sibling tool that handles those, so differentiation from siblings is partial.

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 real operational guidance: 'Only the fields you pass are sent' and to pass current values from lgl_get_constituent when first_name/last_name are unchanged. It signals which data is out of scope, but never names the alternative tool for editing contact details.

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