Wild Apricot MCP by usefulapi

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

destructiveHint=true is already declared, so the agent knows check-out carries a destructive profile. The description adds genuinely useful context beyond that: that checked_in=false reverses a prior check-in, and it exposes the underlying endpoint (POST /rpc/{accountId}/CheckInEventAttendee). It omits permissions, whether check-in triggers notifications, and side effects on guest counts.

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 tight sentence leads with the action and semantics before the guest case, with no padding. The trailing API endpoint is arguably operational detail rather than agent-facing guidance, a minor dilution.

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 three-parameter mutation with full schema coverage and a destructiveHint annotation, the description plus schema gives an agent enough to invoke it correctly. There is no output schema to explain, though error and prerequisite behavior remains unstated.

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 is already documented in the schema, including the guests-as-number constraint on checked_in_guests. The description only restates the boolean meaning, adding no format, default, or boundary detail beyond the schema, 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?

States a specific verb and resource: mark an event registration as checked in or undo it, with the exact boolean semantics inline. It is clearly distinguishable from sibling registration tools (list_event_registrations, create_event_registration) which read or create rather than toggle attendance state.

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 explains what checked_in=true vs false do and that checked_in_guests applies only to guests-as-number registrations, which implies usage. However it never states prerequisites or exclusions (e.g. event must be in progress, registration must be confirmed), and names no alternative tool.

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 the membership side effect (Wild Apricot may create a membership invoice) and the flag that controls it. It does not describe the response body or error behavior for duplicate emails, though the schema notes uniqueness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the core action, then the member path, then the custom-field hint and endpoint. No filler and nothing 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 create tool with no output schema, the description covers the mutation's side effects and the member-vs-contact branch, which are the main agent decision points. It omits what the call returns (e.g. the new contact id), which an agent would otherwise need to chain 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 100%, so the baseline is 3, but the description adds cross-parameter logic the schema cannot express: membership_enabled must be paired with membership_level_id, and the recreate_invoice interaction. That is genuine semantic value beyond field-level descriptions.

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 contact') and extends scope precisely with the member-creation path. It also names the underlying endpoint, making it trivially distinguishable from wildapricot_update_contact and wildapricot_get_contact.

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 conditional guidance: set membership_enabled=true plus membership_level_id to make a member, and recreate_invoice=false to suppress the invoice. It does not explicitly name alternative tools (e.g. update_contact) for the already-exists case, so it stops short of full when/when-not coverage.

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 are thin (only destructiveHint=true), so the description carries most of the burden. It adds the prerequisite that the contact must already exist and surfaces the underlying POST endpoint, but says nothing about duplicate registrations, permission/auth requirements, or the invoice side effect that recreate_invoice triggers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus one API-path line; the core action and its prerequisite lead, and the waitlist alternative follows. No filler or restatement of the title.

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 create tool with full schema coverage and no output schema, the description covers the main flow, the required prerequisite tool, and the waitlist variant. It leaves out edge-case behavior (duplicate handling, missing/closed registration type errors) but is otherwise adequate 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 description coverage is 100%, so every parameter is already documented in the schema. The description only echoes two of them (registration_type_id, on_waitlist) and adds no format, default, or interaction details beyond that baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Register an existing contact for an event') and adds the key constraint that exactly one registration type applies. It also names the sibling tool that supplies registration_type_id, letting an agent distinguish it from list_event_registrations and check_in_attendee without opening schemas.

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?

Points to wildapricot_list_event_registration_types as the source of a required id and notes that a waitlist entry is an alternative outcome, which is useful routing context. However, it gives no when-not guidance (e.g., what to do if the contact is already registered, or how this relates to check_in_attendee).

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 that only the 'current' account is fetched and references GET /accounts/{accountId}, implying the account is resolved from context rather than passed in, which is a small but real addition; it stops short of describing auth requirements 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?

Front-loaded single sentence that leads with the verb and scope, followed by a short API reference. The endpoint citation is mildly redundant but harmless; 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?

