neon-crm

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

Annotations only carry destructiveHint=true; the description adds the genuinely important behavioral fact that Neon's Account Match may merge the new record into an existing account with the same name and email, which explains the destructive hint and warns the agent about duplicate-creation side effects. It also states the return value (new id). Missing auth/permission requirements, but strong for one annotation.

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

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

Three tight sentences with no filler: identity of the resource, the dedup/merge caveat with the sibling to check, and the return value plus endpoint. The merge warning, the most consequential detail, is not 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 19-parameter creation tool with no output schema, the description covers the two account shapes, the duplicate/merge hazard, and the returned id. It stops short of documenting the many address/contact fields (left to the schema, which is fine) and says nothing about permissions or validation failures, but nothing essential for correct invocation 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 all 19 fields, including that company_name is required for COMPANY. The description's type/company_name framing and the optional primary-contact note echo that, adding only marginal meaning beyond the schema. Baseline 3 applies 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?

States a specific verb and resource (create a constituent account) and enumerates the two supported shapes, INDIVIDUAL or COMPANY, so an agent can tell it apart from neon_update_account and neon_get_account. The 'Returns the new id' plus 'POST /accounts' phrasing pins down exactly what the operation is.

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?

Names a concrete precondition and alternative: check neon_list_accounts by email first, because Account Match may merge into an existing account with the same name and email. This is clear routing guidance, though it doesn't spell out the converse (prefer neon_update_account when the account already exists) or any when-not-to-use case.

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 annotation declares destructiveHint=true, but the description describes an additive creation operation ('Create an activity'). This is a direct semantic conflict: an agent cannot reconcile 'create new record' with 'may perform destructive updates.' The endpoint and return-id details are useful, but the annotation contradiction forces a score of 1.

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

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

Front-loads the core action, then required fields, linkage, return value, and endpoint in a compact structure. No sentence 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 create tool with 11 parameters and no output schema, the description covers required fields, how to obtain lookup IDs, account/user linkage, and the return shape. Optional fields are left to the schema, which is reasonable, though the destructive annotation conflict is not addressed.

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. The description restates required fields and lookup sources (neon_list_properties for time zones and statuses) that the schema itself already includes, adding little new parameter meaning. Baseline 3.

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 an activity'), enumerates supported subtypes (call, meeting, note, task), and distinguishes itself from sibling get/update/list tools by clearly being the creation operation.

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 when to use it — logging an interaction or scheduling a task — and names required fields plus where to source lookup IDs. It does not explicitly exclude or compare to neon_update_activity, so it falls short of full when-not 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 establish readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral context by describing the return payload (individual/company account, contact, addresses, consent, custom fields, membership status, timestamps) and the underlying GET endpoint, which is valuable because no output schema exists.

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

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

Two sentences, front-loaded with the action and scope, then the return details. No filler; every clause contributes 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?

No output schema is present, so the description must compensate by explaining returns, which it does with a useful field inventory. It does not cover not-found or error behavior, but for a read-only single-record fetch with a fully documented parameter and readOnlyHint, it is nearly complete.

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

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

Schema coverage is 100%, and account_id is documented there as "The account id." The description does not add format, validation, or other semantic detail beyond the endpoint path, so the schema carries the parameter meaning.

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 account in full") and distinguishes the single-account scope from sibling listing/search tools. The returned entity types (individualAccount or companyAccount) and field list make the purpose unambiguous.

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

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

Implies usage when a single account is needed and an id is available, but never states when to use this over neon_list_accounts, neon_search, or neon_get_organization_profile. No prerequisites, exclusions, or 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, so the description's remaining job is to add context. It does add the return-field inventory and the underlying endpoint (Neon: GET /activities/{id}), which is genuinely useful since there is no output schema. It says nothing about behavior for a missing/invalid id (e.g. 404) or rate limits, so it is solid but not rich.

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

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

One front-loaded sentence that names the resource, defines it, and lists the payload, followed by the endpoint. No filler or redundancy.

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

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

