Kulhad

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

Annotations already declare a non-read-only, non-idempotent mutation, and the description substantially adds to that: Kulhad cannot validate the address, duplicates are not checked, and the free plan permits only one active ID at a time. These are real behavioral and resulting-state facts an agent could not infer from the structured fields.

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

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

Front-loaded with the core purpose, and each subsequent sentence (verification advice, no duplicate check, plan limit) carries distinct information. The middle verification sentence is somewhat long and reads partly as end-user advice, but nothing is redundant.

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

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

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The description fills the meaningful remaining gaps (unverifiable address, duplicate acceptance, plan limits) for a mutation tool, leaving only the sibling-routing guidance unaddressed.

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

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

Schema coverage is 100%, so all three parameters (vpa, label, makeDefault) are fully documented in the schema. The description adds contextual framing ('for supporters to pay into') but no format or constraint detail beyond what the schema already supplies, so the baseline 3 applies.

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

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

States a specific verb (Add) and resource (a UPI ID) plus its purpose ('for supporters to pay into'). The verb 'add' inherently distinguishes this from creation-adjacent siblings like update_upi_id, remove_upi_id, and set_default_upi_id without needing to name them.

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

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

Provides an in-workflow verification instruction ('send one rupee... confirm it arrived before sharing the page') and a plan constraint, which implies the context for use. However, it never routes the agent explicitly to alternatives such as update_upi_id for changing an existing ID or set_default_upi_id, so tool-selection 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 cover destructive/idempotent/readOnly, but the description adds the effects the annotations cannot express: irreversibility, name and amount appearing on page and stream overlays, counting toward totals and the active goal, goal auto-completion and removal from the page, and that nothing is sent to the supporter. These are precisely the consequences an agent must weigh before a one-way action.

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

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

Front-loads the action and its precondition, then layers consequences, parameter behavior, and the safety warning in short, information-dense sentences. Six sentences and every one carries decision-relevant content; no filler or restated boilerplate.

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 destructive, one-way approval with an output schema already present, the description supplies the missing pieces: prerequisites, irreversibility, downstream page/goal effects, reply and hidden semantics, and the consent constraint. Nothing material is left for the agent to guess.

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 67% and the schema already documents reply (280 chars, replaces existing, word-filter refusal) and hidden (message/voice private, name/amount still shown) in nearly the same words, so the description largely duplicates structured data. It adds no prose for id and only marginally extends the parameters by tying them to visible outcomes.

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 ("Approve one supporter") and instantly scopes it as the single-support path versus the sibling bulk_approve_supports. The description also names the precondition that makes it distinct from a generic approval endpoint (creator must have verified payment).

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 an explicit when-to-use rule ("after the creator has found the payment in their own bank app") and a hard when-not rule ("never approve without being asked to for that specific supporter"), plus the rationale that only the creator can know the money arrived. That is exactly the guidance an agent needs before calling a destructive approval.

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 idempotentHint=true, yet the description adds genuinely new behavioral facts: the operation is irreversible, invalid/non-waiting ids are silently skipped and counted rather than erroring, and no reply is set. That partial-success semantics is exactly what an agent needs and is not derivable from the 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?

Four short sentences, front-loaded with the action and its limit, then preconditions, irreversibility, edge-case handling, and sibling equivalence. No filler and every sentence carries distinct 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 an output schema present, return values need not be explained. The description covers batch limit, Premium gating, irreversibility, skip behavior for bad ids, and equivalence to approve_support — everything needed to invoke it correctly.

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

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

Schema coverage is only 50% (the 'hidden' flag is documented in-schema, 'ids' is not described). The description compensates by explaining that the ids array is a set of waiting supporters (implying the 1..100 bound) and that non-waiting, foreign, or missing ids are skipped and counted — a meaningful semantic beyond the raw integer array definition.

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 (Approve), a bounded scope (up to 100 waiting supporters at once), and the prerequisite condition (after the creator has checked their bank). It is easily distinguished from the singular sibling approve_support and from bulk_reject_supports.

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 precondition (creator has checked their bank) and references approve_support as the equivalent single-item operation, plus a Premium gating note. It does not explicitly say when to prefer the single-item tool over this batch tool, but the context is unambiguous.

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 idempotentHint=true, but the description adds what the annotations cannot: the action is irreversible, voice recordings are deleted immediately, non-waiting ids are skipped and counted rather than erroring, and the Premium requirement. That is substantive disclosure of side effects and partial-failure semantics beyond the structured fields.

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

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

Three compact sentences, front-loaded with the action and its limit, then the constraint, then the irreversibility warning. No filler; each sentence carries distinct 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 an output schema present, return values needn't be documented, and the description covers the remaining agent-critical facts: the 100-item cap, Premium gating, irreversibility, recording deletion, and skip-and-count behavior for invalid ids. Nothing essential to calling this correctly is missing.

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

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

Schema coverage is 0%, so the description carries the load. It explains that ids must be waiting supporters, that non-waiting ids are skipped and counted, and that the cap is 100 — matching the schema's maxItems/minItems. It does not clarify ordering or duplicate-id behavior, but it adds meaningful semantics beyond the bare integer array.

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 ('Reject'), resource ('supporters'), and scope ('up to 100 waiting... at once'), which cleanly distinguishes it from the sibling reject_support (singular) and bulk_approve_supports. An agent can route to it without opening the schema.

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

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

Gives a clear operational precondition ('confirm the list with the creator first') and a plan gate ('Part of Premium'), which is real when-to-use guidance. It does not explicitly name reject_support as the single-item alternative or state when bulk is preferred, so it stops short of full alternative routing.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the useful framing that it is a pre-flight validation step, but says nothing else about behavior beyond what the annotations provide.

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

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

Two short sentences, front-loaded with the purpose, then the domain clarification, then the usage cue. No filler or redundancy.

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

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

An output schema exists, so return values need not be described. For a one-parameter validation tool the description covers purpose, the meaning of the input, and when to call it; the only gap is that it doesn't hint at the result shape (available vs. taken), which is minor given the output schema.

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

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

With a single parameter and 100% schema description coverage, the schema already explains that the value is the name 'without the address around it' with the example 'priya'. The description's explanation of what a page name is adds domain framing but no parameter syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('check whether a Kulhad page name is free') and then defines the domain term 'page name' with a concrete example (kulhad.co/priya). No sibling tool does this, and an agent can distinguish it from update_profile or start_signup without opening the schema.

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

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

