Little Green Light MCP by usefulapi

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

Annotations only supply destructiveHint=true; the description adds the write semantics, the dedup warning, and the underlying endpoint (POST /api/v1/constituents). It does not say what the API returns on success or how it behaves if a duplicate is submitted anyway, but the mutation risk and pre-check are well covered.

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 WRITE marker and the resource, then constraints, then the dedup pointer. Nothing is padding and the ordering matches how an agent should read it.

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 write tool with no output schema and only a destructiveHint annotation, the description covers purpose, required fields, dedup and endpoint. It omits what is returned by a successful create and whether a duplicate is rejected or silently merged, which an agent would benefit from knowing.

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?

With 64% schema coverage and 25 params, the schema does most of the work. The description usefully groups the nested collections (emails, phones, addresses, groups) and ties 'person or organization' to is_org, but it also claims email_addresses is required, which contradicts the schema's required list of only first_name and last_name, making the added meaning partly unreliable.

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 WRITE label and a specific verb+resource ('add a new constituent (person or organization) to the account'), then enumerates the optional sub-resources. That is enough to separate it from lgl_create_gift, lgl_create_note and lgl_update_constituent 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 routes the agent to the alternative: 'Search first (lgl_search_constituents) to avoid creating a duplicate.' It names the sibling and the condition that selects it, which is exactly the when-to-use guidance an agent needs before performing a write.

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 provide destructiveHint=true, and the description does not reconcile why an additive 'log a report' carries a destructive hint — an agent is left to guess whether prior data is overwritten. It does add useful context beyond the annotation: the WRITE label and the underlying endpoint POST /api/v1/constituents/{constituent_id}/contact_reports, which confirms this is a nested create under a constituent.

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 tightly packed sentences with zero filler: operation class first, required field and type resolution second, endpoint last. Every clause carries information an agent needs to construct the call.

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 7-parameter create tool with no output schema, the description covers the required fields, the type-resolution ambiguity, and the endpoint shape, which is enough to invoke it correctly. It leaves the destructiveHint unexplained and says nothing about what the response returns or how the new report id is surfaced.

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, but the description adds genuine value by calling out that text is mandatory and that the contact report type accepts either an id or a name (with 'Call' as an example). The cross-reference to lgl_list_type_values supplies a resolution path the schema itself does not.

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 immediately disambiguates the resource with concrete examples ('a call, email or meeting with a constituent'), which cleanly separates it from siblings like lgl_create_note and lgl_create_gift. The 'WRITE:' prefix signals the operation class up front.

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 concrete preconditions: 'text is required' and the type may be supplied by id or name, plus an explicit pointer to lgl_list_type_values type=contact_report_types for valid values. It does not, however, state when to prefer this tool over lgl_create_note for a logged interaction, so it stops short of full alternative routing.

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 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.

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 it does add real context: it labels the operation as a write, names the underlying endpoint (POST /api/v1/constituents/{constituent_id}/notes), and discloses which fields are mandatory. It stops short of describing auth requirements or the response/confirmation behavior.

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 dense sentences plus an endpoint reference; the operation class and required fields lead, and nothing is repeated from the title. Every clause carries information the agent needs at call time.

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, the definition covers requiredness, the id/name alternative, type-value discovery, and the target endpoint. Only external_id's purpose and any post-write behavior remain unstated, which 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 67%, and the description usefully resolves the one genuinely ambiguous pair — note_type_id vs note_type_name are alternatives for the same value, with 'General' given as a concrete example and a lookup tool named. It says nothing about external_id, which is the remaining undocumented parameter.

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 verb+resource pair ('add a note to a constituent's record') and marks the operation class with a 'WRITE:' prefix. An agent can distinguish this from lgl_list_constituent_notes and lgl_update_constituent 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?

Tells the agent what is required (text, original_date) and routes it to the sibling lgl_list_type_values with the exact filter (type=note_types) for discovering valid note types. It does not state when *not* to use it or contrast against update/other creation tools, so it stops short of a 5.

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 the safe-read profile, so the bar is lower. The description adds real value by enumerating the scope of returned data (names, salutations, addresses, phones, emails, groups, memberships, custom attributes), telling the agent what 'full details' actually means.

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 plus a compact endpoint reference; nothing is wasted. The API path is arguably redundant but harmless for traceability.

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?

No output schema exists, so the description usefully compensates by naming the returned field groups, and the read-only annotation covers safety. For a single-parameter get, the agent has everything needed to call it correctly.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents 'id' as a positive integer. The description adds no format or source guidance beyond that, which is the expected 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 and resource ('Full details for one constituent by LGL id') and scopes it to a single record, which cleanly separates it from the list_* and search_* siblings that return multiple entities. An agent can select it without ambiguity.

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 by-id framing: call it when you already have a constituent id and need the complete record. There is no explicit statement of when to prefer this over lgl_search_constituents, nor any prerequisite or exclusion.

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 readOnlyHint=true already covering the safety profile and no output schema present, the description carries useful weight by disclosing the shape of the returned payload (which fields come back). It does not mention error behavior for a missing id or rate limits, but the return-content disclosure is real added value.

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 that states scope and return fields, followed by the upstream API mapping. The endpoint reference is mildly redundant for an agent but is compact and potentially useful for tracing; no wasted prose.

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 single-parameter read tool with annotations covering safety and no output schema, the description supplies the missing return-value picture. It stops short of noting not-found behavior or any expansion options, but nothing essential for calling it correctly is absent.

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?

Only one parameter, and the schema already documents it at 100% coverage ('Gift id (integer)', positive integer). The description's 'by id' adds no syntax, format, or constraint detail beyond the schema, 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 (get) and resource (gift) and scopes it to a single record by id, which cleanly separates it from the list_* and search_gifts siblings. It also enumerates the returned detail set (amount, deductible amount, dates, fund/campaign/appeal/event, payment type, acknowledgment template, tribute, custom fields), so an agent knows exactly what this fetch yields.

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 framing 'one gift by id' implies this is the single-record fetch and that bulk lookups belong to lgl_search_gifts or lgl_list_constituent_gifts, but no alternative is named and no when/when-not condition is stated. Usage is inferable 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 cover the safety profile (readOnlyHint=true), so the bar is lower. The description adds genuine context by enumerating what each appeal record contains (campaign, date, financial goal, cost, active flag) and naming the underlying endpoint, which is useful since 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 tight sentences with the resource description front-loaded and the redirect to downstream use second. No wasted clauses, though the endpoint citation is marginally 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?

With no output schema, the description usefully lists the fields returned, and the schema fully covers pagination. For a simple read-only list tool, this is close to complete; only sibling routing is absent.

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% for both limit and offset, including defaults and pagination semantics, so the schema does the heavy lifting. The description contributes no additional parameter meaning; 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 (list fundraising appeals) and even clarifies the domain with example types (mailings, emails, asks), plus naming the key fields it carries. It does not explicitly differentiate itself from close siblings like lgl_list_campaigns or lgl_list_funds, but the appeal framing is distinct enough to identify.

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 gives downstream guidance ('use the ids and names when recording gifts or filtering searches'), which implies why one would retrieve appeals, but never states when to call this versus alternatives or any prerequisite. Usage context 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, and the description reinforces this by citing the GET endpoint and the fields returned. However it omits any pagination or response-shape behavior despite the schema referencing next_item, so added context beyond annotations is modest.

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 terse sentences led by the returned fields, followed by the API endpoint reference, which is useful for an API-tied tool. Front-loaded and essentially waste-free.

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's enumeration of returned fields is valuable and compensates well. Pagination is covered by the parameter schema, so the only minor gap is lack of guidance on result volume or 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%, so the schema fully documents limit and offset with defaults and pagination semantics. The description adds nothing about parameters, 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 names the resource (campaigns) and enumerates the attributes returned (start/end dates, financial goal, code, active flag), which clearly distinguishes it from sibling list tools like lgl_list_appeals or lgl_list_funds. It never states the verb 'list' explicitly in the body, but the resource plus field enumeration makes 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?

'Use the ids and names when recording gifts or filtering searches' explains downstream use of the output but not when to select this tool over alternatives. There is no when-not guidance or named sibling to route against, 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered and the description does not contradict it. The description adds useful context by disclosing the returned fields and the underlying API endpoint, but says nothing about pagination behavior, ordering, or empty-result handling beyond what the schema's limit/offset notes 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 sentences, zero filler: the first front-loads what the tool returns and the second pins the exact endpoint. Nothing is padded or 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?

With no output schema, the description's enumeration of returned fields (type, date, text, team member) meaningfully compensates, and all three parameters are fully documented in the schema. The remaining gap is usage context — nothing tells the agent when this listing is the right call versus a sibling lister.

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 all documented including defaults, ranges, and the 0-based/next_item convention. The description adds no parameter-level meaning beyond that, so the baseline of 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 states a specific verb+resource ('Contact reports logged for a constituent') and enumerates the data returned (type, date, text, team member), which clearly separates it from the sibling listers for notes, gifts, and memberships. It stops short of explicitly naming those siblings, so this is a clear but not maximally differentiated purpose statement.

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, no prerequisites (e.g., you must have a constituent_id in hand), and no mention of alternatives such as lgl_list_constituent_notes or how to create a report via lgl_create_contact_report. The only routing signal is the resource name itself, which is implied rather than stated.

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 safe-read profile is covered. The description adds nothing beyond that – no note on pagination behavior, result ordering, or what happens for a constituent with no gifts. Adequate but thin for a read-only list operation.

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, front-loading the resource and return fields, with the REST endpoint appended as a lookup aid. No filler; slightly denser than the minimum but every element is relevant.

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?

No output schema exists, so the description usefully enumerates the fields returned, and pagination is fully handled in the input schema. Missing only the routing relationship to sibling gift tools (search_gifts, get_gift).

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 all documented in-schema including defaults and next_item paging guidance, so the baseline is 3. The description adds no parameter-level meaning beyond the schema (the field list is output semantics, not input semantics).

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, 'a constituent's giving history', and enumerates the returned gift attributes (amount, date, gift type, fund, campaign, appeal, event, payment type). It is clearly scoped to a single constituent, but never names the sibling lgl_search_gifts, so an agent must infer the boundary between the two gift-listing tools.

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 only implied: it reads like the tool to call when you already have a constituent_id and want their gifts. There is no explicit when-to-use, no contrast with lgl_search_gifts, and no stated prerequisites such as whether the constituent must exist or be accessible.

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. The description adds the specific fields returned (level, start date, finish date) and the API endpoint, which is useful context for an agent since there's no output schema. It does not cover pagination behavior or auth, but those are partly in the 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?

A single, front-loaded sentence with a clear resource definition, followed by a use case and the endpoint. No wasted words.

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 list tool with annotations covering safety and no output schema, the description provides the key return fields and a use case. It omits pagination and full response structure, but the schema documents limit/offset, so it's largely 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 description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-level detail (e.g., no mention of limit, offset, or constituent_id), so 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 (a constituent's memberships) and the key fields returned (level, start date, finish date), and the endpoint. It implies listing but does not explicitly use a verb like 'list' nor name any sibling alternative, so it's clear but lacks sibling differentiation.

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 says 'use it to see whether someone is current or lapsed', giving a clear context. It does not specify when not to use it or name alternative tools (e.g., lgl_get_constituent), so it stops short of 5.

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 remaining burden is light. It adds the underlying endpoint and the shape of what is returned (type, text, original date), but says nothing about pagination behavior even though the schema exposes offset/limit with a next_item pagination model.

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 short sentences with no filler, and the purpose is front-loaded before the API mapping. It is efficient, though the endpoint reference adds little value for an agent that only needs to choose and call the tool.

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 fully documented parameters, this is close to adequate, and naming the returned fields partially compensates for the absent output schema. However, nothing tells the agent that results are paginated or how to walk pages, which is the main contextual 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 description coverage is 100%, with limit, offset, and constituent_id all documented in the schema itself, so the baseline is 3. The description adds no parameter-level detail (no default page size, no pagination usage hint) beyond what the schema already carries.

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 ('List') and resource ('notes recorded on a constituent') and even enumerates the returned fields (type, text, original date), so an agent can distinguish it from lgl_create_note and lgl_list_constituent_contact_reports. It stops short of naming any sibling explicitly, so it lands at 4 rather than 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, no statement of when this is preferable to lgl_list_constituent_contact_reports or lgl_get_constituent, and no prerequisites (e.g. the constituent must exist). Usage is only inferable from the tool name.

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 fields and the API endpoint, which is useful context, but it does not disclose pagination behavior, rate limits, or authentication requirements beyond what the schema implies.

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 concise and front-loads the resource definition. The three sentences are useful, though the endpoint line is marginally redundant given the tool name. Overall it is appropriately sized.

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 list tool with two optional pagination parameters and no output schema, the description supplies the returned field names and usage context. It could more explicitly state that it returns a paginated list, but the schema covers pagination and the description is otherwise sufficient.

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 description does not need to explain limit and offset. The description adds no additional parameter semantics beyond the schema. 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 the fields returned (dates, campaign, event type, goal, active flag) and implies the list operation via the endpoint, but it does not explicitly state a verb like 'List' and relies on the tool name to make the action clear. It distinguishes itself from sibling tools by focusing on events.

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 provides clear downstream context: 'Use the ids and names when recording gifts or filtering searches.' This tells the agent why to call the tool, though it does not explicitly compare it to alternative list tools or state when not to use it. That makes it a clear context without 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, and the description is consistent with a safe read operation. It adds domain context and returned fields, but does not disclose pagination behavior, sorting, auth requirements, or response shape beyond the endpoint.

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 sentences: resource definition, usage note, and endpoint. The resource definition is front-loaded and no sentence is 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 low-complexity list tool with fully described parameters and read-only annotations, the description covers what funds are, key fields, and how the returned ids/names are used. It does not detail return pagination or total counts, but the schema covers paging inputs; the description is nearly 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?

