Neon CRM MCP by usefulapi

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

Annotations only give destructiveHint=true; the description carries the real burden and delivers: it warns that Account Match may merge the new account into an existing one with the same name/email, states it returns the new id, and names the underlying POST /accounts call. The merge side effect is exactly the kind of non-obvious behavior an agent needs, though auth/permission requirements are not mentioned.

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 dense sentences with zero waste: the type distinction is front-loaded, the merge caveat follows, and the return/endpoint close it out. Every clause earns its place.

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

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

With 19 parameters fully covered by the schema and no output schema, the description covers the remaining gaps: what it creates, the merge risk, and the returned id. It is essentially complete, with only minor omissions like permissions or partial-failure behavior.

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 with meanings, including the company_name-required-for-COMPANY relationship. The description repeats some of this (company_name, optional primary contact) without adding format or syntax 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 and resource ('Create a constituent account') and immediately disambiguates the two account flavors (INDIVIDUAL vs COMPANY) with the fields each implies. This cleanly separates it from siblings like neon_update_account and neon_get_account.

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 directs the agent to check neon_list_accounts by email first because of Account Match merging, which is actionable when-to-use guidance with a named sibling. It stops short of stating when-not to use it (e.g., prefer neon_update_account for an existing account), so it is clear but not exhaustive.

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

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

Annotations only supply destructiveHint=true and a title, so the description does meaningful work: it discloses the return value ('Returns the new id') and the Neon endpoint (POST /activities), plus the lookup dependencies for derived ids. It omits any mention of permission requirements or side effects on linked accounts/users, which keeps 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?

Three tightly packed sentences that front-load the action and the required inputs, then the return value and endpoint. No filler, no restated 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?

With no output schema, the description correctly states the return value (the new id) and enumerates the required inputs and id-lookup helpers, so an agent can construct a valid call. Minor gaps remain around linking semantics for account_ids/system_user_ids, but nothing essential 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 11 parameters including the timezone/status lookup hints. The description largely restates required fields and adds no format or validation detail beyond what the schema provides, which is the baseline-3 case.

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') and clarifies the two modes: logging a constituent interaction or scheduling a task. This clearly distinguishes it from siblings like neon_get_activity, neon_update_activity, and neon_create_account.

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

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

Explains the prerequisites for a successful call (subject, start date, time zone id, status id, priority) and routes the agent to neon_list_properties for the timezone and status enumerations. It does not explicitly say when to prefer this over neon_update_activity, but the create/update split is unambiguous from the verb.

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 only readOnlyHint=true, so the description carries real weight here. It adds substantive behavioral context by disclosing the response shape — the individualAccount/companyAccount variants and the bundled contact, address, consent, custom field, membership and timestamp data — plus the underlying Neon GET endpoint. It doesn't cover auth requirements or not-found 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?

One sentence plus an endpoint reference, with the core action front-loaded. The field enumeration is long but earns its place since there is no output schema to describe the return payload.

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 spells out the returned entity and its components, and the single parameter is fully covered by the schema. Gaps are limited to error/not-found and permission behavior, which are minor for a read-only lookup 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% for the single account_id parameter, so the schema already does the documenting. The description adds no format or syntax detail about the id beyond what the schema states, which is the expected baseline of 3 when the schema is complete.

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 a scoped resource (one account), and the word 'one' implicitly separates it from neon_list_accounts. It even enumerates the return shape (individualAccount vs companyAccount) with sub-resources, so an agent knows exactly what it gets. It stops short of naming a sibling explicitly, which keeps it out of the top band.

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?

No explicit when-to-use or when-not statement, and no alternatives (neon_list_accounts, neon_update_account) are named. Usage is nonetheless implied by the combination of 'one account' and the required account_id, which tells an agent this is the single-record read path.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered, and "Fetch" is consistent with a read-only operation. The description adds the concrete payload shape an agent can expect, but says nothing about not-found/error behavior, permissions required, 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?

One front-loaded sentence led by the verb, followed by a compact endpoint note. The field list is dense but informative rather than redundant, and there is 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 compensates by listing the fields the activity record contains, which is genuinely useful. For a one-parameter read tool this is nearly sufficient; only error/not-found handling and permission requirements are unaddressed.

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

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