Gives explicit timing guidance: 'Use this before suggesting a name to somebody setting up a page,' which ties the tool to a concrete workflow moment. It does not name an alternative or a when-not-to-use case, but no sibling tool overlaps with this check.

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 the generic mutation profile (readOnly=false, destructive=false, idempotent=false). The description goes well beyond that by disclosing the side effect on other goals (deactivated, not deleted), a plan-based refusal precondition, a Premium feature gate, and the visibility consequence of an inactive/incomplete goal. These are exactly the behavioral traits an agent cannot infer from 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?

Four tight sentences, front-loaded with the core action followed by side effects, plan gates, and an edge case. Each sentence carries distinct, non-redundant information with 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?

The tool is a mutation with annotations covering safety and an output schema covering return values, so the description's job is behavioral context — and it supplies side effects, preconditions, gating, and an edge case. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 67%, so the schema documents active, impact, deadline and targetAmount already. The description adds genuine meaning for 'active' by spelling out its consequences (becomes the shown goal, others put away), which the schema's one-line 'Show it on the page straight away' does not cover, while adding little for the rest.

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 goal') and immediately pins the required inputs (title, target in whole rupees). It also distinguishes the operation from neighboring concepts by noting that a replaced goal is 'put away, not deleted' and that set_active_goal restores it, so the agent can separate create from delete/set_active without opening other schemas.

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

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

Provides real conditional guidance: default activation behavior, the free-plan refusal when another goal is running, Premium gating for impact tiers. It stops short of explicitly naming when to pick create_goal over update_goal or list_goals, but the preconditions and plan constraints give the agent enough to decide correctly.

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?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=true) by spelling out the concrete consequences: irreversible, cover image is deleted with it, pending/rejected supports lose their link, and goals with approved support cannot be deleted at all. That is exactly the destructive-effect detail an agent needs before calling.

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

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

Four short sentences, front-loaded with the action and its precondition, then the side effects, then the exclusion case. No filler and nothing repeated from the title or annotations.

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 destructive one-parameter tool with an output schema present (so return values need no explanation), the description covers preconditions, irreversibility, and collateral effects on related entities. Nothing an agent needs before invoking it 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?

Only one parameter, and the schema provides no description for it (0% coverage). The description implies the target is a goal but never clarifies that 'id' is the goal identifier, nor how to obtain it. Acceptable but leaves a small gap that the schema does not fill.

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 plus a scoping condition: 'Delete a goal that has no approved support.' That precondition distinguishes it from generic deletion and from the sibling delete_goal_update (which targets a goal update, not the goal itself), so an agent can select it without opening the schema.

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

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

Gives a clear eligibility rule for use ('no approved support') and implicitly signals the alternative path: a goal with approved support 'can only be turned off,' i.e. use update_goal/set_active_goal instead. It never names that alternative tool explicitly, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds real value beyond that: it spells out the irreversible nature in plain language ('This cannot be undone') and explains the zero-based, newest-first ordering, which explains why repeated calls are non-idempotent. It stops short of covering permissions or out-of-range error behavior.

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

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

Two sentences, zero filler, and the destructive warning is front-loaded immediately after the operation definition. Nothing is repeated from the schema or annotations unnecessarily.

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?

An output schema exists so return values need not be explained, and annotations carry the destructive/idempotent flags. The only remaining gap is behavior on an out-of-range or negative index, which is a minor omission for a two-parameter 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 coverage is 50% — index is documented but goalId is not. The description restates and reinforces the index semantics (zero-based, newest first) but says nothing about goalId, so it does not fully compensate for the coverage gap. 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?

The description names a specific verb and resource — 'Remove one progress note from a goal' — and adds the addressing scheme ('by its position in the list'), which distinguishes it from delete_goal (deletes the whole goal) and update_goal. An agent can distinguish it from every sibling without opening the schema.

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

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

