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

Annotations already indicate the tool is not read-only and not destructive. The description adds that it can update and list changes, but it does not disclose deeper behavioral traits such as side effects of updates, required permission context, or response behavior. It neither contradicts annotations nor adds substantial behavioral insight.

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

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

The description is a single, compact sentence that front-loads the resource and immediately names the three supported operations. There is no filler or redundant restating of 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?

For a tool with nine parameters, three distinct actions, and no output schema, the description is too high-level. It does not explain that the action parameter determines required fields, nor does it mention pagination, date-based change listing, or return behavior. The schema carries most of the needed context.

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 parameter meanings and action-specific requirements. The description adds only high-level mapping to operations and does not enrich understanding of the nine parameters beyond what the schema provides.

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

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

The description names a specific resource (communication permissions for email/SMS/phone) and clearly lists three concrete operations: querying, updating, and listing changed permission statuses. This clearly distinguishes it from sibling tools such as fonzip_events or fonzip_donations.

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 resource domain is clear, so an agent can infer when this tool is relevant, but the description gives no explicit when-to-use guidance, no exclusions, and no comparison to alternatives. Usage is implied rather than stated.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false; the description's mention of silme and olusturma (delete/create) is consistent with those, so there is no contradiction. But the description adds no behavioral context beyond the annotations: no note on destructive scope, no side effects (e.g., creating a donation can auto-create a user via member_id), no auth requirements, and no mention of the payment_method_select 'card' API restriction hinted at in the schema.

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

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

A single dense sentence with no wasted words; the resource name and its most important constraint (date range required for listing) come first, and the semicolon-separated catalog efficiently covers the full action surface. It is compact, though the packed Turkish list functions more as a tag summary than a structured explanation.

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 74 parameters, 14 actions, and no output schema, this is an extremely complex tool, yet the one-sentence description does not orient the agent to the dispatch pattern (action is required and determines which params apply), does not differentiate the list variants (list vs. list_micro vs. list_categories vs. list_donation_forms), and gives no sense of what report covers. The rich schema compensates heavily, but the description alone is not complete enough for safe selection and invocation.

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

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

Schema description coverage is 100% — every one of the 74 parameters carries a description with per-action qualifiers in brackets (e.g., '[list, list_micro] ordering'). Per the rubric, this earns the baseline 3 even though the tool description itself adds zero parameter-level meaning. The schema fully compensates for the description's silence on parameters.

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 Turkish description identifies the resource (donations) and enumerates the operations: listing (with a mandatory date range), detail, create, delete, report, plus donation categories, micro donations, pages, and forms. This distinguishes it from sibling tools by domain. However, it reads as a capability catalog rather than a crisp purpose statement, and the full scope only emerges from the 14-value action enum.

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

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

The only usage guidance is the embedded constraint that listing requires a date range. There is no statement of when to prefer this tool over siblings (e.g., fonzip_monthly_donations for recurring donations vs. the recurring filter here), no exclusions, and no alternatives named. The action enum provides structure, but the description itself offers no selection guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds some context by stating that sales transactions can be deleted ('silme'), which tells the agent what kind of destructive action exists. However, it does not disclose anything beyond that—no permissions, reversibility, or side effects—so it only partially fulfills this dimension.

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

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

The description is a single compact sentence that front-loads the resource and the three main operation types. Every word earns its place, with no repetition of schema details or annotations. This is appropriately concise for a tool with such a rich input 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?

The input schema is exceptionally detailed—every parameter is documented with action tags, enums, defaults, and constraints—so the short description does not need to compensate for missing parameter context. The combination of description and schema gives an agent enough orientation to select the correct action and required fields. It is not a 5 because the description alone does not summarize all nine actions or warn about the destructive operations beyond a passing 'silme' mention.

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 every parameter's meaning and usage per action. The description itself adds no parameter-level information, which is acceptable but not value-adding. Baseline 3 applies here.

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

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

The description identifies a clear resource domain ('E-kartlar') and enumerates the operation groups: card/category management and listing, detail, and deletion of e-card sales transactions. This maps well onto the action enum (create_category, update_category, delete_category, list, get, list_transactions, get_transaction, delete_transaction) and distinguishes the tool from fonzip_* siblings by its e-card focus. It loses one point because 'yonetimi' (management) is a broad verb and does not explicitly name create/update actions.

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 provides no guidance on when to use this tool versus alternatives such as fonzip_donations or fonzip_events, and no exclusions or preferred scenarios. The only implied distinction is the e-card resource in the name, which is not enough for an agent to know when to choose this over sibling tools.

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 convey readOnlyHint=false, idempotentHint=false, destructiveHint=true. The description adds that deletion targets events and that status changes are possible, giving a little more concreteness to the destructive/mutating nature. It does not, however, describe cascading effects, irreversibility, authorization needs, or side effects beyond what the annotations imply.

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

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