With no output schema, the field enumeration is the right compensation and covers what the caller receives. For a single-id read with annotations already declaring read-only behavior, little else is strictly needed, though error handling for an invalid id 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 100% for the single activity_id parameter, so the schema already carries the burden and the baseline of 3 applies. The description only restates the id via the REST path template and adds no format or sourcing guidance beyond it.

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 activity') and disambiguates the entity with a parenthetical definition ('a logged interaction or task'). It also enumerates the payload fields (subject, note, dates, linked accounts, assigned users, status, priority), so an agent knows exactly what it gets that the list/search siblings would not.

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 or when-not guidance and no named alternative, even though siblings such as neon_search or a list-activity tool could also surface activities. The only implicit signal is the required activity_id, which implies 'use when you already have an id' but is never stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the specific fields retrieved and a Neon GET endpoint, which is useful behavioral context beyond the annotation, though it does not discuss error behavior or auth requirements.

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

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

Two tight sentences with the core action front-loaded and no filler. The field list and endpoint reference are both informative and efficient.

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

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

No output schema exists, so the description usefully enumerates the returned fields. With the single parameter fully covered by the schema and readOnlyHint covering safety, the definition is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so campaign_id is fully documented in the schema. The description references '/campaigns/{id}' but adds no syntax, format, or constraint details beyond what the schema already provides; baseline 3 is appropriate.

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

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

States a specific verb ('Fetch one campaign'), clearly scopes it to a single record versus the sibling neon_list_campaigns, and enumerates the returned fields. The endpoint reference further pins down the 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?

The singular 'one campaign' implies usage when a campaign_id is available, but the description never states when to choose this over neon_list_campaigns or what prerequisites exist. The usage context is inferable but not explicit.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description goes further by enumerating the returned payload (amount, date, fund, campaign, purpose, source, tribute, soft-credit solicitor, payments, status), which is genuinely useful since no output schema exists. It omits error/not-found behavior and auth requirements, keeping it short of a 5.

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

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

Two tight sentences that are front-loaded with the action and resource, then the payload contents. The trailing 'Neon: GET /donations/{id}' is mild redundancy with the tool name and schema, but overall there is little 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 single-parameter read tool with readOnlyHint and no output schema, the definition supplies the resource scope, the required id semantics, and a preview of returned fields. Only edge-case behavior (not found, permissions) is missing, which is acceptable at this complexity.

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

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

Schema description coverage is 100% and there is a single required parameter, so the schema already documents donation_id fully. The description's 'GET /donations/{id}' confirms the id path semantics but adds no format, constraint, or sourcing detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (Fetch) and resource (one donation), and the singular phrasing plus the enumerated payload distinguishes it from sibling list tools like neon_list_account_donations and the broader neon_search. It does not explicitly name a sibling to route against, but the singleton scope is unambiguous.

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

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

The 'one donation' phrasing and the required donation_id imply usage (fetch a known record), but there is no explicit statement of when to prefer this over neon_search or neon_list_account_donations, nor any prerequisites. 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?

readOnlyHint=true already tells the agent this is a safe read, so the burden is lower. The description does add value by listing the returned field groups, which matters given there is no output schema, but it says nothing about not-found behavior, error handling, or authentication requirements.

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

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

Two tightly-packed sentences: the return payload first, then the underlying endpoint mapping (GET /events/{id}). 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?

For a one-parameter read tool with no output schema, the description compensates well by enumerating returned fields, and the included API endpoint aids disambiguation. It falls short only on failure modes and lifecycle details, which are minor 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?

With a single parameter at 100% schema description coverage, the schema fully documents event_id. The description adds no format, source, or constraint detail beyond what the schema already provides, which is the expected 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 ('Fetch one event') and enumerates the fields returned (name, summary, dates, location, capacity, category, campaign, registration and financial settings), so the agent knows exactly what it gets back. It implies single-record scope versus the neon_list_events sibling, but never names that sibling explicitly to differentiate.

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 word 'one' implies this is for retrieving a single known event rather than enumerating, which nudges toward neon_list_events for browsing. However, there is no explicit when-to-use or when-not-to-use statement, no mention of prerequisites, and no reference to 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=true, so the safety profile is covered. Because there is no output schema, the description's enumeration of what comes back (level, term, dates, fee, status, auto-renewal, sub-members, payments) meaningfully adds behavioral context about response content.

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 segments, with the action and target front-loaded before the field list. The field enumeration is long but earns its place as a proxy for the absent output schema.

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

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