Usage is implied by the narrow scope (removing a single note), but there is no explicit when-to-use guidance, no statement of prerequisites or permissions, and no named alternative such as update_goal or delete_goal for the confused case. Adequate but with clear gaps.

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 cover safety (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavioral context: a Premium entitlement requirement, a nightly-rollup source that excludes today, and sparse output where only active days appear. The only substantive gap is that it doesn't say what happens on a non-Premium account (error vs. empty result).

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 no filler; the payload contents are front-loaded and the caveats (rollup lag, sparse days) follow. It opens with a noun phrase rather than a verb, which is slightly less scannable but costs almost nothing.

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?

An output schema exists, so return structure need not be described, yet the description still supplies the interpretation an agent needs: data is one-day stale and missing rows mean no activity rather than an error. Together with the Premium gate and the day-range default, nothing required to call or interpret this tool is missing.

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

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

Schema description coverage is 100% and the single 'days' parameter is fully documented with default 30 and max 90 in the schema. The description's 'up to the last ninety days, thirty by default' simply restates those bounds rather than adding format or interaction 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 enumerates exactly what comes back — daily page views, approved supports, amounts, and the visitor-to-supporter conversion rate — so the resource is unambiguous. It never states a verb or contrasts itself with overlapping siblings such as get_dashboard_summary or get_wrapped, so an agent must infer the boundary itself.

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

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

Usage is implied rather than stated: 'Part of Premium' signals an entitlement gate, and the rollup note tells the agent this is for historical, not real-time, numbers. There is no explicit when-to-use-this-instead guidance against the other analytics-flavored siblings, leaving routing 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds a genuinely useful behavioral trait beyond the annotations: the tool is gated behind a Premium plan, which can explain invocation failures for free-tier users.

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 zero filler. The core read behavior is front-loaded and the Premium constraint is a compact trailing qualifier.

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?

An output schema exists, so the description need not explain return values, and the annotations carry the safety profile. For a zero-parameter read tool this is nearly complete; the only real gap is the absence of guidance distinguishing it from verify_custom_domain and the other custom-domain siblings.

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

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

The tool takes no parameters, so there is nothing for the description to clarify at the parameter level. Baseline of 4 applies; the description correctly spends no words restating 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 ('Read') and resource ('custom domain') and defines the two pieces of information returned: connection status and required DNS record. This is far more specific than the title, but it does not explicitly differentiate from close siblings like verify_custom_domain or get_page_settings, leaving some overlap to inference.

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

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

There is no when-to-use or when-not-to-use guidance. The description never explains how this differs from verify_custom_domain or remove_custom_domain, nor when an agent should call this versus set_custom_domain. 'Part of Premium' is an availability note, not usage 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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds scope detail (which aggregates are included) but discloses no freshness, caching, or scoping behavior beyond what the title implies.

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

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

A single front-loaded sentence listing the four headline metrics with no filler or redundancy. It is a bit of a run-on noun phrase rather than a crisp statement of action, but every clause carries information.

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

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

With an output schema present, return values need not be documented, and the read-only annotations remove the need for permission or side-effect discussion. The only shortfall is the absence of guidance distinguishing this summary from get_analytics.

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

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

The tool takes zero parameters, so the schema is trivially complete and the description cannot add parameter meaning. Baseline 4 applies for a no-parameter tool.

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

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

The description concretely enumerates what the tool returns: this-month vs last-month inflow, all-time total, approved support count, and pending-approval count. That is a specific resource with clear contents, but there is no explicit verb and no contrast against the closest sibling (get_analytics), so an agent must infer the boundary.

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 phrase 'headline numbers from the creator dashboard' – a quick overview rather than detailed analytics. It never states when to prefer this over get_analytics or list_pending_supports, and gives no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — it returns snippets to paste, not a rendered preview — but says nothing about format, variants selection, or whether the returned code is scoped to the account.

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

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

Two sentences, zero filler, with the core capability front-loaded and the output clarification immediately after. Nothing is repeated from the title or 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?

An output schema exists, so return values need not be described, and the description covers purpose plus the snippet-vs-preview distinction. It leaves one gap: it advertises three embed types (button, pay card, goal bar) but the schema exposes no type/variant parameter, so how to choose among them is unexplained.

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

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

Schema coverage is 100%, so both parameters (text, position) are fully documented in the schema including defaults, maxLength and enum values. The description adds no syntax or meaning beyond that, 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 (get) and resource (HTML embed code) and enumerates the three embeddable artifacts: support button, pay card, live goal bar. It does not explicitly contrast with the near-siblings get_share_assets and get_stream_overlays, so an agent must infer which embed tool fits which surface.

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 scopes the tool to 'the creator own website or blog,' which implies when it is appropriate, but there is no explicit when/when-not or naming of alternatives such as get_share_assets or get_stream_overlays for other surfaces. 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the response contains impact tiers and progress notes, which is light additional context, especially since an 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 sentence, front-loaded with the verb and resource, with the returned payload named immediately after. Nothing is redundant or padded.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety semantics; the description's job of stating purpose and payload scope is done. The only gap is the unexplained id parameter, which the schema leaves undocumented.

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

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

Schema description coverage is 0% and the sole 'id' parameter is an untyped-in-prose integer with no explanation in either schema or description. The phrase 'one goal' weakly implies the id identifies the goal to fetch, but format or source of the id is never clarified.

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 ('Read one goal') plus the scope of what is returned ('in full, including its impact tiers and its progress notes'). It is distinguishable from list_goals and create_goal/update_goal by the singular, read-only framing, though it never names a 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?

There is no when-to-use guidance and no routing against alternatives such as list_goals (for many goals) or get_analytics/get_dashboard_summary (for aggregated goal data). The single-goal scope is implied by 'one goal' but the agent must infer that a goal id is a prerequisite.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds the domain-status vocabulary (pending/active/disabled) and the fact that data comes from the signed-in account, but says nothing about auth requirements or failure modes.

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 action first and the field list after; no preamble or filler. Every clause is either the verb/resource or the return inventory.

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 an output schema present, the description needn't enumerate return values, and annotations cover the safety profile, so coverage is nearly complete. The only gap is sibling disambiguation against get_page_settings and get_custom_domain, which share overlapping scope.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly conveys the implicit scoping (the caller's own account) rather than a required identifier.

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 ('Read') and resource ('page details for the signed-in creator') and enumerates the returned fields, so an agent knows exactly what it fetches. It does not, however, distinguish itself from overlapping siblings like get_page_settings or get_custom_domain, which also surface page/domain data.

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

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

The phrase 'for the signed-in creator' implies the no-argument, self-scoped use case, which is useful context. But there is no explicit when-to-use guidance or exclusion relative to siblings such as get_page_settings, get_dashboard_summary, or get_custom_domain, so routing must be inferred.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description's only added behavioral value is listing the settings content, which is largely redundant with the existing output schema, leaving no new disclosure about auth, limits, 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?

A single front-loaded sentence with the verb and resource up front and no filler. The inline list is slightly dense but every item is informative and there is no wasted prose.

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

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

For a zero-parameter read tool with an output schema covering return values and annotations covering the safety profile, the description supplies enough context to call it correctly. Nothing essential is missing, though it could note the read-vs-update relationship for completeness.

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 per the rubric the baseline is 4. There are no parameter details the description could add or omit, and the field enumeration pertains to output rather than inputs.

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 (Read) and resource (appearance and behaviour settings for the page) and enumerates the concrete settings returned (theme, banner, suggested amounts, visibility, thank-you note). This clearly distinguishes it from the write counterparts update_page_appearance/update_page_behaviour, though those siblings are not named explicitly.

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

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

Usage is only implied: as a read tool the description suggests calling before updating via the siblings, but it never states when to use it, when not to, or which alternative to prefer. No prerequisites or sequencing guidance are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false. The description adds real value on top by explicitly stating that nothing here starts, changes or cancels a subscription, drawing a clear boundary against mutation behavior an agent might otherwise assume from a plan/billing topic.

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

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

Two sentences with zero filler. The content list is front-loaded and the safety boundary is appended where it is most useful.

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?

An output schema exists, so return-value detail is not the description's burden. With annotations covering the safety profile and the description covering scope and content, nothing an agent needs to call this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the empty schema is unambiguous.

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 (read) and enumerates exactly what is read: current plan, Premium expiry, whether it is set to end, and past charges with invoice links. An agent knows precisely what this returns, and no sibling tool covers billing, so there is no ambiguity to resolve.

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 enumerated content makes the use case obvious (checking subscription status or billing history), and the closing clause scopes it away from subscription management. It does not name an explicit when-to-use trigger or an alternative sibling, but no billing alternative exists, so the implicit guidance is sufficient.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral context: results are returned as links to open or download, not as images, and it explains the UPI QR conditional (only when the counter QR is switched on).

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 dense but well-organized sentence covering all assets plus a short clarification about link-vs-image. Front-loads the primary asset (page address) first. Slightly run-on with parenthetical, but 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?

Output schema exists and annotations cover safety, so the description needn't explain return values. It nonetheless clarifies the crucial 'links not images' format and the conditional UPI QR, which are the main points an agent would otherwise miss. Complete enough for a zero-param read 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?

Zero parameters, so baseline is 4. The description appropriately spends no effort on parameter syntax and instead clarifies the conditional content of the return (counter UPI QR) which is the only real variable.

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 (get) and enumerates the concrete resources returned: page address, QR code, share images, and printable sheets. This is clearly distinguishable from siblings like get_embed_code or get_page_settings.

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 well by the title 'Get my page link...' and the description's enumeration, and it's clearly distinct from get_embed_code (HTML embed) and get_stream_overlays. However, it never explicitly says when to prefer this over those 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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds that alert firing rules and per-source sizes are included, which is mild value, but says nothing about auth needs, whether addresses are stable across calls, or any regeneration 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, front-loaded with the core action ('Get the three overlay addresses'), then the enumerated outputs and the bonus contents. No filler and nothing that could be trimmed without losing 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?

