Funraise MCP by usefulapi

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

Goes beyond the annotations by disclosing concrete behavior: the completed date is set to now, and Funraise may additionally log an interaction as a side effect depending on task automation. That side-effect warning is exactly the kind of context annotations cannot convey. It stops short of saying what happens when the task is already complete, which matters given idempotentHint=false.

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 clauses with the operation class front-loaded ('WRITE:'), the core effect second, the side-effect caveat parenthetical, and the endpoint last. 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 one-parameter mutation with annotations covering the safety profile and no output schema, the description supplies the important missing behavior (timestamping and possible interaction logging). Only the treatment of an already-completed task is 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 description coverage is 0% for the single required parameter task_id, so the description should have compensated. It only exposes the id implicitly through the 'PUT /api/v1/task/{id}/complete' path and never states that task_id is a positive integer identifier of an existing task.

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 ('mark a task complete') and prefixes it with 'WRITE:' so the agent immediately knows the mutation class. It is clearly distinct from siblings like funraise_get_task or funraise_create_task, though it never names an alternative to disambiguate further.

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: the tool is used when a task is finished. There is no explicit statement of when to prefer it, no prerequisite (e.g. confirming the task exists via funraise_get_task first), and no exclusion of alternatives.

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=false, idempotentHint=false, destructiveHint=false; the description adds the meaningful consequence that each call creates a new note (so retries duplicate data) and names the endpoint. It does not cover auth scopes or what happens on invalid household_id, but the non-idempotency warning is genuine 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?