There is no output schema, so the description's enumeration of returned fields is valuable compensation. With no parameters and a readOnly annotation, the definition covers what an agent needs for this simple fetch, though it does not mention pagination or error cases (not applicable here).

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The description correctly communicates that no account identifier is supplied.

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 ('Fetch the current account's details') and enumerates the returned fields (name, domain, time zone, currency, billing plan, contact limit), which makes the tool's scope concrete. It does not explicitly distinguish itself from the sibling wildapricot_list_accounts, 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?

Usage is only implied by the word 'current' — there is no explicit when-to-use statement or comparison to the sibling list_accounts. An agent can infer this is the single-account read, but nothing is spelled out.

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 adds useful return context (all field values, membership level and status) and explains the extended_membership_info switch, but says nothing about error behavior for a missing/invalid contact_id or any 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?

Three short sentences with the core verb and payload front-loaded. The trailing raw endpoint restatement ('Wild Apricot: GET /accounts/...') is marginally useful routing info but is essentially redundant given the tool already targets that 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 two-parameter read with no output schema, the description does describe the shape of the returned data, which is the main gap-filler. It still omits not-found/error behavior and pagination/expansion caveats, leaving the agent under-informed on edge cases.

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 both parameters are already documented in the schema, making 3 the baseline. The description only restates the extended_membership_info purpose (pending order, invoice, allowed actions), adding little beyond the schema text.

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 ('Fetch one contact or member') and names the returned payload (all field values, membership level, status), which implicitly contrasts with the sibling list_contacts. It stops short of naming an alternative tool explicitly, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to reach for this tool versus wildapricot_list_contacts, update_contact, or check_in_attendee. Usage is only inferable from 'one contact'; no prerequisites, no exclusions, no alternatives 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 declares the safety profile, so the description is not obligated to restate it. It does add useful beyond-annotation context by disclosing the composition of the returned payload (description, registration types, registration fields, sessions, counts, totals paid/due), which is the main behavioral unknown for a detail 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?

A single front-loaded sentence leads with the verb and enumerates the payload, followed by a compact endpoint reference. No sentence is wasted and nothing is 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?

With no output schema present, the description compensates by listing the returned sub-resources, which is the most important missing structure for a detail fetch. Minor gaps remain around behavior when the event_id does not resolve, but for a simple read-only lookup this is close to 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?

There is only one parameter, event_id, and schema description coverage is 100%, so the schema already carries the full burden. The description adds no format, range, or sourcing guidance for the id beyond what the schema states, 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 uses a specific verb and resource ('Fetch one event with its details') and enumerates exactly what that detail includes, so the agent knows it is a single-record retrieval rather than a list. It does not explicitly name the contrasting sibling list_events, leaving that differentiation to inference from the name.

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 rather than stated: 'one event' hints that this is the lookup-by-id counterpart to list_events, but there is no explicit 'use this when you already have an event id' guidance or any exclusion. For a simple single-parameter read tool this is the minimum viable level.

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 genuinely useful behavior beyond the annotations: it discloses the return content (contact ids matched 'currently'), which matters because no output schema exists. It stops short of noting pagination or result-size 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?

Two sentences with the core behavior front-loaded and no wasted preamble. The trailing REST endpoint reference is arguably redundant metadata, but it is compact and potentially useful for API-oriented callers.

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 correctly compensates by stating what is returned (matching contact ids). For a two-parameter read tool with readOnlyHint annotations, the essential information is present; only edge-case behavior like result limits or archived-contact interaction is left unstated.

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

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

Schema description coverage is 100%, so both saved_search_id and exclude_archived are already documented in the schema. The description adds no syntax, format, or constraint detail beyond what the schema supplies, 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 states a specific verb ('Run') and resource ('one saved search') and clarifies the output ('return the ids of the contacts it currently matches'). This clearly separates it from the sibling wildapricot_list_saved_searches, which enumerates searches rather than executing 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 implied by the phrasing 'Run one saved search,' but there is no explicit guidance on when to prefer this over alternatives or on the prerequisite of obtaining a saved_search_id from list_saved_searches. The agent must infer the workflow.

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 real value beyond that: it discloses the access scope ('this API key can reach'), the concrete fields returned, and the underlying endpoint (GET /accounts). It stops short of describing result limits or pagination.

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 plus a short endpoint reference, with the core purpose and scope front-loaded and the health-check use case following. Every clause carries information; no 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 parameters and no output schema, the description compensates by naming the fields a caller can expect back (id, name, primary domain, currency, contact limit), which is exactly the missing structured information. Nothing needed to call this 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?

The tool takes zero parameters, so there is nothing to document and the schema is trivially complete; per the baseline for 0-param tools this sits at 4. The description adds no parameter guidance because none is needed.

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 the Wild Apricot accounts this API key can reach') and immediately distinguishes scope from the singular get_account sibling by enumerating the returned fields (id, name, domain, currency, contact limit). An agent can tell what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for use: 'A cheap way to confirm the key works,' which signals a low-cost validation/health-check purpose. It does not, however, explicitly name an alternative or state when not to use it (e.g., to fetch a single account's detail, use get_account), so it falls short of the full 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 covers the safety profile, and the description adds little beyond that – essentially restating the operation and naming the underlying endpoint. It does not mention default date behavior, pagination semantics, or the practical limits on querying history (the 100-record cap lives only 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?

Two compact sentences with the scope stated first and the API endpoint appended as supporting detail. No padding, though the endpoint path is arguably redundant for an agent that has 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 simple read-only list tool with no output schema, the definition is minimally adequate. It does not explain return shape, ordering, or how paging interacts with the date window, which an agent would need to page results reliably.

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 top, skip, start_date and end_date are already fully documented with bounds and format patterns. The description's 'within a date range' adds nothing beyond what start_date/end_date descriptions provide, so the baseline 3 is warranted.

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 ('audit log items') and clarifies the record types returned (membership changes, payments, invoices, admin/member activity), which helps separate it from siblings like wildapricot_list_payments or wildapricot_list_invoices. It stops short of explicitly contrasting with those siblings, but the 'audit log' framing is clear.

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 only usage cue is 'within a date range', which hints at date-scoped queries but gives no when-to-use guidance relative to alternatives. An agent cannot tell from this text whether to reach for the audit log or the dedicated payments/invoices listing tools when investigating a specific transaction.

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 declare readOnlyHint=true, so safety is covered. The description adds behavioral context beyond annotations by detailing what the returned definitions include (searchable via $filter, editable) and specifying the underlying Wild Apricot endpoint GET /accounts/{accountId}/contactfields.

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 plus a short endpoint reference. The purpose is front-loaded, and every sentence adds useful information 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 simple listing tool with no parameters and no output schema, the description covers purpose, returned content, usage, and the underlying API call. An agent has everything needed to invoke 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?

The tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the schema is empty.

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 the contact and membership field definitions.' It further specifies the contents (names, system codes, types, allowed values, searchable/editable), clearly distinguishing it from sibling tools like get_contact or list_contacts.

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?

Provides a clear use case: 'Use it to build filters and field_values.' It does not name alternatives or state when not to use it, but the context is sufficient to know when this tool is relevant.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond that: synchronous execution ($async=false) and the backing REST endpoint. It does not describe the response shape, but the read-only nature and sync behavior are the key facts.

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 mode-selection distinction. The API endpoint citation is marginally redundant for tool selection but harmless and confirms 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?

Given 8 optional params, no output schema, and full schema coverage, the description supplies what the schema cannot: the choice logic between the two query styles and query syntax examples. Remaining params (count, ids_only, select, sort) are adequately documented in the schema itself.

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 baseline is 3. The description goes further by explaining the semantics of the two most complex params (simple_query vs filter), including OData operator examples and pointing to wildapricot_list_contact_fields for field names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (search contacts and members) and even cites the underlying endpoint GET /accounts/{accountId}/contacts. It is distinguishable from get_contact and list_contact_fields, though it never names a sibling to explicitly contrast with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly routes between the two query modes: simple_query for substring matching vs filter for OData expressions, with concrete examples. It does not state when to prefer a different tool entirely (e.g. get_contact for a known id), so it stops short of explicit 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?

readOnlyHint=true already declares this is a safe read, so the bar is lower. The description adds the returned field set and the underlying REST endpoint (GET /accounts/{accountId}/donations), which is useful context, but says nothing about paging behavior or default result size beyond what the schema states.

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: identity and returned fields first, optional filter and endpoint last. No filler or repetition.

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 no output schema, the description covers purpose, fields and the date filter adequately. Minor gaps remain around pagination defaults and whether results are capped in practice, but nothing blocks 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 description coverage is 100%, so top, skip, ids_only, start_date and end_date are all already documented. The description only reinforces the date-range usage, adding no new syntax or semantics. 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+resource ('List donations') and enumerates the returned fields (donor, amount, date, comments, donation field values), so an agent knows exactly what it gets. It does not explicitly distinguish itself from sibling list tools like list_payments or list_invoices, which is the only thing keeping it from 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?

'optionally within a date range' implies the one conditional usage mode, but there is no explicit when-to-use/when-not guidance and no routing to an alternative sibling. 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?

The readOnlyHint annotation already carries the safety profile, lowering the bar. The description adds the returned field set and the backing endpoint (GET /accounts/{accountId}/eventregistrations), which is useful context, but it says nothing about pagination, result volume, or the fact that both id filters are optional.

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 states purpose, scope, and return fields, followed by the endpoint reference. Well-sized with no filler, though the trailing API path is of marginal value to an agent invoking 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?

With no output schema, the description helpfully enumerates the fields returned, and five fully-covered optional params carry the invocation detail. It omits pagination/result-limit behavior, which is the only notable gap for a list tool.

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 event_id, contact_id, and the three boolean flags are already fully documented in the schema. The description's event/contact framing reinforces the id params but adds no format or default information beyond what the schema provides, 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 uses a specific verb+resource ('List registrations') and clarifies the two scopes the tool covers — an event's attendee list or a contact's signups — with the returned data ('registration type, fee, paid, checked in, waitlist'). It is clearly distinguishable from create_event_registration and check_in_attendee, though it does not name any sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for the two invocation modes: pass an event to get an attendee list, pass a contact to see what they signed up for. There are no explicit exclusions or named alternatives (e.g. when to prefer list_event_registration_types), 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=true annotation already establishes the safety profile, so the description carries a lower burden. It usefully discloses the returned data shape (price, availability, limits, waitlist) and the underlying REST endpoint, but says nothing about isolation (e.g. event-scoped only), pagination, or auth requirements beyond what annotations provide.

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 core purpose front-loaded; nothing is wasted. The trailing REST endpoint notation is borderline noise for an agent but is compact enough not to harm 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?

For a one-parameter, read-only list tool with no output schema, the description covers what is listed and why it matters, which is sufficient to call it correctly. Minor gaps remain around pagination and event scoping but nothing blocking.

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 the single event_id parameter, so the schema already documents it fully and the baseline is 3. The description only echoes the parameter via the '?eventId=' endpoint fragment and adds no format 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 gives a specific verb and resource ('List an event's registration types (ticket types)') and even enumerates the fields returned (price, availability, limits, waitlist), which cleanly separates it from the sibling list_event_registrations. It stops short of explicitly naming or contrasting an alternative, so it lands just under a perfect score.

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 line 'You need a type id to register someone' implies the workflow context (call this before create_event_registration), which is useful implied usage. However, it never states when to prefer this over siblings like list_event_registrations or any exclusions/prerequisites, leaving tool selection to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds the underlying REST mapping, which is modestly useful context, but says nothing about paging behavior, result limits, or auth requirements beyond what the schema's top/skip already 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?

Front-loaded with the purpose, then immediately the filter examples, then the endpoint. Compact with essentially no filler; only the endpoint mapping is arguably redundant, but it is cheap and informative.

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 something about what is returned (a paged collection of event objects) or default paging behavior, and it does not. Six optional parameters are otherwise well covered by the schema, so this is adequate but not complete.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely adds meaning by showing concrete $filter syntax ("IsUpcoming eq true", "Tags in [workshop]", "Id in [1,2]") that the schema merely gestures at with a field list. This is exactly the kind of syntactic detail an agent needs to build a valid filter.

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 ("List events") and pins it to the underlying endpoint GET /accounts/{accountId}/events, so the agent knows exactly what collection is returned. It does not, however, differentiate itself from close siblings like wildapricot_get_event or wildapricot_list_event_registrations, so there is no explicit sibling 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?

There is no statement of when to use this tool versus get_event (single record) or list_event_registrations, and no guidance on paging strategy or when to prefer count/ids_only. The filter examples hint at usage patterns but are parameter syntax, not selection 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?

The readOnlyHint annotation already establishes this is a safe read. The description adds the upstream endpoint (GET /accounts/{accountId}/invoices), which is mildly useful context but says nothing about pagination limits, voided-invoice handling, or the response shape. With annotations carrying the safety profile, this is an adequate-but-thin contribution.

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 with zero filler; the filter scope is front-loaded and the endpoint reference is a compact trailing clause. Every part earns its place.

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

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

For an 11-parameter read-only list tool with full schema coverage and a readOnlyHint, the description covers the what and the filter surface well. The minor gap is that with no output schema, nothing is said about returned fields or paging behavior, though the top/skip schema descriptions partly compensate.

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 11 parameters are already documented in the schema, including the created-date semantics of start_date/end_date and the paid/unpaid toggles. The description restates these filters at a high level but adds no syntax, mutual-exclusivity, or interaction details beyond the schema, 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 a specific verb (List) and resource (invoices) and enumerates the available scoping filters — contact, event, event registration, paid/unpaid, created-date range. This cleanly separates it from the sibling list tools (list_payments, list_donations, list_event_registrations), so an agent can pick it 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?

The phrase "optionally for one contact, event or event registration, paid/unpaid only, or within a created-date range" tells the agent when each filter applies and that all are optional. It does not, however, name an alternative or state exclusions (e.g. when to prefer list_payments), so it falls 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the upstream REST endpoint and the returned field set, but says nothing about pagination defaults or result ordering, which is relevant given the top/skip parameters.

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 tightly written sentences, front-loaded with the verb and resource, with no filler. The trailing endpoint mapping is mildly redundant but cheap and useful for disambiguation.

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 a fully documented two-parameter schema and no output schema, the description is nearly sufficient. Inlining the returned fields (id, name, description) compensates for the absent 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%, so top and skip are fully documented in the schema with their ranges and paging intent. The description adds no parameter detail beyond that, which is the expected baseline when the schema carries the load.

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 (ad hoc member groups) and enumerates the returned fields. 'Ad hoc member groups' does distinguish it from sibling list_membership_levels, though the distinction is left implicit rather than spelled out.

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, and no mention of the sibling tools (e.g., list_membership_levels) an agent might confuse this with. 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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context; it does add the underlying endpoint (GET /accounts/{accountId}/membershiplevels) and the field set, but says nothing about permissions, pagination, or ordering.

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 sentence, front-loaded with the verb and resource, followed by the most decision-relevant attributes and the API reference. No 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 usefully previews the return fields, which is the main thing an agent needs for a zero-param listing. Minor gap: it never explains the accountId referenced in the endpoint, so the auth/account scoping model stays implicit.

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 tool takes zero parameters, so the baseline is 4 per the rubric. The description adds nothing to explain the accountId shown in the endpoint path, leaving a small ambiguity about whether the account is inferred from auth context.

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 ('List membership levels') and enumerates the salient fields returned (name, fee, renewal period, individual vs bundle, public applicability), which is enough to distinguish it from the nearby wildapricot_list_member_groups sibling without opening a 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?

Usage is only implied by the resource name; there is no statement of when to call this versus list_member_groups or list_contacts, and no prerequisite like accountId sourcing (even though the endpoint shows an accountId path parameter). Adequate for an obvious read-only listing, but no explicit routing guidance.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description confirms listing behavior and notes the optional unsettled filter, but adds nothing about pagination behavior or the 100-record cap beyond what annotations and schema already convey.

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: purpose first, then the GET endpoint reference. No filler. The endpoint detail is arguably redundant for an agent but not wasteful.

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 operation with 100% schema coverage, the description is adequate but thin. It omits pagination guidance (top/skip relationship, 100-cap implications) and doesn't distinguish this tool from invoice/donation listing siblings, leaving some ambiguity an agent could resolve incorrectly.

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% – every one of the 8 parameters is documented in the schema, including top/skip, dates, contact/event ids, ids_only, and unsettled_only. The description merely restates the filter dimensions already fully described in the schema, 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 a clear verb+resource ('List payments received') and adds the scoping dimensions (contact, event, unsettled, created-date range). It does not explicitly differentiate itself from siblings like wildapricot_list_donations or wildapricot_list_invoices, which an agent might confuse with payments.

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 usage context by naming the optional scoping filters, but never says when to choose this tool over list_donations, list_invoices, or get_contact. No explicit when/when-not guidance 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, so the safety profile is covered by structured data. The description adds useful context that the entries are admin-defined and lists the returned fields, plus the underlying GET endpoint. It does not mention pagination behavior or result limits, which keeps this at a solid-but-not-rich 3.

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 purpose and return fields front-loaded before the endpoint mapping. Every clause carries information and nothing 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?

With no output schema and no parameters, the description compensates by naming the return fields (id, name, description) and the scope of the search set. A mention of pagination or ordering would make it fully self-contained, but nothing essential to calling the tool 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?

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify, and the description correctly describes a no-argument enumeration of account-level saved searches.

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 ('contact saved searches defined by admins'), and the parenthetical enumerates the returned fields (id, name, description), so the agent knows exactly what comes back. It is naturally distinguished from the singular wildapricot_get_saved_search sibling by its plural list scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the tool name and the 'admin-defined' qualifier, which tells the agent these searches were configured by administrators rather than ad-hoc. However, there is no explicit when-to-use statement and no alternative sibling is named (e.g., routing to wildapricot_get_saved_search for a single definition).

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; the description adds genuine behavioral value by clarifying that the PUT-style call is semantically a partial update ('Only the fields you pass are sent'), which an agent could easily get wrong for a PUT endpoint. It still omits side effects such as invoice recreation when membership level changes, which the schema documents but the description does not surface.

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-load the action and the key partial-update caveat, with the API endpoint appended as a trailing reference. Nothing is wasted, though the endpoint citation is the least load-bearing element and could be dropped without loss.

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

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

With 10 parameters at full schema coverage, one required argument, and no output schema, the description covers the essentials an agent needs: what can be changed, that updates are incremental, and that the target must exist. Mitigating details such as the invoice-recreation default and the uniqueness constraint on email live only in structured fields, leaving a small gap for a destructive-flagged mutation tool.

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 nested field_values is already documented, and the description adds only a high-level grouping (names, email, membership level/status, custom fields). That grouping is a useful orientation but adds no syntax 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 and resource ('Update an existing contact') and enumerates the updatable surface (names, email, membership level/status, custom field values), which lets an agent separate it from create_contact and get_contact by verb alone. It stops short of explicitly naming a sibling or stating the precondition that the contact must already exist.

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?

'Update an existing contact' and 'Only the fields you pass are sent' imply when the tool applies and that it is a partial update, so an agent can infer the use case. There is no explicit when-to-use guidance, no statement of prerequisites beyond the name, and no routing away from alternatives such as create_contact for new records.

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