An output schema exists, so the description need not explain return values, and it still names the three overlay artifacts plus the ancillary size/timing data. Adequate for a zero-required-parameter read tool; only the absence of any sibling-routing or auth note keeps it from being fully 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 language, wallRows and alertSeconds are already fully documented in the schema. The description adds no parameter meaning beyond that, which lands at the baseline 3.

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

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

States a specific verb and resource ('Get the three overlay addresses') and enumerates exactly what the three are: goal bar, supporter wall, alert. An agent immediately knows the payload, though it does not explicitly distinguish itself from adjacent siblings such as get_embed_code or get_share_assets.

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 'to add to OBS or any streaming software as a browser source' supplies the use context, which is more than nothing. But it gives no conditions, prerequisites, or guidance on when to pick this over the embed-code or share-asset siblings.

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, idempotentHint, destructiveHint=false and closed-world scope, so safety is fully covered. The description adds one useful behavioral nuance — the result is bounded by what 'the creator can see', implying permission-scoped visibility — but says nothing about pagination, shape, or missing-id 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?

A single front-loaded sentence containing the verb, the scope limitation, the resource, and the lookup key. No filler and nothing redundant.

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

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

An output schema exists, so return contents need no explanation, and the tool is a trivial one-param read whose annotations fully describe its behavior. The description is adequate for the complexity, with only the visibility-scoping statement doing extra work.

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 the single id parameter is already documented as coming from list_supports/list_pending_supports, so the description adds nothing beyond 'by its id'. Baseline 3 applies when the schema carries the parameter semantics.

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?

Specific verb + resource + cardinality ('Read everything ... about one supporter, by its id'), which cleanly separates it from the singular-vs-list siblings list_supports and list_pending_supports. It stops short of naming those siblings explicitly, 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: the phrasing 'by its id' plus the schema note 'From list_supports or list_pending_supports' hints that this is the follow-up lookup after a listing call. There is no explicit statement of when to use this versus fetching via a list tool or when not to use it.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond what the annotations provide; its remaining content is really return-value framing, which the output schema already covers.

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

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

Two sentences, front-loaded with what is being broken down before the use case. The source enumeration is longer but each item maps to a distinct channel, so it earns its length; only slight trimming is possible.

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

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

For a simple two-optional-param read with a full output schema, annotations covering safety and a schema covering inputs, the description is nearly sufficient. The only material gap is routing against the overlapping analytics/support siblings, which it never addresses.

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 'from'/'to' date parameters are already documented with format (YYYY-MM-DD) and semantics in the schema. The description adds nothing about the parameters or default date scoping, 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 ('break approved support down by where it came from') and enumerates the concrete source categories, so an agent knows exactly what dimension is being attributed. It does not name a sibling such as get_analytics or get_support to differentiate itself, which caps it below 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 second sentence gives a clear use context ('Use this to answer which channel is actually working'), which is a genuine scenario statement rather than a restated purpose. It stops short of naming alternatives or exclusions (e.g., when to prefer get_analytics), so it is not a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the plan-availability fact ('free on every plan'), which is real value beyond annotations, but it does not cover pagination, scope, or any other behavioral trait. An appropriate 3 given the low bar set by rich annotations.

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

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

Two short clauses, front-loaded with the resource name and the returned metrics, with no filler. Slightly dense enumeration of return fields could be trimmed, keeping it just shy of a 5.

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?

An output schema exists, so the description is not obligated to enumerate return values, yet it does so helpfully. With a fully documented single optional parameter and complete annotations, the definition gives an agent everything needed to invoke it correctly. It remains silent on scope/pagination, but that is minor for a read-only summary 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 coverage is 100% and the single optional 'year' parameter is fully documented in the schema, including its default. The description only alludes to 'for a year' without adding format, bounds, or default behavior, so the schema does the heavy lifting. Baseline 3.

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

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

States a specific resource ('Kulhad Wrapped for a year') and enumerates exactly what it returns: number of supporters, total, page views, busiest month, largest single support. This is distinguishable from get_analytics and get_dashboard_summary by the named year-in-review data points. It stops short of explicitly contrasting itself with those siblings, 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?

'Free on every plan' tells the agent there is no plan-gating prerequisite, which is genuinely useful eligibility context. However, it never says when to reach for this versus get_analytics or get_dashboard_summary, nor any exclusions, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still earns credit by disclosing two things annotations cannot: the sort order (active goal first) and the payload shape (raised amount vs target). It omits pagination/limit behavior for large goal sets, keeping it out of 5 territory.

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, front-loaded with the verb and resource, then the ordering and the per-item metric. Every clause carries information an agent needs; 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?

An output schema exists, so the description is not obligated to detail return values, and it still summarizes them briefly. For a zero-argument, read-only list scoped to the caller's page, nothing an agent needs in order to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics to describe or omit. The description correctly adds nothing here rather than padding.

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?

Specific verb (list) plus resource (goals) plus scope ('every goal on the page'), which implicitly separates it from the singular get_goal sibling. It also states ordering (active first) and the metric returned. It never names a sibling explicitly, so it stops short of a 5.

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

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

Usage is only implied: the word 'every' signals this is the enumerate-all path versus get_goal for a single goal, and set_active_goal for reordering. There is no explicit when-to-use/when-not statement and no mention of prerequisites such as having at least one goal configured.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds genuinely useful behavioral context beyond them: the listed data is unverified self-reported claims ('what people say they sent, not what has been received') because Kulhad cannot see bank accounts. That trust caveat materially affects how an agent should interpret and relay results.

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 purpose and then the trust caveat and workflow. Each sentence contributes, though the third sentence's workflow detail is slightly more than a list tool strictly needs; no filler or redundancy is present.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. Given a single trivial parameter, the description covers the one thing structured data cannot: what the listed records actually mean and the review step that follows. Nothing an agent needs to call or interpret this tool is missing.

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

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

There is a single parameter (limit) with 100% schema description coverage, so the schema fully documents it. The description adds no syntax, default, or format detail beyond the schema, which is the expected baseline of 3 when the schema does the heavy lifting.

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

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

The description states a specific verb (List) and resource (supporters) with a precise state filter: those who marked payment as sent and await creator approval. This distinguishes it cleanly from list_supports (all supports) without needing to name the sibling, since the 'waiting for approval' qualifier is unambiguous.

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

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