For a single-parameter read tool, the description covers what is fetched and what the response contains, and the annotations cover the safety profile. Nothing critical is missing, though error behavior for a nonexistent membership_id is unspecified.

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 a single required parameter at 100% schema description coverage, so the schema already documents membership_id fully. The description only restates it via the REST path (/memberships/{membershipId}), adding no new semantics, which matches the baseline 3 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 states a specific verb and resource ('Fetch one membership') and enumerates the returned fields, so an agent knows exactly what it retrieves. The singular 'one' implicitly separates it from neon_list_account_memberships, though no sibling is named explicitly.

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

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

Usage is only implied: the required membership_id and the 'one membership' framing make the single-record lookup case obvious, but the description never states when to prefer this over neon_list_account_memberships or what happens with an invalid/missing id.

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 only needs to add value — which it does by disclosing that the call is scoped to "these credentials" and is cheap enough to use as a credential/org-ID sanity check. No permission, cost, or side-effect details beyond that, but none are needed for a zero-arg read.

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 purpose and followed by the practical use case plus the endpoint. Every clause earns its place with no repetition 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 a zero-parameter read tool with no output schema, the description fully compensates by listing the returned fields and the underlying endpoint, so an agent knows exactly what it gets back without needing a 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; 4 is the baseline for a zero-parameter tool.

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 (fetch) and resource (the organization these credentials belong to), and enumerates the returned fields (name, org ID, app URL), so it is immediately distinguishable from the account/activity/campaign siblings. The API path is also named.

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?

"A cheap way to confirm the org ID and API key work" gives a concrete when-to-use scenario (credential validation) that an agent can act on. It stops short of explicitly stating when not to use it or naming an alternative, but the context is clear.

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, so the safety profile is covered. The description adds a genuinely behavior-relevant fact not present in structured fields: results are returned newest first by default, plus it discloses the underlying Neon endpoint (GET /accounts/{id}/donations), which helps predict pagination/response shape.

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, zero filler, with the core purpose and default ordering front-loaded before the optional endpoint note.

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 no output schema, the description compensates well by naming the returned fields (amount, date, fund, campaign, purpose, status, payments) and the default sort, while the schema fully documents pagination and sort parameters. Minor residual gaps: no statement of pagination depth or result caps.

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 adds meaning beyond the schema by stating the default ordering ('newest first'), which clarifies the effective values of sort_column/sort_direction when they are omitted, something the enum-only schema does not specify.

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 with scope ('List one account's donations') and enumerates the returned fields, so an agent can tell it apart from neon_get_donation (single) and neon_list_accounts (different resource). It does not explicitly name a sibling alternative, keeping it 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 account-scoped phrasing implicitly signals when to use this list endpoint versus a single-record get or a cross-account search, but there is no explicit when-to-use, prerequisite, or named alternative. Usage must be inferred rather than read.

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 description adds the REST endpoint and optional event filtering, which is useful context. However, readOnlyHint=true already covers the safety profile, and the description does not disclose pagination behavior, sorting semantics, or auth requirements.

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

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

Two sentences, front-loaded with the core action and scope, followed by a compact API mapping. No wasted text.

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

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

For a simple read-only list tool with full schema coverage and no output schema, the description is nearly sufficient. The main remaining gap is that it does not route the agent between this account-scoped list and the broader sibling 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 the schema already documents all four parameters. The description reinforces the event_id filter but does not add syntax, defaults, or behavioral 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?

States a specific verb and resource: list event registrations for one account, with an optional single-event scope. This distinguishes it from the sibling list_event_registrations, which is not account-scoped.

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 the usage context by saying 'one account has made, optionally for a single event', but it does not explicitly name alternatives or state when to prefer this tool over neon_list_event_registrations or neon_get_event.

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

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

The readOnlyHint annotation already establishes this as a safe read, so the description's added value is limited to enumerating returned fields and noting the status values (SUCCEEDED/FAILED). It says nothing about pagination behavior or the default result set size despite page_size and current_page parameters existing.

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

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

Front-loads the core purpose and the returned fields in one dense sentence, then closes with the underlying endpoint. Every clause carries information; the endpoint citation is marginally extraneous but cheap and useful for API-literate agents.

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 compensates by listing the fields returned and example status values. Combined with full schema coverage for the seven parameters and the readOnly annotation, the definition covers what an agent needs, though pagination defaults remain 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, setting the baseline at 3. The description restates two filters (active, primary active) that the schema already explains, adding no syntax or default-behavior detail beyond it.

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 one account's membership history') and enumerates the returned data (level, term, dates, fee, status, auto-renewal). It implicitly separates itself from the singular neon_get_membership and from neon_list_membership_levels, but never names a sibling explicitly to make the distinction 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 hints at selection via 'Filter to active or the primary active membership,' which tells the agent these filters exist but not when one should be preferred over the other. There is no statement of when to use this versus neon_get_membership or the account-listing siblings, so usage is only implied.

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

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