The description is a single compact sentence that front-loads the main capability domains and avoids filler. While it is terse for a 49-parameter/12-action tool, it is not padded and reads quickly. It loses a point because it is a fragment and does not structurally reflect the action-based routing nature.

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

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

Given the tool's complexity, the description covers the main event lifecycle and ticket/sales domains, but it omits event querying/list/get operations even though the action enum includes list/get. With no output schema and only this high-level summary, an agent gets a partial map of the tool's surface; the schema fills in many gaps, so it is adequate but not complete.

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

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

Schema description coverage is 100%, so the input schema fully documents every parameter, including which actions each field belongs to and required markers (e.g., 'Zorunlu: delete, get, update, update_status'). The tool description itself contributes no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description names the resource domain ('Etkinlikler' – events) and enumerates concrete operations: create, update, status change, delete, plus ticket definitions and ticket sales/details. This is more specific than the tool name and helps distinguish it from siblings focused on other fonzip areas. It lacks a crisp 'performs X to achieve Y' statement and reads as a fragment, so not 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?

No explicit statement of when to choose fonzip_events over alternatives. The domain is inferred from the name and the list of operations, but there are no exclusions, prerequisite conditions, or references to sibling tools. This is effectively no guidance for selecting between tools.

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 state readOnlyHint=false and openWorldHint=true, and the description adds that one action writes a reply to an answer, which is the main mutation. However, it does not mention consequential side effects encoded in the schema (emails, refunds, membership number assignment, template overwrites), so transparency is only partial.

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

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

The description is a single front-loaded sentence with no filler; the colon list conveys scope and operations efficiently. It could arguably be more action-oriented, but it earns its place as a concise summary.

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, four-action tool with no output schema, the description is minimal, but the rich input schema supplies required-parameter and action mappings. Missing usage and side-effect context prevents a higher score, yet the schema makes the definition usable.

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

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

Schema description coverage is 100%, and each parameter already has a description plus square-bracket action tags, so the schema carries the parameter meaning. The tool description adds no parameter detail, which is acceptable under the high-coverage 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?

The description names the resource ('forms and form answers') and enumerates the four operations (list forms, list answers, answer detail, write a reply), which map directly to the action enum. It is clear enough to distinguish this forms domain from the fonzip_* siblings, though it is a noun-phrase summary rather than a single imperative verb.

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

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

There is no guidance on when to use fonzip_forms instead of a sibling such as fonzip_templates or fonzip_donations, and no when/when-not conditions. The action enum and parameter tags imply operation selection, but the description itself gives no usage direction.

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 no behavioral information beyond annotations: it does not mention mutation, deletion, finalization, state changes, permissions, or side effects. Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description itself does not disclose any operation semantics. There is no contradiction with annotations, but there is also no added behavioral transparency.

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

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

The description is a single sentence with no wasted words, but it is under-specified rather than appropriately concise for a 56-parameter, multi-action tool. It lacks any structure such as an action list, usage context, or key distinction hints. For this complexity level, the brevity is more a deficiency than a strength.

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

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

Given a 56-parameter surface, no output schema, and multiple implied operations, the description only provides a high-level resource scope. It does not explain how actions route parameters, what operations are available, or what the tool returns. The schema carries nearly all the operational meaning, leaving the description incomplete as a standalone guide.

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 input schema already documents all 56 parameters and their action-specific meanings. The tool description provides no parameter-level semantics and does not need to, given the complete schema. This matches 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?

The description lists the covered resources: fundraising campaigns, campaign events, fundraising teams, and team campaigns. It is not a tautology because it enumerates these subresources, but it contains no action verb and reads as a static domain label rather than a statement of what the tool does. It does somewhat distinguish the tool from siblings like fonzip_events or fonzip_donations by naming campaign-specific 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?

The resource list implies that this tool is for fundraising-related entities, which gives some context on when it applies. However, the description never explicitly says when to use it vs. alternatives such as fonzip_events or fonzip_donations, and it does not mention exclusions or alternative tools. Usage guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description's 'silme' (delete) matches the destructive nature. The description adds an inventory of mutating operations but does not disclose side effects such as send_mail, add_payment, or the remove/activate action behavior. No contradiction with annotations.

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

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