There is a single parameter with 100% schema description coverage, and the schema already documents activity_id. The description only reinforces this indirectly via the REST path template "GET /activities/{id}", adding no format, source, or constraint 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 and resource ("Fetch one activity") and even defines the domain term ("a logged interaction or task"), which removes ambiguity for a word like "activity". The enumeration of returned content (subject, note, dates, linked accounts, assigned users, status, priority) makes the scope concrete. It does not, however, explicitly distinguish itself from siblings such as neon_search or the list_* family.

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 singular "one activity" plus the GET /activities/{id} mapping signal that this is the lookup-by-id path rather than a search or list. There is no explicit statement of when to prefer it over neon_search or a list tool, and no note about what to do when the id is unknown.

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

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

readOnlyHint=true already declares the safe-read profile, so the bar is lower. The description adds genuine value beyond annotations by listing the payload contents (dates, goal, fund, purpose, parent campaign, status, page URLs, statistics) — important since there is no output schema — and by mapping to the underlying API route.

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

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

A single front-loaded sentence with the core purpose, followed by the API endpoint as supporting detail. Every clause earns its place; the endpoint reference is marginally 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?

With no output schema, the enumerated field list is exactly the replacement an agent needs to know what comes back, and readOnlyHint covers safety. Missing only failure-mode behavior (e.g., unknown id), which is a minor gap for a simple getter.

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?

One parameter with 100% schema description coverage, so the schema already documents it as 'The campaign id.' The description adds no format, prefix, or lookup guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description gives a specific verb (fetch) and resource (one campaign), and enumerates the returned fields so the agent knows exactly what data this call yields. It implicitly separates itself from neon_list_campaigns by saying 'one campaign', though it never names the sibling explicitly.

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

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

Usage is implied by the single-entity phrasing and the required campaign_id, but there is no explicit statement of when to prefer this over neon_list_campaigns or what happens if the id is unknown. Adequate, not instructive.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds real value by listing the fields returned (amount, date, fund, campaign, tribute, soft-credit solicitor, payments, status) and the underlying endpoint, which is useful since 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?

A single front-loaded sentence: verb+resource first, then the field inventory and endpoint. Nothing is wasted, though the long field list and the 'Neon: GET /donations/{id}' suffix are slightly dense for one sentence.

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 by enumerating the return fields, which is the main thing an agent would otherwise lack. It stops short of describing error behavior for a missing or unknown donation_id.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents donation_id. The description adds no format, ID-source, or validation semantics beyond what the schema states, making the baseline 3 appropriate.

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

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

The description names a specific verb and resource ('Fetch one donation') and enumerates the returned fields, so the agent immediately understands this is single-record retrieval by ID rather than a list. It does not explicitly name the sibling it contrasts with (e.g. neon_list_account_donations), so differentiation is implicit rather than stated.

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 mention of 'one donation' and the endpoint 'GET /donations/{id}' signal that a donation_id is required for point lookup. There is no explicit when-to-use, no when-not-to-use, and no pointer to neon_list_account_donations or neon_search for bulk retrieval.

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 is a safe read. The description adds the scope of returned data (registration and financial settings) but says nothing about permissions, error behavior for missing ids, or rate limits. Adequate given annotations, but not rich.

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

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

One compact sentence with the resource front-loaded and the field list bundled efficiently. The trailing 'Neon: GET /events/{id}' endpoint note is mildly redundant with the name but harmless.

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 gives the agent a useful picture of what comes back, and the readOnly annotation covers safety. For a one-parameter read tool this is close to complete, missing only guidance on error 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?

There is a single parameter at 100% schema description coverage, so the schema already documents event_id fully; the description adds no format, source, or sourcing guidance beyond what the schema provides. 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 ('Fetch one event') and enumerates the returned fields, which implicitly distinguishes it from the sibling neon_list_events. An agent can tell immediately this is a single-record get by id.

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 name and the required event_id — the description never says when to prefer this over neon_list_events or neon_search, nor any prerequisite for having a valid id. Minimum-viable guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing what the read returns (level, term, dates, fee, status, auto-renewal, sub-members, payments) and the underlying REST endpoint, which matters since there is no output schema.

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

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

Two tight sentences with zero waste: the action and returned fields are front-loaded, and the API path is appended as compact orientation. Nothing is padding.

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 enumerating returned fields, and one required param at full schema coverage needs no more. Minor omission: no mention of behavior when the id is invalid/not found, but the essentials for a correct call are present.

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

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