readOnlyHint=true already establishes the safety profile, and the description adds real value beyond that by disclosing the return shape (accountId, names, email, userType) and the underlying endpoint. It says nothing about pagination semantics or result caps, which the schema only partially implies.

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

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

Three short sentences, front-loaded with the core action and filters before the return fields and endpoint. The final 'Neon: GET /accounts.' line is marginal but genuinely useful for an API-wrapper tool, so almost 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?

With no output schema, the description carries the burden of describing returns and does so concisely; all six parameters are covered by the schema, the read-only nature is declared by annotations, and the search alternative is pointed to. Nothing an agent needs to call this 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 all six parameters are already documented in the schema. The description restates the filterable fields (email, name, type) without adding any format, matching, or interaction guidance beyond what the schema already provides — 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 ('List constituent accounts'), clarifies scope (individuals and companies), enumerates the filter dimensions, and names the sibling (neon_search) it is not. An agent can distinguish it from neon_get_account and neon_search without opening any schema.

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

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

Explicitly routes richer queries to neon_search, which gives a clear alternative-selection rule. It does not, however, state when-not to use this tool or any prerequisites for the filtered lookups, 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?

The readOnlyHint=true annotation already declares this is a safe read, so the description's burden is reduced. It adds the returned column set and the underlying API endpoint (GET /campaigns), but says nothing about pagination, result size, or ordering 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?

One short sentence plus a compact endpoint reference; front-loaded and free of filler. The API mapping line earns its place by tying the tool to the documented Neon 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 zero-parameter read tool with no output schema, the description is nearly sufficient because it enumerates the fields returned. The only real gap is pagination/result-set behavior, which matters for any 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond the returned fields it already 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 and resource ('List fundraising campaigns') and even enumerates the returned fields (id, code, name, status), making it clearly distinguishable from the singular neon_get_campaign sibling. It is clear but does not explicitly name that sibling, so it stops short of a 5.

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

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

There is no when-to-use guidance, no statement about filtering/scoping, and no mention of the alternative neon_get_campaign for fetching a single campaign. The listing intent is only implied by the verb 'List'.

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 read-only safety profile is covered. The description adds the underlying Neon endpoint and the shape of each returned registration, but says nothing about pagination limits, default sort, or result volume — modest additional value, appropriate for a 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?

A single tight sentence with the core purpose front-loaded and the returned fields listed compactly; the trailing endpoint reference is short and useful for tracing. No padding or redundancy.

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

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

For a read-only list tool with a fully described schema and annotations covering safety, the description supplies what remains: the contents of each registration record, compensating for the absent output schema. Missing only pagination/sort defaults, which the schema partially covers.

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 five parameters (including page/page_size semantics and the sort_direction enum) are already documented in the schema. The description only hints at registrant_account_id as an optional narrowing filter, adding little 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 and resource ('List the registrations for one event') and enumerates the data returned (registrant account, tickets/attendees, amount, payments), which lets the agent distinguish it from the sibling neon_list_account_event_registrations scoped per account. However, it never names that sibling explicitly, so the differentiation is left to inference from the tool 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?