The description is a single concise sentence with no fluff, and it front-loads the domain. However, it compresses many distinct operations into one comma-separated list without grouping by operation flow or naming the action selector, which weakens its structural usefulness for a 40-parameter tool.

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

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

For a multi-operation tool with 40 parameters and no output schema, the description is far too thin. It does not explain how to select or route between operations like list, create_debt, delete, or update_debt_status, nor what return values to expect. The rich schema partially compensates, but the high-level description leaves critical invocation context 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%, and each parameter already includes operation tags and enum explanations. The description itself adds no parameter-level meaning 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 the resource ('Aidatlar ve borclar') and enumerates concrete operations: listing/detailing/deleting subscriptions and creating/updating/status-changing/deleting debts. It distinguishes the tool's domain from siblings like fonzip_donations and fonzip_monthly_donations, though it is a packed summary rather than a structured operation list.

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 provides clear domain context with 'Aidatlar ve borclar', implying this tool is for membership dues and debt operations. However, it gives no explicit when-to-use guidance, exclusions, prerequisites, or comparison against sibling tools, leaving usage mostly to inference.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, and the description merely lists mutation-like operations without adding side-effect context. It does not explain what cancellation triggers, whether approval flows are required, or what consequences follow a card update request or amount change.

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

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

The description is a single compact sentence with the resource scope front-loaded and a list of core operations. It is efficient, though for a 32-parameter multi-action tool it could be structured into clearer action groups.

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

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

Given the high complexity (32 parameters, one required action, nested objects, no output schema), the description is too sparse. It does not explain how the required 'action' parameter routes to modes like change_values, cancel, create_update_request, respond_amount_change_request, or send_card_update_request, nor does it mention omitted operations such as date/category changes and retry.

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 every parameter. The description adds no extra parameter meaning beyond naming some high-level operations, which keeps it at the baseline rather than adding value.

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

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

The description names the resource ('Duzenli (aylik) bagislar' / recurring monthly donations) and lists concrete operations: creating/responding to amount change requests, sending card update requests, and canceling recurring donations. However, it omits some distinct modes present in the schema, such as changing the next withdrawal date, category, retry withdrawal, and the broader action-dispatch model, so it is not fully precise.

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 no guidance on when to use this tool versus sibling tools like fonzip_donations or fonzip_membership_dues, and no when-not-to-use conditions. It implies the domain via the resource name but never states selection criteria or alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool exposes system configuration and connection data, but does not discuss authentication needs, rate limits, pagination behavior, or return format. This is acceptable given the annotations but not highly informative beyond them.

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

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

The description is two sentences with no filler. The first sentence states the tool's content scope, and the second immediately communicates the practical use case. Every phrase contributes to orientation and selection.

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 discovery tool with a fully-described three-parameter schema, the description gives enough context to start using it correctly. It names the core resources and the start-here workflow. The absence of return-value details is mitigated by the read-only annotations and the enum-driven action schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters and action-specific usage. The description only refers the agent to the bracketed field descriptions without adding new meaning or examples. This meets the baseline for fully-covered schemas.

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

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

The description identifies a clear functional scope: account and system information (connection verification via 'me', payment systems, bank accounts, marketing channels). It also states the practical purpose of finding IDs for other tools. It is somewhat broad because it covers multiple sub-actions, but the action enum in the schema supplies the missing specificity.

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 explicitly says to start here when verifying setup or locating IDs used by other tools, which gives clear guidance on when this tool is appropriate. It does not name excluded alternatives, but the sibling tools are domain-specific and this is clearly positioned as the system-level discovery entry point.

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 signal that this tool is mutating and destructive, so the description does not need to repeat that. It adds the useful scope 'kurum genelindeki' and confirms the CRUD action set, but it does not disclose further behavioral context such as irreversibility of deletes, authentication requirements, or side effects.

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

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

The description is a single compact sentence with the resource and all four operations front-loaded. There is no filler or redundant elaboration, though it is necessarily thin on behavioral guidance.

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 multi-action CRUD tool with seven parameters and no output schema, the description plus schema and annotations are minimally sufficient. The schema handles parameter semantics and required fields, and annotations handle the destructive nature, but the description adds little beyond scope and operation names, leaving usage context and behavioral caveats thin.

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 every parameter described and action-specific requirements marked in square brackets. The tool description itself adds no parameter detail, but the schema carries the full burden; a baseline of 3 is appropriate.

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

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