Schema coverage is 100% and the single membership_id parameter is documented, so the schema does the heavy lifting. The description reinforces it via the {membershipId} path but adds no format or sourcing detail beyond that; 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 ('Fetch one membership') and enumerates the payload surface (level, term, dates, fee, status, auto-renewal, sub-members, payments). The singular 'one membership' plus the explicit GET /memberships/{membershipId} path cleanly distinguishes it from the plural sibling neon_list_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 only implied: fetching a single membership by id versus the list siblings. There is no explicit 'use this when...' or exclusion statement, so an agent must infer the choice from the singular phrasing.

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 behavioral value by naming the returned fields and framing the call as cheap validation, but it stops short of noting rate limits, caching, or error behavior on bad credentials.

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 purpose and payoff, and closing with the raw endpoint for developers. 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 parameterless read tool this covers everything the agent needs: what it returns, why it is useful, and the endpoint. Annotations cover safety and no output schema is expected to be described further.

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 for the description to disambiguate; baseline 4 applies. No misleading or invented parameter guidance is present.

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 an unambiguous resource (the Neon CRM organization these credentials belong to), and even enumerates the returned fields (name, org ID, app URL). This clearly differentiates it from sibling tools like neon_get_account or neon_list_properties, which target different resources.

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 usage context: credential/connection validation. It doesn't state explicit alternatives or when-not to use it, but the resource is distinct enough that no sibling competes directly.

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

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

With readOnlyHint=true already covering the safety profile, the description adds useful context: the exact fields returned and the default sort order ("newest first"), which clarifies behavior the annotations don't cover. It still says nothing about pagination, result limits, or how the sort defaults interact with the sort 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 compact sentences that front-load the core verb and resource, followed by a useful listing of returned fields. The trailing API endpoint note is arguably redundant but short and unobtrusive.

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's enumeration of returned fields partially compensates by telling the agent what to expect. Combined with the readOnly annotation and full schema coverage, this is largely sufficient for a straightforward read/list tool, though pagination expectations 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 all four parameters (account_id, sort_column, sort_direction, current_page) are already documented in the schema. The description's "newest first by default" adds slight meaning to the sort behavior, but overall the schema does the heavy lifting, making the baseline 3 appropriate.

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

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

States a specific verb and resource ("List one account's donations") and enumerates the returned fields (amount, date, fund, campaign, purpose, status, payments), which clearly distinguishes it from the singular neon_get_donation sibling. It does not explicitly name competing list/search siblings, 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 phrase "one account's donations" implies the usage context (retrieve donations scoped to a single account) and "newest first by default" hints at default ordering behavior. However, there is no explicit when-to-use guidance or exclusion pointing to alternatives such as neon_get_donation for a single record or neon_search for cross-account queries.

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 this is a safe, non-mutating read, so the description carries a lighter burden. It adds the account-scoped endpoint mapping and the optional event narrowing, but says nothing about pagination behavior, default page size, or result ordering despite exposing current_page and sort_direction 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 short sentences with the core scope front-loaded and the REST endpoint appended for implementers; there is no filler. Slightly terse given the tool exposes filtering and paging, but nothing is wasted.

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

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

For a read-only, account-scoped list with full schema coverage and no output schema, the description covers what the tool returns conceptually (registrations, optionally per event). Return shape and pagination are the only omissions, and the naming plus schema carry most of that.

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, including the 0-based paging semantics and the enum-constrained sort direction. The description only restates the optional event filter already covered by event_id, adding no syntax or behavioral nuance beyond the schema.

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

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

The description states a specific verb ("List") and resource ("event registrations") scoped to "one account", and notes the underlying endpoint GET /accounts/{id}/eventRegistrations. It implicitly distinguishes itself from the broader sibling neon_list_event_registrations by binding the listing to an account, but never names that sibling or contrasts 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?

"optionally for a single event" gives one useful scoping hint, so the reader understands the event filter is optional. However, there is no explicit when-to-use vs. when-not, no statement of prerequisites (e.g., valid account id), and no routing to sibling tools such as neon_get_account or neon_list_event_registrations.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden; it does disclose the shape of the returned history (including status values like SUCCEEDED/FAILED) and the underlying Neon endpoint, which is valuable given there is no output schema. It does not discuss pagination behavior beyond what the schema already documents.

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, no filler. The field inventory comes first and the endpoint reference is tucked at the end, so the agent gets the essential information immediately.

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, 7-parameter list tool with full schema coverage, the description is nearly complete: it explains the resource, the filterable modes, and the returned fields, compensating for the absent output schema. Pagination is handled by the schema, so only the lack of explicit sibling routing holds it below 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 every parameter is already documented in the schema, including both enum-typed sort parameters. The description's mention of active/primary-active filtering maps directly onto is_active and primary_active_membership without adding format or syntax detail, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('List one account's membership history') and enumerates the returned dimensions (level, term, dates, fee, status, auto-renewal). This clearly distinguishes it from the singular neon_get_membership and from neon_list_membership_levels, which lists level definitions rather than an account's 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?