It establishes the workflow context: the creator reviews this list, checks their bank app for the amount and four-character code, then approves. That implicitly points to approve_support as the follow-up action. It stops short of an explicit when-to-use-this-vs-list_supports statement or exclusions, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered and the bar is lower. The description still adds behavior the annotations don't: results come back 'newest first' and are filterable by status or date range. It omits pagination behavior and whether hidden/rejected records appear by default.

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, and the important scoping detail ('newest first') is front-loaded before the tool-selection guidance. 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?

An output schema exists, so return values need no explanation, and the description covers purpose, filters and the sibling boundary. For a 5-parameter, 0-required paging tool, the only real gap is pagination behavior (default limit of 25, max 100), which an agent must infer from the schema defaults.

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 60%, with 'to', 'from' and 'status' (including the 'claimed' gloss) already documented in the schema. The description only re-states that these filters exist and says nothing about 'page' or 'limit', the two undocumented parameters, 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?

The description states a specific verb and resource ('List supporters'), plus two distinguishing traits: default ordering ('newest first') and supported filters ('by status or by date'). This lets an agent separate it from list_pending_supports without reading 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?

It gives explicit positive contexts ('history', 'questions about a particular period') and names the alternative tool for a different intent ('use list_pending_supports for the approval queue'). The routing decision is fully 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds domain behavior the annotations cannot: that these are supporter payment addresses and that the free plan keeps only one active at a time, which affects how results should be interpreted. It does not describe ordering or pagination, but with an output schema present that gap is minor.

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

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

Two short sentences, front-loaded with the core action and followed by the one piece of domain context that matters. No filler or repetition of the title.

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

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

For a zero-parameter, read-only list tool with an output schema, the description supplies what the agent needs: what is listed, what the items represent, and the plan constraint on active IDs. Return values need not be explained since an output schema exists, though result ordering/limits are not mentioned.

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 and the baseline of 4 applies. No parameter-related claims are made or needed.

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

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

States a specific verb ("List") and resource ("UPI IDs on the account"), and even defines what a UPI ID is ("addresses supporters pay into"). It doesn't explicitly name sibling tools like add_upi_id or set_default_upi_id, but the read/list framing distinguishes it from the mutation siblings.

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

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

Usage is only implied: an agent can infer you call this to see existing UPI IDs. There is no explicit when-to-use, no statement of prerequisites, and no routing to alternatives such as set_default_upi_id or set_upi_rotation when the intent is to change rather than view them.

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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description discloses a 280-character cap, a 20-note retention limit, newest-first ordering, visibility on the goal page while active or complete, no cost on any plan, and that nobody is notified. That is substantive behavioral context an agent cannot get from the structured fields.

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, zero redundancy, with the core action and size constraint front-loaded before the retention and visibility details. Every sentence adds distinct 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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The description covers limits, retention, and visibility well, though it never clarifies what goalId refers to or whether the target goal must be active — the one remaining gap for a two-parameter mutation.

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 50% — 'body' is documented in the schema and the description's 280-character statement only echoes its maxLength. The 'goalId' parameter is undocumented in both places, so the description does not compensate for the coverage gap. 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 ('Add a short note') on a specific resource (a goal's progress note) and clarifies what the note contains ('saying what the money did'). An agent can distinguish this from update_goal or delete_goal_update without opening the schema.

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

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