The description names the resource (tags/etiketler) and enumerates the four operations: listeleme, olusturma, guncelleme, silme. It also adds the institution-wide scope with 'kurum genelindeki,' so it is not a bare tautology. It stops short of explicitly differentiating from sibling tools, but the tag resource is clearly distinct among the sibling modules.

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

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

Usage is implied rather than explicitly stated: the tool is for institution-wide tag management, and the action enum clarifies which operation to perform. However, there is no guidance about when to prefer this tool over alternatives or when a particular action should not be used.

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 indicate the tool is destructive, read-write, and non-idempotent. The description merely restates that delete/update/create operations exist and adds no additional behavioral context such as effects on related data, authorization needs, or irreversible actions.

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

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

The description is a single concise sentence with no filler. It front-loads the resource and lists operations efficiently, though it is so terse that it misses opportunities to provide richer guidance.

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 25 parameters, nested objects, no output schema, and an action-driven design, a one-line description is insufficient. The schema helps, but the description does not clarify per-action invocation patterns, required fields beyond the bracketed notes, or expected return 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 carries the parameter documentation burden. The tool description itself adds no parameter-level meaning beyond naming the operations, justifying the baseline score of 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?

The description clearly identifies the resource as email/message templates and lists the five CRUD operations (list, detail, create, update, delete). It is specific enough to distinguish this tool from sibling fonzip_* tools that target different resources, though it does not name a sibling or highlight unique scope.

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

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

The description gives no guidance about when to use this tool versus alternatives, nor any exclusion criteria. An agent must infer usage solely from the resource name and the action enum in the schema.

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 mark this tool as destructive and non-read-only, and the description confirms this by mentioning create, update, and delete operations. It adds some behavioral context by naming the person-centric subresources, but it does not disclose side effects, what deletion affects, authentication needs, or other consequences beyond what the annotations already imply.

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

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

The description is a single, dense sentence that front-loads the resource and core operations before enumerating related data areas. It is compact and free of filler, though the long semicolon-separated list makes it slightly less scannable than a structured summary would be.

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?

This is a very complex tool with 46 parameters, 20+ actions, nested search/update structures, and no output schema, but the description only provides a high-level scope. It does not explain how to choose among actions, what actions are available beyond the enum, what return values look like, or how pagination and filtering work. The schema fills in parameter details, but an agent still lacks adequate contextual guidance for correct tool invocation.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter in detail, including action-specific required fields. The description itself contributes no parameter semantics, which is acceptable given the strong schema coverage. The baseline of 3 applies because the schema, not the description, carries the semantic load.

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

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

The description clearly identifies the resource as members/donors (persons) and lists the main operations: listing/searching, detail, create, update, delete, plus related person data like timeline, tags, donations, dues, tickets, and form answers. This gives an agent a solid idea of the tool's scope, though it does not explicitly differentiate it from sibling tools like fonzip_donations or fonzip_tags, which cover overlapping subresources.

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

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

There is no guidance on when to use this tool versus sibling tools. The description simply states the resource and operations, leaving the agent to infer that person-level operations belong here. No exclusions or alternative recommendations are provided, which is a significant gap for a large tool with many related sibling tools.

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 indicate destructive behavior and non-read-only semantics, and the description merely lists operations such as delete and send_test_notification without adding new context beyond the schema. It does not disclose side effects, irreversibility, authentication requirements, or rate-limit considerations.

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

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

The description is a single concise sentence that immediately identifies the resource and lists every available operation. There is no redundant phrasing or filler, making it easy to scan and understand quickly.

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 tool with eight parameters, an action discriminator, nested objects, and no output schema, the description provides a helpful operation overview but leaves per-action required fields and return behavior to the schema. It is minimally adequate but not comprehensive.

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 parameters and their action affinities. The description adds no parameter-level meaning, so it deserves the baseline score of 3 rather than higher.

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

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

The description clearly identifies the tool as a webhook manager and enumerates all supported operations: listing, detail, create, update, test notification, and delete. This is specific enough to distinguish it from sibling tools targeting other Fonzip resources, though it does not explicitly contrast itself with a sibling.

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

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

The description provides no guidance on when to use this tool versus alternatives, and does not explain how to choose among the action values. The action enum in the schema covers operation semantics, but the description itself leaves usage decisions entirely to inference.

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