Both parameters (limit, offset) are fully described in the schema, and the description does not add any parameter-level meaning. Under the 100% schema coverage baseline, a 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 the resource ('Funds'), its domain role ('where gifts are designated'), and the fields returned ('campaign, code, financial goal and active flag'). It does not explicitly differentiate from sibling list tools such as lgl_list_campaigns or lgl_list_appeals, so it is clear but lacks sibling-specific routing.

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 implies a use case by saying to use the ids and names when recording gifts or filtering searches, but it never states when to call this tool rather than lgl_list_campaigns, lgl_list_appeals, or lgl_search_gifts. No exclusions or prerequisites are given.

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 needs only to add context. It does add that groups carry ids and keys and cites the underlying GET endpoint, confirming read behavior. It says nothing about pagination behavior or result volume, which the schema partially compensates for.

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 sentences with the resource description front-loaded, followed by practical usage and then the API mapping. There is little waste; the trailing 'LGL: GET /api/v1/groups' is arguably redundant but is brief and aids traceability to the vendor API.

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 two-parameter list tool with no output schema, the description covers what is returned (ids, keys, examples), why it matters (recording gifts, filtering searches), and the source endpoint. Only the lack of pagination/volume expectations 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 description coverage is 100% and both parameters (limit, offset) are fully documented in the schema, including defaults and ranges. 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?