The phrase 'Optionally only one registrant' signals that registrant_account_id is a filter, implying usage, but there is no explicit when-to-use versus the account-scoped sibling or any exclusion/precondition guidance. Usage must be inferred from the name and the field list.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds two pieces of real context beyond annotations: date format (YYYY-MM-DD) and the legacy-events-only API limitation, plus the underlying endpoint. It says nothing about pagination behavior or result ordering, so it is adequate but not rich.

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

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

Two tight sentences, filtering scope front-loaded, with the legacy-API caveat appended where it belongs. The trailing endpoint reference ('Neon: GET /events') is mildly redundant but cheap.

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 fully documented parameters, no required args, and no output schema, the description covers purpose, filter surface, date format, and a meaningful data-scope caveat. Only pagination/ordering behavior 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 description coverage is 100%, so the schema already documents all ten parameters including their filter semantics. The description's only add is the YYYY-MM-DD format note, which the schema also states for the date fields. 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+resource ('List events') and enumerates the filter dimensions, which separates it from the singular neon_get_event and from neon_list_event_registrations. It does not name a sibling explicitly, but the scope ('Only Neon's legacy events') is distinctive enough to route an agent.

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

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

The description lists filters but gives no when-to-use guidance: nothing says when to prefer this list tool over neon_search or neon_get_event, and no prerequisites or exclusions are stated. Usage is only implicitly derivable from the filter list.

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 that this is a safe read operation. The description adds the returned field list and the underlying GET endpoint, but says nothing about pagination behavior, permissions, or rate limits beyond what the schema and 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 compact sentences with no wasted wording. The purpose is front-loaded, followed by the returned fields and endpoint reference.

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 no output schema, the description usefully enumerates the fields returned (id, code, description, rank, type, status), which helps the agent understand the response shape. Pagination details and return structure are only implied through the schema, but the essentials are covered.

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

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