The description hints at usage by mentioning the 'filter to active or the primary active membership' options, which maps to two of the filter parameters, but it never states when to choose this tool over siblings like neon_get_membership or neon_list_accounts. Usage is implied rather than specified.

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 value beyond that by disclosing the return fields (accountId, names, email, userType) and the underlying API mapping (GET /accounts), which matters since no output schema exists. It does not mention rate limits or result caps, 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?

Three tight sentences: purpose and filters first, return shape second, alternative route third, API mapping last. Nothing is redundant and the most decision-relevant information is front-loaded.

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

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

With a read-only annotation and no output schema, the description carries the return-value burden and does so adequately by listing returned fields, plus it maps to the API endpoint. Pagination defaults are left entirely to the schema, which is acceptable, but a note on result ordering or paging limits would have completed the picture.

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

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

Schema description coverage is 100%, so every filter and pagination parameter is already documented in the schema. The description restates the filterable fields (email, first/last name, type) without adding format, matching semantics, or combination behavior, making it a baseline case.

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 (constituent accounts), defines the resource scope as individuals and companies, and enumerates the available filters. It explicitly separates itself from the sibling neon_search for richer queries, so an agent can route correctly without opening either schema.

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

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

Gives a clear use condition (simple filtered listing) and names the alternative tool (neon_search) for richer queries. It stops short of stating when-not to use it (e.g. when a single account is needed, neon_get_account) or any prerequisites, so it is clear but not exhaustive.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's addition is modest. It does add the underlying endpoint (GET /campaigns) and the shape of records returned, but says nothing about pagination, ordering, or whether all campaigns are returned.

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

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

One short sentence plus a terse endpoint reference, with the resource named first. Nothing is padded and every fragment carries information.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the main thing an agent needs. It omits any note on result volume or pagination behavior, a minor gap for a list endpoint that takes no arguments.

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

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

The schema has zero properties, so there are no parameters to document and the baseline is 4. The parenthetical field list describes response content rather than inputs, which is a small bonus beyond an empty 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 fundraising campaigns") and enumerates the fields returned (id, code, name, status), which is enough to separate it from the singular neon_get_campaign sibling. It stops short of explicitly contrasting itself with that sibling, 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?

Usage is only implied by the verb "List"; there is no statement of when to prefer this over neon_get_campaign or neon_search, and no exclusions or prerequisites. For a zero-parameter list tool the implied reading is unambiguous, but no explicit guidance is provided.

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 a safe read. The description adds the underlying Neon endpoint and enumerates the returned data shape (accounts, tickets, attendees, amounts, payments), which is useful context, but says nothing about pagination behavior, result limits, or auth requirements even though pagination parameters exist.

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: the action and its scope come first, the optional narrowing second, and the endpoint reference 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?

With no output schema, the description compensates by naming the fields returned, and it identifies the primary and optional filters. It stops short of describing pagination semantics for a paginated list, but the essentials for correct invocation are present.

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 are already documented in the schema. The description only reinforces the registrant_account_id filter ('Optionally only one registrant'), adding no syntax or behavioral detail beyond the structured fields — the baseline 3 for full schema coverage.

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

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

States a specific verb and resource ('List the registrations for one event') plus the payload it covers (registrant account, tickets, attendees, amount, payments). It scopes to a single event and an optional registrant, which implicitly separates it from the account-scoped sibling neon_list_account_event_registrations, but never names that sibling explicitly.

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

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

The description implies the usage context: fetch registrations for one event, optionally narrowed to a single registrant. It offers no explicit when-not guidance or pointer to the sibling tool for account-wide registrations, leaving the agent to infer the distinction.

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

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