The description names the specific resource (constituent groups with examples Board Member, Staff, Volunteer) and states what is returned (ids and keys), which makes the operation unambiguous. It stops short of an explicit verb like 'list' and does not differentiate itself from the closest sibling, lgl_list_type_values, which could look similar to an agent scanning names.

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' explains what the results are good for downstream, which implies when the tool is relevant. However, there is no guidance on when to call this vs. a sibling list/search tool, and no exclusions or prerequisites are stated.

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 the safety profile, so the description's main addition is the reference-data framing and the endpoint. It does not disclose result ordering, whether team membership includes inactive users, or any auth/rate-limit behavior, leaving the behavioral picture thin beyond the annotation.

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?

Compact and front-loaded: the resource definition comes first, then the practical usage note, then the API reference. Three short statements with no filler, though the parenthetical field list and em-dash clause make it slightly dense.

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 carries the burden of describing return values and does so by naming the returned fields; pagination is handled by the schema's limit/offset. What remains unstated is pagination metadata (e.g. next_item, totals) mentioned in the offset description, which would round out the picture.

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 (1-100, default 25) and offset (0-based, default 0) are fully documented in the schema, including the default values. The description adds nothing about parameter semantics, 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?

Identifies the exact resource (LGL user accounts on the team) and enumerates the fields returned (name, email, admin flag), plus the underlying endpoint GET /api/v1/team_members. It also positions the tool relative to siblings by explaining these are the values a gift's or contact report's team_member field refers to, which no other sibling tool does.

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 what to do with the results: "Use the ids and names when recording gifts or filtering searches." That is actionable usage guidance tied to sibling operations (create_gift, search_constituents), though it stops short of stating when not to call it or naming a competing alternative.

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 tells the agent this is a safe read. The description adds implementation routing (which types come from their own endpoints vs /api/v1/types/{type}), which is useful context but does not disclose behavior the agent actually needs, such as return shape or pagination semantics. Adds some value over the annotation only.

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 purpose is front-loaded in the first clause, which is good, but the sentence is a dense run-on that spends substantial space on internal endpoint URLs (/api/v1/gift_types, /payment_types, etc.) that an agent cannot act on. The routing detail is verbose relative to its value.

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 lookup tool with no output schema, the description covers the essential points: what is returned (ids and names), the full set of type values, and the special gift_type_id filtering case. An agent has enough to call it correctly.

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 enum values, limit/offset, and the gift_type_id filter are all documented in the schema. The description's endpoint-to-type mapping corroborates but does not add semantics beyond what the schema already provides; 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 (list) plus resource (the account's configured lookup values for one type) and adds the key distinguisher that these are 'the ids and names other tools accept'. This separates it from the data-listing siblings like lgl_list_appeals or lgl_list_campaigns, which return entities rather than lookup/reference values.

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 ids and names other tools accept' implies the purpose (resolve enum values before calling a create/update tool), but there is no explicit when-to-use statement or a named alternative to route between. There is no direct sibling alternative, so the guidance is workable but inferred rather than stated.

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 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.

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 bar is lower; the description still adds real value by disclosing the 'active gifts' filter scope, the mandatory-term validation rule, and the underlying LGL endpoint. It omits any note on pagination semantics or result volume, which keeps it from a 5.

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 and examples before the dense term-field enumeration. The long parenthetical list is run-on, but every element earns its place given the raw query-string API.

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 complex 9-param search with no output schema, it covers purpose, the required-term constraint, query vocabulary, and points to the GET endpoint. It does not describe the gift record shape returned, a minor gap 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 100%, but 'terms' is an opaque raw-string array in the schema; the description compensates by enumerating every supported field and its operator syntax (in|ni, gte|lte|btw, bl, date formats), which is the only place that knowledge exists.

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 (search) and resource (gifts), scoped to 'active gifts across the account', and immediately illustrates the two canonical query shapes (date range, fund/campaign). It is clearly distinguishable from lgl_get_gift and lgl_list_constituent_gifts.

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 concrete usage context ('everything received in a date range, or gifts to one fund or campaign') and states the hard constraint 'At least one term is required'. It does not explicitly route the agent away from sibling list/get tools, but the context is clear enough to select it.

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 declare destructiveHint=true, so the description carries most of the burden and does well: the 'WRITE:' prefix, the partial-update guarantee ('only the fields you pass are sent'), and the required-field quirk (first_name/last_name must be passed even when unchanged) are all behavior an agent cannot infer from the schema alone. It stops short of describing permissions, error behavior, or what an empty PATCH returns.

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 dense sentences, front-loaded with the operation type and field scope, followed by the two gotchas an agent must know. The trailing 'LGL: PATCH /api/v1/constituents/{id}' is compact and useful. No filler, though the field enumeration slightly overlaps the 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 22-parameter mutation with no output schema, the description covers the highest-risk unknowns: partial update behavior, the required-name trap, and excluded sub-resources. Return value and failure modes are unstated, but with no output schema that omission is defensible; the main residual gap is the undocumented minority of fields.

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%, with parameters such as gender, suffix, job_title, is_deceased, maiden_name, middle_name, deceased_date and annual_report_name undocumented in either place. The description adds real value on the required-first_name/last_name wrinkle and the send-only-what-you-pass semantics, but does not fill the documentation gap for the remaining undocumented fields, so this lands at the baseline-plus level rather than higher.

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 ('change scalar fields on an existing constituent') and enumerates representative fields, so the scope is immediately legible. It also draws the boundary against sibling functionality by declaring that addresses, emails and phones are not edited here, which no sibling name alone would convey.

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 operational context: only passed fields are sent, and current values should be sourced from lgl_get_constituent when first_name/last_name are unchanged. The exclusion of addresses/emails/phones implies an alternative path but never names the tool that handles them, so the routing is clear but not fully explicit.

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