The description implies context (a note about what the money did, shown on the goal's page) but never states when to post an update versus updating the goal itself, nor any prerequisite such as the goal needing to exist or be active. Usage is inferable but not spelled out.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description goes well beyond them: irreversibility ('cannot be undone'), immediate deletion of the voice recording, the record being cleared a week later, and the absence of any page notification or supporter message. That is concrete, actionable side-effect disclosure.

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, zero filler, and correctly front-loaded: the usage condition comes first, followed by the irreversibility warning and the side-effect timeline.

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?

An output schema exists, so return values need not be described. Given the tool is a simple destructive single-record operation, the description covers trigger, reversibility, deletion timing, and external visibility completely.

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

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

Schema description coverage is 0% for the single 'id' parameter, so the description has to carry the burden. It implies the id identifies one supporter (framing the operation as single-target versus bulk), but never states the id's format or which entity it indexes, leaving real ambiguity.

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 (reject) and resource (one supporter), plus the exact trigger condition (payment not found in bank). The 'one supporter' scope cleanly separates it from sibling bulk_reject_supports, and the reject-vs-approve polarity distinguishes it from approve_support.

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 when-to-use condition: reject when the creator has verified the bank and the payment is absent. It does not explicitly name alternatives such as approve_support or bulk_reject_supports, but the single-supporter versus bulk distinction is implied by 'one supporter'.

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 idempotentHint=true, so the safety profile is covered. The description adds valuable context about the consequence: printed materials with the old domain stop working, which is beyond what annotations say. It doesn't discuss reversibility, but idempotent/destructive hints partly cover that.

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

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

Two tight sentences that front-load the action and consequence. Every clause earns its place with 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?

For a zero-param destructive action with an output schema and rich annotations, the description gives the necessary warning and outcome. Nothing an agent needs to decide to call it 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?

Zero parameters, so baseline is 4. The description appropriately doesn't invent parameter details where none exist.

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 (disconnect) and resource (custom domain) and names the resulting state (page served from its kulhad.co address again). It is clearly distinguishable from siblings like set_custom_domain, get_custom_domain, and verify_custom_domain.

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 concrete warning to confirm with the creator first before invoking, which is a form of pre-condition guidance. It doesn't explicitly name alternatives, but the sibling set makes the intent unambiguous.

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

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

The annotations already mark this as destructive and not read-only, but the description adds important consequences: 'This cannot be undone, and past supports lose the link to it.' It also gives the exception condition and the non-destructive alternative, going well beyond the structured hints.

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

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

The description is three compact sentences and is front-loaded with the core action. Each sentence adds a distinct constraint or consequence: removal, exception, irreversibility, and alternative.

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?

An output schema exists, so return values need not be explained, and the annotations cover the destructive/idempotent profile. The description covers the operation's key behavioral constraints well, though it leaves the single required parameter 'id' unexplained.

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 only one parameter, 'id', with 0% description coverage. The description never explains that the required integer is the UPI ID's identifier or what value should be supplied, leaving the parameter meaning to inference from the tool name alone.

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

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

The description uses a specific verb and resource: 'Remove a UPI ID from the account.' It also distinguishes the action from the safer alternative by stating that 'switching it off instead keeps it,' which helps separate removal from update or deactivation siblings.

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

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

It explicitly states when removal is not allowed: 'The last one, and the only active one, cannot be removed.' It also gives the alternative behavior: 'switching it off instead keeps it,' so an agent can choose between permanent removal and deactivation.

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

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

Annotations already flag this as a non-read-only, destructive, idempotent, closed-world write, and the description adds substantial context beyond them: replacement with no history, the inability to blank the reply, refusal of links and flagged words, dual visibility surfaces (creator page after approval vs. supporter receipt link), and that no notification is sent. This is exactly the mutation detail an agent needs.

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

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

Front-loaded with verb, resource, and the length constraint, then layered with visibility and side-effect clauses. Every sentence carries distinct behavioral information, though the visibility sentences are dense and could be tightened; there is 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?

An output schema exists, so return values need no explanation, and the description covers the remaining gaps: scope (one supporter), validation limits, replacement semantics, visibility timing, and the absence of notification or approval side effects. Nothing required to invoke it correctly is missing.

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

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

Schema coverage is 50%: 'reply' is documented in-schema but 'id' is not. The description compensates by tying the write to 'one supporter' (implying id targets a single supporter) and by disclosing validation rules for reply — 280-character cap, links and flagged words refused — that the schema's maxLength alone does not convey.

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

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

States a specific verb and resource ('Write or replace the thank-you beside one supporter') plus a hard constraint (280 characters). It further differentiates itself from nearby write-siblings by declaring 'Does not approve anyone and sends nothing', so an agent can separate it from approve_support 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 clear context on when this applies (a thank-you for one supporter) and explicit exclusions relative to siblings ('Does not approve anyone and sends nothing'), which rules out approve_support. It stops short of naming a preferred alternative tool or stating prerequisites for the supporter's state, so it is clear but not fully routing.

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 cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description goes well beyond them by enumerating the absent side effects — nothing recorded, no goal movement, no thank-you — and by giving latency behavior (~5s to appear, gone after 6s). That is exactly the context an agent needs to know this is a throwaway call.

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: purpose first, then the negative side-effect list, then timing. Every sentence carries distinct information and none repeats the title or annotations.

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 an output schema present, return values need no explanation, and the description covers the remaining unknowns: ephemerality, latency, and absence of persistent effects. Complete for a zero-parameter test-fire 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify or compensate for. It correctly spends no words on arguments.

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 (fire) and resource (test alert) plus the reason it exists: previewing placement in OBS during setup. Nothing in the sibling list overlaps with this, so an agent can route to it unambiguously.

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

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

Clearly frames the context of use ('while setting up', to see where the alert lands in the overlay) rather than the real alert flow. It does not explicitly name alternatives or say when not to use it, but no sibling is close enough to require an exclusion.

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 non-destructive, idempotent, non-read-only behavior, so the bar is lower. The description still adds real value by explaining the mechanism ('puts the others away without deleting anything') and explicitly flagging reversibility, which clarifies that other goals are deactivated rather than removed.

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, front-loaded with the primary action and immediately followed by the side effect and reversibility note. No filler, every clause carries information.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description covers the single-active-goal model and reversibility, though it could note that a missing/absent id leaves no goal active; still adequate for a 2-param mutation tool.

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

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

Schema coverage is 50%: 'active' is documented in the schema, while 'id' is not. The description's 'turn the current one off' maps onto the active=false case but does not add format or meaning beyond what the schema already states, so the id gap remains uncompensated. Baseline 3 fits.

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 (make active / turn off) and resource (goal shown on page), and clarifies scope against siblings like update_goal and delete_goal by noting nothing is deleted. An agent can distinguish this from create_goal, update_goal, and delete_goal without opening schemas.

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

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

Implies when to use it via 'The page shows a single goal at a time, so choosing one puts the others away,' which explains the consequence of the action, but it never explicitly contrasts with alternatives such as update_goal (to edit goal content) or list_goals. 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?

Beyond the annotations (destructiveHint=true, idempotentHint=true), it discloses what actually gets destroyed: any existing — including working — domain stops serving until verify_custom_domain passes again, so the creator should be consulted. It also clarifies the entitlement requirement (Premium) and the critical non-behavior that it does not touch DNS or activate the domain, which is exactly what an agent needs to avoid misrepresenting the effect.

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 action, then the destructive warning, then the clarification of scope. Every sentence carries distinct, necessary information with 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 an output schema present, return values need not be explained; the description still covers the operation's effect, its prerequisite, and the required follow-up tool. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, and the schema already supplies the example format (priya.in). The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: it records the desired domain and returns the DNS record to add. It is immediately distinguishable from siblings like verify_custom_domain (which checks) and remove_custom_domain (which removes).

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

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

It gives clear context: this is a Premium operation, it warns to confirm with the creator if a domain is already active, and it routes the follow-up step to verify_custom_domain. It doesn't explicitly name get_custom_domain as the way to check current state, but the usage conditions are well covered.

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

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

Annotations cover the safety profile (idempotent, non-destructive, closed-world), and the description adds real behavioral context beyond them: other IDs stay on the account, and a default set on an inactive ID is never actually quoted. This edge-case disclosure is exactly the kind of value the description should add.

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 primary effect and followed by the caveat. The 'does not switch an ID on' clause and the 'inactive ID ... never quoted' clause partly restate the same point, a small redundancy.

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

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

For a one-parameter mutation with annotations and an output schema, the description covers the essential gotcha (inactive IDs are not activated by being made default). It omits error/permission behavior and how to discover the ID, but nothing critical to correct invocation is missing.

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

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

Schema coverage is 0% and the single 'id' parameter is undocumented, but the description's 'one active UPI ID' framing lets an agent infer the parameter is a UPI ID. It still does not say where to obtain the ID (list_upi_ids) or that the target must be active, so it only partially compensates for the coverage gap.

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

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

States a specific verb+resource effect ('Make one active UPI ID the one supporters are shown first'), which is clear enough to distinguish from update_upi_id, add_upi_id and set_upi_rotation. It does not name any sibling explicitly, so it stops short of the 5-level differentiation.

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

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

No when-to-use or when-not-to guidance is given, and no alternative is named (set_upi_rotation governs ordering among IDs and is the closest sibling). The only guidance is an implicit constraint that this reorders rather than adds or removes IDs.

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 the safety profile (destructive, idempotent, non-read-only); the description goes well beyond that by disclosing full-replace semantics rather than append, silent filtering of blank/link/flagged replies with counting, and that an empty list wipes everything. The destructive/hidden-loss behavior is exactly what an agent needs before calling.

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, front-loaded with the core action, then constraints, then edge-case behavior. Every sentence carries information the agent needs; 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 only one parameter, surviving annotations, and an output schema to cover return values, the description supplies everything else: replacement semantics, limits, silent-drop behavior, and the empty-list clear path. Nothing material 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 coverage is 0%, so the description must carry the meaning, and it does: at most 7 entries (maxItems in schema, but the description frames it as a rule), up to 280 characters each, and how individual entries are validated/dropped. It adds real semantics beyond the raw array schema, though it doesn't clarify whether duplicates or trimmed whitespace matter.

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 (replace/set) and resource (the creator's ready-made thank-you replies), plus scope: 'the list ... the creator picks from when approving a supporter.' That framing separates it from siblings like reply_to_supporter (sending an actual reply) and the approval tools.

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

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

It explains how to clear the list ('Passing an empty list removes all of them'), which is a partial usage instruction, but it never states when to choose this over alternatives or any prerequisites. Usage is implied rather than spelled out, so it sits at the minimum-viable level.

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

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

Annotations already declare this is a non-read-only, idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds the useful 'Part of Premium' gating fact, which is not in the annotations. It does not disclose what happens when toggled off (e.g., whether quoting reverts to a single default UPI ID) or any side effects on existing supports, so behavioral coverage is 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?

Two compact sentences with no filler, and the conditional 'When on' leads so the reader immediately anchors on the toggle state. The metaphor about support 'landing in one account' is slightly wordy but earns its place by clarifying the rotation concept. No structural waste.

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

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

An output schema exists, so return values need not be explained, and the Premium gate is surfaced. Missing pieces are the effect of disabling rotation, the relationship to set_default_upi_id, and whether the change affects in-flight or pending supports. For a simple boolean toggle this is adequate but leaves meaningful behavioral questions unanswered.

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

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

Schema description coverage is 0% for the single 'enabled' boolean, so the description must carry the meaning. 'When on, active UPI IDs take turns...' does imply what the boolean controls, giving partial compensation, but it never names or contrasts the on/off states explicitly. Baseline 3 is appropriate for a one-param tool where the description only indirectly conveys the flag's semantics.

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 explains the semantics of the resource (active UPI IDs taking turns being quoted so support spreads across accounts), which pairs with the name set_upi_rotation and the title to convey that this toggles that rotation behavior. It distinguishes itself from sibling UPI tools like set_default_upi_id by describing a rotation concept rather than a default selection. However, it never states the action in verb form (enable/disable rotation), leaving the tool's operation implied rather than explicit.

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 enable rotation versus using set_default_upi_id or other UPI siblings, and no exclusions. The only contextual signal is 'Part of Premium', which is a prerequisite, not usage routing. An agent must guess the appropriate scenario from the feature description alone.

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

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

Annotations only say it is not read-only, is idempotent, and is non-destructive; the description adds the actual side effect that matters — the name is marked as taken for check_username_available for fifteen minutes, but direct signups are not blocked, no account is created, and nothing is sent. This is exactly the extra behavioral context annotations cannot carry, and it does not contradict them (the reservation is a real mutation, consistent with readOnlyHint=false).

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

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

Five short sentences, front-loaded with what the tool returns and who consumes it, followed by the scope disclaimers. Every sentence carries distinct information (return value, recipient, no account, reservation window, nothing sent) with no 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 only one fully-described parameter and an output schema available, the description need not explain return values, and it spends its budget instead on the non-obvious behavioral boundaries. Nothing an agent needs to invoke this correctly or to set expectations with a user 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% for the single username parameter, including an example, so the schema already does the parameter work. The description adds only the framing that the name is both reserved and prefilled, which is useful but not syntax or format 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?

The description states a specific verb and artifact: it returns a link that opens Kulhad sign-up with a page name prefilled, to be handed to the person doing setup. It explicitly disambiguates from the sibling check_username_available (and from 'create account', which it says is impossible), so an agent can tell it apart without opening any schema.

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

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

It gives clear context for use: get the link, hand it to the person setting up the page, who finishes in a browser. It also draws boundaries (does not create an account and cannot; does not block direct signups). It stops short of explicitly naming when to prefer a different tool path, so it is strong context rather than full alternative routing.

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 idempotentHint=true, but the description adds genuinely non-obvious consequences: renaming breaks the old web address with no redirect, and changing the target does not re-evaluate goal completion. These are exactly the side effects an agent needs to warn about before calling.

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 field list, then partial-update semantics, then the two caveats. No filler, and each sentence carries distinct, actionable 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?

An output schema exists, so return values need no explanation, and the description covers all mutable fields plus their side effects. It omits permission/Premium requirements and behavior when the id does not exist, which is a minor gap for a six-parameter mutation.

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 only 50%, so the description must compensate, and it does: it names all five optional fields and adds meaning the schema lacks (impact replaces the entire list rather than merging, renaming mutates the URL, target edits skip completion checks). It does not clarify id semantics or the Premium gating on impact, so it falls short of a 5.

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

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

States a specific verb (change/update) plus the resource (a goal) and enumerates the mutable fields: title, target, description, deadline, impact tiers. This clearly separates it from create_goal, delete_goal, get_goal, and list_goals without needing to open any schema.

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

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

The description gives useful operational context ('Only the fields you pass change, and each replaces the old value') which tells the agent how to invoke it, but never states when to choose this over siblings like create_goal or delete_goal, nor any prerequisites or exclusions. Usage is implied by the field list rather than spelled out.

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

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

Beyond the annotations (destructive/idempotent already declared), the description adds meaningful context: each passed value replaces the current one, writes are scoped to the creator's own account, most fields are Premium-gated, and the GA ID is only stored locally with no Google contact. It does not describe failure modes or validation behavior, so it stops short 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?

Purpose is front-loaded in the first sentence, and the following sentences cover Premium gating, replacement semantics and account scope. Some redundancy with the schema's repeated "Premium." labels, but overall tight for an 8-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?

With an output schema present, annotations covering safety and full parameter documentation, the description supplies the remaining essentials (replace-don't-merge behavior, plan gating, account scope). Minor gaps remain around parameter interactions and error handling, but nothing critical for correct invocation is missing.

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

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

Schema coverage is 100% and every parameter is already documented, so the baseline is 3. The description adds a small conditional hint (custom colour is meaningful only when theme is "custom") but no syntax or value semantics beyond the schema.

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

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

States a specific verb ("Change") and two concrete resources (page theme, announcement banner), which cleanly separates it from siblings like update_page_behaviour, update_seo and update_profile. An agent can identify the tool's job without opening the schema.

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

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

Usage is implied by the scope (customize theme/banner appearance) but the description never states when to use this versus get_page_settings or the other update_* tools, nor any prerequisites. It leaves the routing decision to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuine behavioral context beyond them: passing amounts replaces all three suggestions, labels/headlines failing the word filter are silently blanked, changes affect future supports only, and writes are scoped to the creator's own account. Auth requirements and any propagation delay are still unstated, keeping it below 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?

The opening 'Change what the page does' is well front-loaded, but the long middle enumeration largely restates the schema property descriptions ('whether people may give without a name', 'whether the supporter count and total show') at length. The genuinely valuable sentences — word-filter blanking, replace semantics, future-only effect, account scope — are pushed to the tail.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile; the description covers scope, side effects, and replace semantics. The remaining gap is partial-vs-full update behavior for the nine non-amount fields, which an agent would want to know before calling.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning beyond the schema: 'Passing amounts replaces all three' clarifies replace-not-merge semantics for the amounts array, and it flags voiceBlessingsEnabled as Premium. It does not clarify whether the other boolean fields are partial or full replacements.

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 (change) and resource (page behaviour) and enumerates the settings under its control, so an agent can tell it configures a page's support-facing behavior. However, it never distinguishes itself from the very plausible sibling update_page_appearance (nor from get_page_settings), which is a real ambiguity in a 40-tool 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?

It gives some conditional guidance ('Passing amounts replaces all three', 'Affects future supports only') and the schema entry for streamAlertOn warns to only set 'claimed' when the creator asked. But there is no explicit when-to-use-this-vs-alternatives routing, which matters given the overlapping page-appearance sibling.

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?

Adds substantial value beyond annotations: it explains the immediate no-redirect breakage of the old address, QR/embed/overlay collateral damage, name release, custom-domain restriction, bio truncation at 280 chars, and link-list replacement. This goes well beyond destructiveHint/idempotentHint.

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

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

Front-loaded with the field list then consequences; every sentence carries weight. Slightly dense but well-organized, with the highest-impact warning (address change) placed before lesser constraints.

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 7 optional params, destructive annotations, and an output schema, the description covers the mutation semantics, irreversibility, and replacement behaviors an agent needs. Return values are covered by the output schema so needn't be repeated.

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 86%, so the schema already documents most parameters including bio truncation and the username/custom-domain constraint. The description largely mirrors that and adds only the link-replace behavior, which is also in 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 precise verb + resource and enumerates every mutable field (name, bio, username, kind, page/ui language, socials). It is clearly distinguishable from sibling tools like update_page_appearance and update_seo.

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

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

It clearly establishes partial-update semantics ('Only the fields you pass change') and flags the socials-replace rule. It doesn't explicitly route to siblings (e.g. check_username_available before username, or update_seo for SEO fields), leaving some alternative-selection gaps.

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 cover readOnly=false, idempotent=true, destructive=true, openWorld=false; the description reinforces closed-world behavior ('does not contact any search engine') and adds non-structural facts: Premium requirement, length limits, and blank-value reset semantics. It never explains what happens to the untouched field on a partial update, which is the main gap given destructiveHint.

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

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

Three tight sentences, front-loaded with the action, then constraints, then the two exclusions. Nothing is padding; the only slight redundancy is repeating the 60/160 limits already in the schema.

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

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

An output schema exists, so return values need no explanation, and the description covers limits, gating, side effects, and scope. It is close to complete for a two-field mutation; the only missing piece is partial-update/field-clearing behavior on an idempotent destructive write.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It maps each field to its meaning and adds the key semantic the schema lacks: a blank value restores auto-generated text. Content and character limits restate the schema's maxLength rather than extending it.

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

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

States a specific verb+resource (set the page's SEO title and description in the HTML head) and immediately scopes it: 'does not set an image and does not contact any search engine.' That distinguishes it from siblings like update_page_appearance/update_page_behaviour 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 context — Premium-gated, blank value reverts to Kulhad-generated text — and an explicit exclusion ('does not set an image'). It stops short of naming which sibling to use for the excluded cases, so routing is implied rather than directed.

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 say destructive=true and idempotent=true; the description goes well beyond that by disclosing concrete side effects: changing the address clears the test, the new address becomes what supporters are quoted and what past supports display, and disabling the default shifts quoting to the lowest active ID. The minimum-one-active invariant is also a real constraint an agent must respect.

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

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

Three tight sentences, front-loaded with the operations list followed by consequences. No filler and every clause carries either a capability or a side effect.

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 annotations covering safety and an output schema covering returns, the description supplies the missing behavioral layer. It could still say that updates are partial (only id required, other fields optional) to clarify how multi-field edits compose, but nothing critical is absent.

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

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

Schema description coverage is only 20% (testDone alone), so the description has to carry the load: it maps address->vpa, label, on/off->active, and the one-rupee test->testDone, and adds downstream meaning for vpa that the schema lacks. It still omits the expected VPA format and label constraints, so not a full 5.

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

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

The description names a specific verb (change) and resource (UPI ID) and enumerates the exact mutation surface: address, label, on/off state, and test-done flag. That scope cleanly separates it from add_upi_id, remove_upi_id, set_default_upi_id, and set_upi_rotation without needing to name them.

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

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

It gives clear operating context and constraints (at least one ID must stay active, switching off the default promotes the lowest active ID), which tells the agent when a call is legal. It does not, however, explicitly route the agent away from siblings like set_default_upi_id or remove_upi_id for those specific operations.

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 flag destructiveHint=true, but the description is what explains the destruction concretely: 'Clears the same domain from any other account's unverified claim.' It also discloses the DNS lookup (open-world behavior) and the propagation-delay failure mode. It stops short of covering idempotency semantics 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?

Four short clauses, action first, with the Premium gate and the failure-mode caveat following. Informal but no wasted sentences; the only weakness is the fragmentary 'Part of Premium.' clause, which reads more like a note than a structured precondition.

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?

An output schema exists, so return values need not be explained. The description covers the plan requirement, the cross-account side effect, and the expected transient failure, which is most of what an agent needs, with the parameter format being the notable omission.

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

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

One parameter with 0% schema description coverage, so the description carries the full burden and it doesn't deliver: it never states whether 'domain' is an apex domain, a subdomain, or includes a scheme/path. 'Look the domain up in public DNS' only weakly implies the parameter is a hostname.

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 concrete verb and resource ('look the domain up in public DNS') plus the consequential effect ('switch the page to it', 'kulhad.co/<name> then redirects there'). It doesn't explicitly name distinguish it from the sibling get_custom_domain or set_custom_domain, 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?

Gives useful preconditions and expectations ('Part of Premium', 'Fails until the record has propagated, which is normal for the first few minutes'), which implies it belongs in a post-DNS-setup flow. However, it never says when to prefer this over set_custom_domain or get_custom_domain, so the routing guidance is only implied.

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