Schema description coverage is 100%, so the three optional parameters (status, page_size, current_page) are fully documented in the schema. The description adds no parameter-level semantics beyond indicating the resource being listed.

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 (organization's membership levels), and enumerates the returned fields. It does not explicitly contrast with the similarly named sibling neon_list_account_memberships, but the resource scope is clear enough to distinguish levels from account memberships.

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 name and purpose: use this to retrieve the organization's membership levels. There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives or prerequisites.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the upstream API shape (GET /properties/{name}) and the cross-tool dependency on returned ids. It does not discuss pagination or ordering, which keeps it from a 5.

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

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

Front-loaded with the core purpose, followed by the category list and endpoint. The long comma-separated enumeration is dense but every item maps to an enum value, so little 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 single-param read-only lookup with no output schema, the description tells the agent what it returns (ids) and why it matters. Nothing critical is missing, though return shape/pagination is 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 coverage is 100% with an enum, so the schema already carries most semantics (baseline 3). The description adds value by glossing the categories and flagging that systemTimezones feeds neon_create_activity, which the schema does not convey.

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

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

States a specific verb ('List') and resource ('organization's lookup lists') and immediately characterizes the return as the ids other tools need. The enumeration of list categories makes it unmistakable against siblings like neon_list_accounts or neon_list_campaigns.

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?

Frames usage as supplying ids that other tools require, and explicitly ties systemTimezones to neon_create_activity. It stops short of stating when not to use it or naming a competing alternative, but the use context is clear.

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. Beyond that the description discloses what each kind actually returns (operators for filter fields, custom field numeric ids for output columns) and even names the underlying REST paths, adding useful behavioral context without needing to discuss caching or pagination for a metadata lookup.

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 front-loaded sentences with no filler: the purpose and the kind split come first, the mandatory ordering call comes last. Every clause carries an actionable 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?

There is no output schema, so the description compensates by summarizing the return payload for each kind. Combined with full schema coverage and annotations, an agent has everything needed to call this prerequisite tool correctly.

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

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

Schema description coverage is 100% with both params enum-constrained, so the baseline is 3. The description goes further by explaining the semantic difference between the two enum values and what each returns, which meaningfully supplements the terse schema descriptions ('Filter fields or output columns').

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 ('Discover') plus resource ('the field names neon_search accepts') and disambiguates the two modes by explaining what kind=searchFields yields (filterable fields with allowed operators) versus kind=outputFields (returnable columns, standard plus custom numeric ids). An agent can distinguish this from the many neon_get_*/neon_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?

It explicitly states the ordering constraint 'Call this before neon_search', naming the sibling tool that consumes the result. This is a clear when-to-use rule that routes the agent correctly rather than leaving sequencing 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 cover read-only safety, and the description adds genuinely useful context beyond them: the underlying POST /{resource}/search call, the single-concurrent-search limitation, and the shape of the returned searchResults rows with pagination totals. Return-format detail is a real value-add for a no-output-schema 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?

Three densely packed sentences, front-loaded with what is searched, then inputs, then output/constraint. No wasted filler, though the density is near the upper limit of readable.

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 responsibly describes the return shape (rows keyed by output field name plus pagination totals) and covers the concurrency caveat. An agent has enough to invoke correctly, though noting the ANDed-filter behavior is left 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 coverage is 100%, so the baseline is 3, but the description adds meaning by explaining the string-vs-integer convention for output_fields (standard field names vs custom-field ids) and pointing to neon_list_search_fields for valid values, which the schema alone does not convey.

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

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

Names a specific verb (report-style search) and enumerates exactly which resources are searchable (accounts, donations incl. pledges/pledge payments, activities, events). This clearly distinguishes it from the many neon_list_* and neon_get_* siblings that retrieve without filter criteria.

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

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

Tells the agent what inputs are needed and where to get them (field names/ids from neon_list_search_fields), and warns of the one-concurrent-search-per-endpoint constraint. It stops short of explicitly stating when to prefer this over neon_list_accounts or neon_get_donation.

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

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

With only destructiveHint=true available, the description carries meaningful extra context: PATCH/partial-update behavior, the type-must-match constraint that will cause a failure if violated, and the exclusion of addresses. It doesn't cover permissions, error behavior, or which values are irreversible, so it isn't exhaustive.

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 sentences, all front-loaded and information-dense: field list first, then update semantics, then the constraint, then the exclusion and API endpoint. Nothing is padding, though the trailing "Neon: PATCH /accounts/{id}" is the weakest element.

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 12-parameter mutation tool with no output schema and thin annotations, the definition covers the essentials an agent needs: what can change, that it is a partial update, and the type precondition. Missing error/auth context keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already documents all 12 parameters, including the enum on type and the field mappings. The description's field list is a helpful summary but adds no syntax or format 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 (Change) and resource (account) plus an explicit list of the mutable fields (name, email, job title, company name, opt-out flags). The scoping line "Addresses are not edited here" further sharpens what the tool does and does not touch.

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

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

Gives real preconditions: partial-update semantics ("only the fields you pass are changed"), the requirement that type must match the account, and a pointer to neon_get_account to check it. It also excludes addresses. It stops short of an explicit when-to-use-this-vs-alternative statement, but the guidance is concrete.

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

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

Annotations only declare destructiveHint=true. The description adds genuinely useful behavioral context beyond that: it is a PATCH-style partial update where unspecified fields are preserved, which is critical for a mutation tool and not derivable from the annotations alone. It does not, however, note irreversibility or permission requirements.

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

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

Two tight sentences with zero waste. The mutable-field list and the PATCH constraint are front-loaded, and the endpoint reference is a compact trailing 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 mutation tool with destructiveHint but no output schema, the description covers the actionable essentials: what can be changed, that it is partial, and the underlying endpoint. It omits permission/auth prerequisites and confirmation that fields not passed are untouched, which would round it out.

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 each parameter (including the enum for priority and the note-replacement behavior). The description repeats the field list but adds no syntax or format 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?

The description names a specific verb ('Change') and resource ('an activity') and enumerates the mutable fields (subject, note, status, priority), so an agent can immediately tell it apart from neon_get_activity and neon_create_activity. It stops short of explicitly naming siblings, so it is clear but not maximally differentiated.

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 'when to use this vs alternatives' statement. The PATCH note ('Only the fields you pass are changed') implies the intended partial-update usage, but the agent is left to infer when an update is preferable to a create or get call.

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