readOnlyHint=true already covers the safety profile, so the bar is lower; the description still adds genuinely new behavioral context by disclosing that only Neon's legacy events are exposed by the API — a scope limitation an agent could not infer from the schema. It omits pagination behavior and return shape, which keeps it out of the top band.

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 capability and filters, followed by scope and endpoint metadata. Every sentence carries information, though the endpoint trailer ('Neon: GET /events.') is low-value for an MCP agent that never issues raw HTTP.

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 explaining the return shape for a paginated list endpoint, and it says nothing about the response envelope or how page_size/current_page interact. Combined with 100% parameter coverage and the readOnly annotation, the definition is adequate but has an evident gap around results handling.

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 all ten parameters documented including page_size, current_page, published_event, and the four date bounds. The description's only added detail, the YYYY-MM-DD format, is already repeated verbatim in 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 (list events) and enumerates the filterable dimensions — name, category, date window, published/archived state — so the agent can distinguish it from neon_get_event (single event) and neon_list_event_registrations (a different resource). It does not explicitly name those siblings, so it stops short of the top band.

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 filter dimensions, the YYYY-MM-DD date convention, and the 'legacy events only' scope note imply how the tool should be used, but there is no explicit when-to-use or when-not-to-use guidance versus neon_get_event for detail lookups or neon_list_event_registrations for registration data. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the returned field set and the underlying Neon endpoint, which is modestly useful context, but says nothing about pagination behavior, result limits, or ordering even though two of three parameters are pagination controls.

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 and its returned fields, plus a short endpoint pointer. Nearly zero waste, though the 'Neon: GET /memberships/levels' fragment is mostly protocol trivia for an agent that already has the tool name.

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

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

With no output schema, the description usefully enumerates the fields returned, so the agent knows what it gets back. For a three-parameter, no-required-args list tool this is close to sufficient; the only real gap is that pagination semantics are left entirely to the schema.

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

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

Schema description coverage is 100% and each of the three parameters is documented in the schema, so the baseline of 3 applies. The description adds no parameter detail of its own – the status filter and paging controls go unmentioned – but nothing is left ambiguous by the schema either.

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 organization's membership levels') and enumerates the returned fields (id, code, description, rank, type, status), which pins down exactly what a 'level' is. It does not differentiate from the closely-named siblings neon_get_membership or neon_list_account_memberships, so the agent must infer the distinction from names alone.

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 and no mention of alternatives, even though the sibling list contains several membership-related tools (neon_get_membership, neon_list_account_memberships) where the boundary matters. The scope is only implied by the word 'organization's' and the plural resource 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 establishes the safe-read profile, so the description's job is lighter. It adds the underlying endpoint (GET /properties/{name}) and clarifies that results are ids, which is useful, but says nothing about pagination, ordering, or response shape. 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?

Purpose is front-loaded in the first clause, followed by the enumeration and the endpoint reference. The long value list is slightly dense but each entry maps to a real category, so it earns its place; no wasted filler.

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

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

For a single-param, read-only lookup tool with no output schema, the description supplies what an agent needs: the purpose, the valid categories, and the fact that results are ids. Missing detailed return format, but that is minor against the annotations covering safety.

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

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

Schema coverage is 100% and the enum already lists all 14 valid values with the description 'Which lookup list.' The description's enumeration largely mirrors the enum rather than adding format or selection guidance, so baseline 3 is appropriate.

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

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