Three terse sentences, zero filler, with the WRITE classification and target resource front-loaded before the side-effect note and endpoint.

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 small write tool with no output schema, the definition covers the mutation, its non-idempotent nature, and the target resource. Missing only minor edges: household_id semantics and any auth/permission expectation.

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 75% and the schema documents body, title, and important with constraints; the description only alludes to the household via the path template. With household_id undocumented in both schema and description, 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 ('add a note to a household's record in Funraise') and disambiguates from the sibling supporter-note tool by naming the household scope. The HTTP endpoint reinforces the target resource.

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 household framing, and 'Creates a new note each call' hints at repeat-call consequences, but there is no explicit guidance on when to use this versus funraise_create_supporter_note or funraise_create_interaction, nor any stated prerequisites such as the household existing.

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 annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful reinforcement with 'Creates a new interaction each call' and the POST endpoint, but it does not cover auth requirements, error behavior, or what is returned.

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 front-loaded with 'WRITE' and is only three short sentences. Every clause adds useful information about purpose, behavior, and endpoint without waste.

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 write tool with no output schema, the description plus annotations cover the essential invocation context. It could be slightly stronger on return behavior or prerequisites, but it is largely complete for correct tool selection and invocation.

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 80%, so most parameters are already documented. The description adds minor meaning by naming interaction types that map loosely to action_required, but it does not clarify supporter_id or provide additional syntax 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?

The description states a specific verb and resource: log an interaction on a supporter's record. It clarifies that it creates a new interaction each call, which distinguishes it from read-oriented siblings like funraise_get_interaction and funraise_list_supporter_interactions, though it does not name those siblings directly.

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 gives examples of interaction types (call, email, meeting), implying when to use the tool. However, it does not explicitly state when to choose this over related write siblings such as funraise_create_supporter_note or funraise_create_task.

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=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by spelling out the consequence of non-idempotency (duplicate records) and the mitigation workflow, plus the underlying HTTP endpoint. It stops short of saying what the call returns or what permissions/validation errors to expect.

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, front-loaded with the WRITE marker and the resource, then the duplicate-risk warning and the alternative, then the endpoint. No filler; every clause carries information.

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 13 loosely documented parameters and no output schema, the description should at minimum explain which fields identify a supporter and what comes back (e.g., the new supporter ID) so a caller can chain into funraise_get_supporter. Neither is addressed, leaving meaningful gaps for a create operation.

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 8% across 13 parameters with zero required fields, so the schema alone leaves field intent largely undocumented. The description contributes nothing about parameters — no indication of which fields are needed, how email uniqueness works, or what the tags string format means — so it fails to compensate for the coverage gap.

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 'WRITE: create a supporter (donor) record in Funraise' — a specific verb, resource, and side-effect class, plus the concrete endpoint POST /api/v1/crm/supporter. An agent can distinguish it from the many funraise_get_* and funraise_list_* siblings 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 states the workflow precondition: 'search with funraise_list_supporters (email) first to avoid duplicates', naming the exact alternative tool and the parameter to search by. It also states the condition that makes this necessary ('creates a new record each call').

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 flag readOnlyHint=false and idempotentHint=false, but the description reinforces the non-idempotent behavior with 'Creates a new note each call', which is a meaningful warning that duplicate calls produce duplicate notes. It also exposes the underlying POST endpoint, giving the agent grounding in the actual 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?

Three short, front-loaded clauses with zero filler. The operation type and the key behavioral caveat both appear before the endpoint detail.

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 create tool with no output schema, the agent is left guessing whether the new note's id is returned and whether it can be used for follow-up operations. The core action and its non-idempotency are covered, but the result contract is not.

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 75%, so title, body, and important are already documented in the schema. The description adds only that the supporter is the target record, without explaining the role of supporter_id (the one undocumented parameter) or what 'important' changes downstream. 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 ('add a note to a supporter's record'), which cleanly separates it from the sibling funraise_create_household_note. It doesn't name that sibling explicitly, but the scoping to a supporter 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?

'WRITE:' and 'Creates a new note each call' imply this is for adding new notes rather than updating existing ones, but it never says when to use this versus funraise_create_interaction or how to check for an existing note first. Usage 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 write, non-idempotent, non-destructive, so the description doesn't need to re-establish safety. It adds value by stating 'Creates a new task each call' (reinforcing non-idempotency in plain terms) and the supporter/donation linkage rule, which the annotations do not capture. It never says what to expect on a missing linkage (error?) or what comes back.

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 short clauses, front-loaded with 'WRITE', then the linkage constraint, then the length limit and endpoint. Nearly every sentence carries information; only the title-length repeat 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 an 8-parameter write tool with no output schema, the description is thin on the return side: an agent creating a task will likely need the new task id, and nothing indicates whether one is returned or whether an error results from missing linkage. The linkage rule and mutation semantics are covered, but the post-call picture isn't.

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 is 3; the description earns above that by disclosing a cross-parameter constraint no single field description can express (at least one of supporter_id or transaction_id). The title 40-character note merely repeats the schema's maxLength, which is wasted but harmless.

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 ('create a task in Funraise') plus a non-obvious scoping rule: it must be linked to a supporter or a donation. This clearly separates it from funraise_get_task and funraise_complete_task without the agent needing to open 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?

'give at least one' of supporter_id or transaction_id is an explicit precondition for calling. It doesn't name the alternative siblings (e.g. create a task vs. log an interaction), so routing guidance is partial, but the critical gating rule is 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?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a GET endpoint and names the fields returned, but it does not cover error behavior, auth needs, or rate limits.

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 definition is two compact clauses: the core purpose is front-loaded, and the returned fields plus endpoint follow without redundant text. Every part contributes to identifying or calling 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-by-ID tool with annotation-covered safety and no output schema, the description gives enough context to select and invoke it. The main remaining gaps are error semantics and how to source the address_id, which are minor for this operation.

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 0%, so the description must compensate for the single address_id parameter. It does so by saying 'by id' and showing the path variable, but it does not explain the ID type, constraints, or where to obtain a valid address ID.

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 and resource: getting one address by ID. The word 'One' distinguishes it from sibling list tools such as funraise_list_household_addresses and funraise_list_supporter_addresses, and the parenthetical enumerates the returned fields.

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 'by id' and the endpoint path, which tells an agent to call this when an address_id is known. However, it does not explicitly say when to prefer this over list tools or what to do if only a supporter/household is known.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value by describing the payload contents (a configuration preview with the listed sections), which matters because there is no output schema; it does not mention error/not-found or auth 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?

Two compact, front-loaded clauses with no filler. The trailing 'GET /api/v1/campaignSite/{uuid}' is mildly redundant with the parameter name but is short enough not to hurt readability.

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 enumeration of returned configuration areas gives an agent a good preview of what it will get. Only error behavior and any access-permission notes are absent, which are minor for a single-resource read.

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 already documents campaign_site_uuid fully. The description's 'by UUID' adds minimal meaning beyond that, matching the baseline for full schema coverage.

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 ('One campaign site by UUID') and enumerates the returned configuration sections (payment options, goals, form, homepage, fundraiser settings). That clearly distinguishes it from sibling funraise_list_campaign_sites.

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 'by UUID' versus the plural list tool, but the description never explicitly says when to use this instead of funraise_list_campaign_sites or what to do if the UUID is unknown. 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and the 'GET /api/v1/crm/donation/{id}' line is consistent with that read-only profile. The description adds the field set returned, but says nothing about permissions, rate limits, or not-found behavior; with annotations carrying the safety profile a 3 is fair.

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 with the identifying key front-loaded, followed by the returned field list and endpoint. Nothing 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?

With no output schema, enumerating the returned fields is the right compensation and it does so, though at a coarse level ('fees, UTM, dedication' are unexpanded). For a single-parameter read this is nearly complete; only error/not-found behavior 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 coverage is 0% and the single parameter carries no description, so the description must carry the meaning. 'By its Funraise id' does tell the agent the integer is a Funraise donation id, but it adds no format, range, or example detail beyond that.

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 retrieval of a single donation keyed by Funraise id, and the phrase 'One donation by its Funraise id' implicitly separates it from funraise_list_donations. It even enumerates the resources returned (amount, supporter, household, form, fees, UTM), so an agent knows exactly what it gets.

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: fetch a single donation when you have the id, versus the list tool when you don't. There is no explicit when-to-use/when-not statement, no mention of the alternative list tool by name, and no guidance on behavior if the id is unknown.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully lists the fields returned, but it does not discuss permissions, error behavior, or rate limits.

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 definition is two sentences with no filler, and the returned-field list is front-loaded. It is appropriately sized for a simple single-record retrieval 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 GET-by-ID operation with no output schema, the description helpfully names the returned fields and includes the endpoint. It is nearly complete, with only minor gaps around parameter semantics and alternative-tool selection.

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?

The schema has 0% description coverage for the single required household_id parameter, so the description must compensate. It only embeds {householdId} in the endpoint path and adds no format, constraint, or identifier-source detail beyond what the schema already shows.

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 identifies the resource as a single household and enumerates the returned fields, which is clearer than a bare name. It implies retrieval by ID via the endpoint, though it does not explicitly distinguish itself from sibling tools such as get_household_member.

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 explicit statement of when to use this tool versus alternatives such as get_household_member or list_household_addresses. The singular 'One household' and endpoint path provide only weak implied 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the response includes both household and supporter details, which is useful return-shape context, but it says nothing about behavior when a supporter has no household (null vs error) or about pagination/auth.

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, front-loaded sentences with no filler. The parenthetical return-value note is dense and useful; the endpoint path is the only arguably redundant element since it restates the resource.

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 no output schema, the description should convey the return shape more concretely, especially since ambiguity with funraise_get_household is the main failure risk. It hints at returned fields but leaves the household-vs-membership distinction unresolved.

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 0%, so the schema only tells the agent the parameter is a positive integer named supporter_id. The description partially compensates by embedding it as {supporterId} in the path, confirming it is the supporter's identifier, but it adds no format or source guidance (e.g., where to obtain a supporter id).

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 (household membership) tied to a supporter, and the endpoint path confirms the lookup key. However, it does not distinguish itself from the very similar sibling funraise_get_household, so an agent must guess which of the two to call for household data.

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 tool versus funraise_get_household or funraise_get_supporter, and no prerequisites or exclusions are given. Usage must be inferred entirely from the endpoint path.

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, openWorldHint=true and destructiveHint=false, so the description adds almost nothing behavioral. The only extra information is the underlying REST path GET /api/v1/interaction/{id}, with no mention of error/not-found behavior or what the lookup 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?

Two short sentences, front-loaded with the operation and then the endpoint. Nothing is wasted, though the extreme brevity leaves it closer to a stub than a full definition.

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-parameter read tool with no output schema, this is barely adequate: the agent knows what it fetches but not what comes back, what happens on a missing id, or how the id is obtained. Annotations cover the safety profile, so the remaining gap is modest but real.

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 0% for the single parameter, so the description must compensate; 'by id' at least confirms interaction_id identifies an interaction rather than any other object. It still doesn't say where such an id comes from (e.g. returned by the list tools) or whether it must be a numeric Funraise id.

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 resource and scope: a single interaction fetched by its id, which distinguishes it from list-style siblings such as list_supporter_interactions. It never names those siblings, but the singular 'One interaction by id' 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?

There is no guidance on when to use this versus funraise_list_supporter_interactions or funraise_list_user_interactions, and no prerequisites or edge-case conditions (e.g. invalid/nonexistent id). The agent must infer usage entirely from the 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful value by naming the fields returned (compensating for the absent output schema) and citing the REST endpoint, but says nothing about error behavior or permissions.

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, front-loaded with the resource and return fields. The 'GET /api/v2/note/{id}' clause is mildly redundant for an agent but does anchor the underlying endpoint.

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 single-param read tool with annotations covering safety, this is largely complete — the field list stands in for the missing output schema. Only the not-found/error case is left 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 0%, so the description carries the burden for the single note_id parameter. 'by id' confirms the identifier refers to a note, but adds no format, range, or sourcing guidance beyond what the schema's integer type already conveys.

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 ('One note by id') and enumerates the returned fields (title, body, importance, author), so the agent knows exactly what this fetches. It implicitly distinguishes itself from the list_*_notes siblings by being the single-record-by-id lookup, though it never names them.

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: fetch a single note when you have its id, as opposed to funraise_list_household_notes or funraise_list_supporter_notes for collections. No explicit when-to-use, prerequisites, or handling for a missing note is 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the returned field set (status, frequency, amount, dates, supporter) and the underlying endpoint, but says nothing about not-found behavior, auth requirements, or rate limits. Useful additions, but not rich behavioral context beyond 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: the field list first, then the endpoint. No filler, and the most decision-relevant information is front-loaded.

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 enumeration of returned fields is exactly the compensation needed for an agent to know what it will get back. Error and edge-case behavior is the only notable omission.

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 0% for the single parameter, so the description carries some burden. 'By id' and the path template /crm/subscription/{id} imply subscription_id is the recurring gift's identifier, but no format, type, or source guidance (e.g., where to obtain the id) is added 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+resource ('One recurring gift by id') and enumerates the fields returned, which lets an agent separate it from funraise_list_subscriptions at a glance. The REST endpoint reinforces the single-record scope. It never names the list sibling explicitly, 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?

The phrase 'by id' implies this is the lookup path once a subscription id is known, and the presence of funraise_list_subscriptions in the sibling set makes the division of labor inferable. However, no explicit when-to-use, when-not-to-use, or prerequisite is 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the returned field set and the underlying REST path, but says nothing about not-found behavior, permissions/API key requirements, or rate limits that openWorldHint hints at.

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 fragments with no filler, and the payload contents are front-loaded before the endpoint reference. The telegraphic style is efficient, though the leading 'One supporter:' is slightly elliptical.

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 the safety profile and no output schema, the description's field enumeration effectively describes the return payload. Only error/edge-case behavior is missing, which is a minor gap at this complexity level.

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 0%, so the description must compensate; the {id} path template does signal that supporter_id is the record identifier. However, it omits the schema's positive-integer constraint and gives no format/example, leaving a gap for a single required 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?

The description names a single resource type (one supporter) and enumerates the fields returned, and the explicit endpoint GET /api/v1/crm/supporter/{id} makes the retrieve-by-id action unambiguous. It implicitly distinguishes itself from funraise_list_supporters, though it never says so explicitly and no verb is stated in prose.

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 guidance on when to use this versus funraise_list_supporters (browse/search) or funraise_get_household (related records). The agent must infer the choice 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint and the returned field set, which is useful, but says nothing about error behavior for a missing id or rate limits.

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 compact sentence with the identity of the resource front-loaded, followed by the returned fields and the endpoint. Every clause carries information an agent can use.

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 single-resource read with no output schema, listing the returned fields covers most of what an agent needs, and annotations cover the safety profile. A note on behavior when the id doesn't exist would close the remaining 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?

Only one parameter with 0% schema description coverage, so the description must carry the load. It conveys that the identifier is a task id and that lookup is by id, but adds no format or constraint detail beyond what 'by id' and the endpoint path imply.

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 ('One task by id') and enumerates the fields returned, so an agent knows exactly what it retrieves. The singular-by-id scope clearly separates it from the list_* siblings.

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: the 'by id' phrasing signals it needs a known task_id, likely obtained from a listing tool, but no explicit when-to-use, prerequisites, or alternative routing is 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?

The annotations already establish that this is a safe, read-only, non-destructive listing operation. The description adds useful behavioral detail the annotations do not cover: active is the default, archived=true switches to archived sites, and the response includes totalPageCount and totalRowCount. It does not discuss pagination limits or rate limiting, but the annotations lower the bar.

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 three tightly packed sentences: purpose and default scope first, return structure second, endpoint detail third. Every sentence earns its place with no repetition or filler.

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 parameter documentation and annotations covering safety, the description is nearly complete. It covers default scope, archived behavior, and the main return fields; only minor details like page-size behavior are left entirely to 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%, so the schema already documents page, archived, page_size, and allow_fundraisers. The description reinforces the archived default behavior but adds no syntax or format details beyond the schema; baseline 3 is appropriate 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 gives a specific verb and resource ('List campaign sites') and clarifies that campaign sites are fundraising pages, plus active versus archived scope. It does not explicitly distinguish itself from the sibling funraise_get_campaign_site, which likely fetches a single site, so it falls short of full 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?

Usage is implied: use this to list active or archived campaign sites, with active as the default. However, the description does not state when to prefer this over funraise_get_campaign_site or provide any explicit exclusions or alternatives.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real value by naming the fields in the response payload (important since there is no output schema) and by spelling out the continuation semantics for last_id and the underlying endpoint GET /api/v1/crm/donation. It does not address volume/rate characteristics of an unfiltered listing.

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 the resource and its returned fields, the second packs filtering and pagination guidance. Nothing is repeated from the schema beyond what is needed for readability.

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 returned fields is the key contribution and it is present; pagination is covered in both description and schema. Completeness would be higher if the description clarified when to prefer this over funraise_get_donation given the shared transactionId filter, or noted that omitting all filters returns a broad listing.

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 all six parameters are already documented, including the page-numbering ambiguity. The description largely restates those filters and adds only the framing that last_id means 'continue from the last donation id of the previous page', 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 ('List donations (transactions)') and enumerates the fields returned (amount, date, supporter, form, campaign page, allocation, fees, tags), which sharply conveys scope. It does not explicitly differentiate itself from funraise_get_donation, which an agent could confuse with the transactionId filter case.

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: filter by exact transactionId, by last N hours, or by lastUpdated, and use last_id to continue from the previous page's last id. It stops short of exclusions or naming an alternative (e.g., use funraise_get_donation for a single known donation), leaving that inference to the agent.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the raw endpoint path, which helps map to API docs, but says nothing about pagination, ordering, or auth scope for a 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 short sentences with no filler, and the resource identification is front-loaded ahead of the endpoint. It is efficient, though the terseness contributes to the missing usage and behavior context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with annotations covering safety and no output schema, the definition is minimally sufficient to invoke. It still omits where form_id comes from and whether the response is paginated or ordered, which matters for a list endpoint.

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 0% and the single parameter form_id has no schema description, so the description must compensate. It partially does by showing {formId} in the path template, implying form_id identifies the parent form, but it never states format, source, or constraints.

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 (custom questions attached to a form) and pairs it with the exact endpoint GET /api/v2/form/{formId}/custom-question, so an agent knows this is a read of a form's custom questions. No sibling overlaps this resource, so no differentiation is strictly needed, though the prose itself uses a noun phrase rather than an explicit verb.

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 call this versus alternatives, and no prerequisite is given (e.g. that a form_id must first come from funraise_list_forms). The agent must infer that this is the way to inspect a form's question configuration.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: the required CREATOR role on the key and the underlying GET /api/v1/form endpoint, which tells the agent this is a scoped remote read. It does not discuss paging behavior, but the schema does.

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, front-loaded with the resource and filters, with the auth prerequisite second. The GET path is mildly redundant but compact and useful to API-aware agents; nothing is wasted or buried.

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 filtered list with a fully documented 5-parameter schema and no output schema, the description covers purpose, filters, auth, and endpoint. The only gap is return shape and result ordering/pagination totals, which are partially inferable from 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%, so every parameter including the ambiguous 0-vs-1 page numbering is already documented in the schema. The description only restates the filter names (type, status, version) without adding format, matching semantics, or default ordering. 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 ('List') and resource ('donation and event forms') plus the filter dimensions, which clearly separates it from the sibling funraise_list_form_custom_questions. It does not explicitly name sibling alternatives, but the resource noun 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?

The description implies when to use it (browsing forms with optional type/status/version filters) and states the CREATOR role prerequisite, but it never says when not to use it or points to an alternative tool for a related need. 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 and destructiveHint=false, so the safety profile is covered. The description adds that results are paginated with specific response envelope fields (list, page, pageSize, totalPageCount, totalRowCount), which is useful behavioral context not present elsewhere. It says nothing about empty results, permissions, or error 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?

Two compact sentences with the subject front-loaded and no filler. The parenthetical pagination field list is dense but earns its place given there is no 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 simple paginated read tool with read-only annotations and no output schema, the description covers what the endpoint returns and how it is paged. The main gap is routing guidance against sibling address tools, which is a usage rather than completeness issue.

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 80%; page, page_size, sort and order are all documented in the schema, including the paging-origin ambiguity. The description only contributes the householdId path param via the endpoint string, which is marginal added value. 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 (addresses of a household) and the endpoint, so an agent can tell it fetches household addresses rather than supporter addresses like the sibling funraise_list_supporter_addresses. The listing verb is implied rather than stated, but the resource and scope are 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?

There is no guidance on when to choose this over funraise_get_address (single address) or funraise_list_supporter_addresses. The agent is left to infer the selection rule entirely 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the pagination behavior and the endpoint, but says nothing about default ordering, empty-result behavior, or auth requirements beyond what annotations 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 short fragments, front-loaded with the resource and scope followed by the endpoint. Nothing is wasted, though the terse phrasing borders on under-specification rather than polished conciseness.

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 should say more about what a note record contains or at least that results are returned as a page of note objects. It covers scope and pagination but leaves the return shape and sorting defaults to inference.

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 80% and the paging/sorting parameters carry detailed descriptions, including the caveat about 0- vs 1-based paging. However, the required household_id has no schema description, and the description only implicitly maps it via '{id}' in the path, adding little 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?

The description names a specific resource (notes on a household record) and the exact endpoint, so an agent can tell it apart from funraise_list_supporter_notes or funraise_get_note. It never uses the verb 'list' explicitly, relying on the title and '(paginated)' to imply retrieval of a collection.

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 guidance on when to pick this over funraise_list_supporter_notes, funraise_get_note, or funraise_create_household_note, and no prerequisites are stated. The only implied usage is the household scope, recoverable from the path template.

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 readOnly/openWorld/non-destructive, so the safety profile is covered; the description adds the concrete GET endpoint and, importantly, discloses that q is mandatory with a server-side default of 'id > 0 order by id asc'. It omits anything about paging behavior or result caps, but the annotations carry the rest.

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, both doing work: the first names the resource and return fields, the second explains the required filter with an example and default. Slightly dense with nested quoting in the example, but front-loaded and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing the returned fields, and it flags the mandatory q parameter. Pagination quirks are delegated to the schema, which handles them well, so nothing an agent needs to invoke the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents q, page and page_size including the 0/1 paging ambiguity. The description restates the q semantics and adds a worked expression example, but contributes little the schema does not already contain.

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 opens with a specific verb and resource ('List recurring gifts (subscriptions)') and enumerates the fields returned, so an agent knows exactly what it gets back. It does not explicitly distinguish itself from the sibling funraise_get_subscription (single record), though the list/get naming makes that inference easy.

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 states that the q filter is required by Funraise and gives its default, which is genuine usage context. However, it never says when to pick this tool over funraise_get_subscription or when to narrow the list with a status filter beyond the single 'Cancelled' example.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that results are paginated and the REST path backing the call; it says nothing about page size defaults, ordering defaults, or what an empty result 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?

Two short fragments, front-loaded with the resource and scope, with zero filler. The telegraphic style costs a little readability but keeps the definition tight.

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 5-parameter paginated list tool with no output schema, the description is minimal but workable since annotations carry safety and the schema carries pagination details. It is still thin on what an address record contains and on the paging ambiguity the schema itself flags.

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 80%, with page, sort, order, and page_size all documented in the schema; only the required supporter_id lacks a description there. The description partially compensates by showing supporterId in the endpoint path, but adds no further meaning about sortable fields or pagination semantics 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?

The description states a specific resource (addresses of a supporter) plus the underlying endpoint, making it clear this is a list operation scoped to one supporter. It is distinguishable from funraise_get_address and funraise_list_household_addresses by the supporter scope, though it never explicitly names those siblings.

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 guidance on when to use this versus funraise_get_address (single address) or funraise_list_household_addresses, nor any prerequisite or exclusion. The agent must infer the selection criteria 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /api/v1/interaction/donor/{donorId}) and the shape of returned fields, which is genuine added value, but it says nothing about pagination, ordering, result limits, or empty-result behavior — meaningful for a read/list tool.

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 short sentence plus the endpoint, with the resource and returned fields front-loaded and zero filler. The terseness costs it a point only because there is room to add routing guidance without bloat.

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 field enumeration ('subject, description, action, assigned user, dates') usefully describes the payload. However, for a list endpoint with a single scoping parameter, the description omits pagination/ordering behavior and does not distinguish supporter-scoped from user-scoped listing, leaving real gaps.

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 0%, but there is only a single required integer parameter and the description's 'of a supporter' wording makes clear that supporter_id scopes the query. It adds no guidance on identifier format or where to obtain a valid supporter id, so it neither fully compensates for the coverage gap nor leaves the parameter unintelligible.

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 (the interaction log for one supporter) and enumerates the record types and fields returned (calls, emails, meetings; subject, description, action, assigned user, dates). It effectively distinguishes this from funraise_get_interaction (single record) by implying a list for a donor, though it never explicitly differentiates from funraise_list_user_interactions, which is the closest ambiguous 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?

Usage is only implied: an agent can infer it should call this when it needs all interactions tied to a supporter. There is no explicit when-to-use statement, no mention of the supporter-scoped vs user-scoped alternative (funraise_list_user_interactions), and no note on when to prefer funraise_get_interaction for a single record.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that results are paginated and the REST path, without saying anything about ordering defaults, total counts, or what a note record contains. Given the annotation coverage, a 3 is appropriate.

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 fragments with no filler and the resource scope stated first. It is efficient, though the terseness borders on under-specification rather than maximal information density.

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 readOnly annotations the safety picture is clear, but there is no output schema and the description says nothing about the shape of a note, its fields, or whether sorting has a default. For a 5-parameter paginated list tool, that leaves an agent guessing about the return payload.

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 80% (page, sort, order, page_size are all documented; supporter_id is not), so the baseline is 3. The description's '(paginated)' nod confirms page/page_size behavior but adds no syntax or constraint detail 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?

The description names the resource precisely ('Notes on a supporter's record') and even gives the underlying endpoint GET /api/v2/supporter/{id}/note, which unambiguously scopes it to supporters rather than households. It is a noun fragment rather than an explicit verb+resource sentence and never names the sibling it is distinct from (funraise_list_household_notes), 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?

There is no when-to-use, when-not-to-use, or alternative routing guidance. An agent must infer from the name alone that this lists existing notes rather than creating them (funraise_create_supporter_note) or fetching a single note (funraise_get_note).

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description contributes real behavioral context by disclosing the server-side ordering ('newest first, as Funraise returns them'), which an agent could not otherwise assume, but says nothing about auth, rate limits, or what a page of results contains beyond the records themselves.

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 zero waste: what it lists, how it orders, how it filters, and the underlying endpoint. The most decision-relevant facts (resource and ordering) are front-loaded.

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, fully documented, 4-parameter list endpoint with annotations carrying the safety profile, the description covers what the agent needs to call it correctly. The remaining gap is the result shape (fields returned per supporter, whether totals/paging metadata come back), which matters somewhat given there is no output 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% and each parameter is documented in detail, including the paging 0-vs-1 ambiguity, so the baseline of 3 applies. The description restates the email and last_hours semantics and adds only the ordering guarantee, which marginally exceeds 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 (list supporters/donors in the Funraise CRM) plus the ordering ('newest first as Funraise returns them') and the two filtering modes. An agent can immediately tell this is a collection read, distinct from funraise_get_supporter or the create/note siblings.

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 two filter modes (exact email, last N hours) imply lookup-by-email and incremental-sync use cases, so usage is reasonably inferable. However, it never names an alternative or says when not to use this tool — notably it does not clarify when to prefer funraise_get_supporter for a single known supporter rather than an email filter here.

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, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds only the raw endpoint path; it says nothing about pagination, ordering, rate limits, or what happens for an unknown/zero user_id, so it contributes almost no behavioral value beyond structured data.

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 fragments with no filler, and the resource scope is front-loaded. It is arguably too terse rather than bloated, so conciseness itself is fine.

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 list endpoint with no output schema, the description should at least indicate what is returned (interaction records) and whether results are paginated or bounded. Neither is present, and there is no guidance on the single required parameter's expected value, so the definition is thin for correct invocation.

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 0% and user_id has no description, so the schema alone does not say what kind of ID is expected. The parenthetical '(staff member)' and the {userId} path hint that this is a Funraise staff-user ID rather than a supporter ID, which is genuinely useful disambiguation, but format/validity details remain undocumented.

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 (interactions) and the scoping dimension (assigned to a Funraise user/staff member), which is meaningful. But it is essentially a restatement of the title plus a raw endpoint path, with no verb and no explicit differentiation from the sibling funraise_list_supporter_interactions or funraise_get_interaction.

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 tool versus funraise_list_supporter_interactions, funraise_get_interaction, or funraise_create_interaction. The only cue is the implicit 'assigned to a user' scope, leaving the agent to infer the selection condition.

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