States a specific verb ('List') and resource (the organization's lookup lists) and enumerates the exact lookup categories available. An agent can immediately tell this fetches reference/id data, distinct from the get_/list_ record tools in the sibling set.

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 the tool's role as supplying 'the ids other tools need' and calls out the specific dependency on neon_create_activity for time zones. This gives clear context for when to reach for it, though it stops short of naming alternatives or explicit when-not-to-use conditions.

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

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

Annotations only declare readOnlyHint=true; the description adds that this is a GET-based discovery endpoint that must precede neon_search, and explains the semantics of each kind (operators for searchFields, custom numeric ids for outputFields). Auth and rate-limit behavior are still undisclosed, but meaningful context beyond the annotations is provided.

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 sentences, front-loaded with the core purpose and followed by the two kind explanations and the sequencing cue. The trailing REST path note is a minor redundancy but is compact and useful for tracing behavior.

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 correctly carries the burden of explaining return content for both kinds, including the custom-field numeric ids. Combined with the mandatory precondition on neon_search, an agent has everything needed to call it correctly.

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

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

With 100% schema coverage, the baseline is 3, but the description genuinely enriches both parameters: it explains that kind=searchFields returns filterable fields plus their allowed operators, and kind=outputFields returns returnable columns including custom fields with numeric ids. This adds semantic depth the enum labels alone don't 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 (discover) and resource (field names neon_search accepts), and differentiates itself from siblings by naming neon_search as the consumer. The two kind values are explained in terms of their distinct outputs, so an agent can distinguish this discovery tool from the actual search tool.

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?

"Call this before neon_search" is an explicit usage directive that tells the agent exactly when to reach for this tool. It does not state when the tool is unnecessary (e.g. if field names are already known), but the sequencing guidance is clear and actionable.

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

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

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and does add value: it discloses the return shape ('searchResults rows keyed by output field name, plus pagination totals') absent any output schema, and warns of a real constraint ('only ONE concurrent search per endpoint'). It stops short of describing error behavior or a result cap.

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 what is searched, then how to build the request, then what comes back — a sensible order with dense content and no filler sentences. The trailing 'Neon: POST /{resource}/search' is low-value implementation trivia that slightly dilutes the ending.

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

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

For a 7-parameter, 3-required search tool with no output schema, the description covers the request structure, the field-value provenance, the ANDed filter semantics, the concurrency limit, and the return shape. It is nearly complete; error handling and any maximum-result behavior remain 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 baseline is 3 and the schema already documents field/operator/value, page_size bounds, output_fields limits and the required sort_column membership rule. The description's additions (custom-field IDs as integers, 0-based pages) largely restate the schema, with only the neon_list_search_fields provenance being genuinely additive.

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 set ('Report-style search over accounts, donations... activities or events') and scopes the record types precisely, including that donations subsume pledges and pledge payments. An agent can distinguish this from the neon_list_* and neon_get_* 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?

Gives clear call context (supply filter criteria, output columns, pagination) and points to the prerequisite source of valid field identifiers, neon_list_search_fields. It does not explicitly state when to prefer this over neon_list_accounts or neon_get_donation, so the routing is implied rather than enumerated.

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?

destructiveHint=true tells the agent this mutates data, and the description adds genuinely new context beyond that: PATCH semantics mean only passed fields change (so unlisted fields survive), the type must match, and addresses are out of scope. It does not cover permissions or reversibility, but the partial-update guarantee is the highest-value disclosure for a write 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?

Four tight sentences: what changes, how partial updates behave, the type precondition, and the scope exclusion, with the PATCH endpoint mapping last. Every sentence carries distinct information and the mutation scope 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 12-parameter mutation with no output schema, the description covers the mutation model, a prerequisite, and an exclusion. It omits only secondary details like the response shape and failure behavior, which is minor given the thorough schema.

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

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

Schema description coverage is 100%, so every one of the 12 parameters is already documented, including the type enum and the field-to-payload mappings. The description lists a subset of the same fields without adding syntax, formats, or constraints, so it earns only the 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 ('Change an account's') and enumerates the editable fields, which cleanly separates it from neon_create_account and neon_get_account. No sibling is named explicitly, but the update verb makes the distinction obvious 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?

Gives a real prerequisite ('The type must match the account (see neon_get_account)') and a boundary ('Addresses are not edited here'), plus the partial-update rule. It stops short of naming when to use update vs create or where address edits should go, so no explicit alternative is routed.

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 deliver: the PATCH partial-update contract ('Only the fields you pass are changed') and the API mapping (PATCH /activities/{id}) are real behavioral context. It omits permissions/auth requirements and does not warn that note replacement is irreversible, which is disclosed 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 tight sentences plus a short API mapping: scope and update semantics are front-loaded, and every clause earns its place. 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 a 5-parameter PATCH tool with no output schema, the description covers what can be changed and how partial updates behave, which is the essential call-correctness information. It leaves auth/prerequisite context and any confirmation of what the response returns unstated, a minor gap given the simple surface.

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, including status_id's pointer to neon_list_properties name=activityStatuses. The description's field list and 'mark it completed' example add marginal framing but 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 clear verb+resource ('Change an activity's...') and enumerates the updatable fields (subject, note, status, priority), which distinguishes it from neon_update_account and the many read siblings by resource name. It stops short of explicitly contrasting with a sibling, but an agent can identify the target entity immediately.

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

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

The description gives one usage example ('mark it completed') and implies when the tool applies, but it never states when NOT to use it, nor points to alternatives (e.g. neon_create_activity for new records, neon_get_activity for reads). Usage is implied rather than guided.

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