Kulhad

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

Annotations already declare this is a non-read-only, non-idempotent, open-world write, so the safety profile is covered. The description adds genuinely non-structured context: the platform cannot validate the address's ownership, so the agent must direct the creator through a self-verification step. That is real behavioral guidance beyond 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?

Two sentences, purpose front-loaded and the caveat second, with no filler. Slightly terse given the verification instruction packs four ideas (no validation, self-test, wait, then share) into one sentence, but nothing is wasted.

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

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

An output schema exists, so return values need no explanation, and annotations cover the mutation profile. The description supplies the one thing an agent could not infer — that address validity is unverifiable and needs a manual check. Adequate for a three-parameter write 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% with all three parameters described (including examples for vpa and label), so the schema carries the load. The description adds no syntax, formatting, or constraint detail beyond it, which matches the baseline for high-coverage schemas.

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

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

States a specific verb and resource ('Add a UPI ID') plus the downstream purpose ('for supporters to pay into'), which cleanly separates it from siblings like update_upi_id or set_default_upi_id. It stops short of naming an alternative explicitly, so it is clear but not fully sibling-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?

It gives a useful workflow condition (verify by sending one rupee before sharing the page) but says nothing about when to add a new UPI ID versus updating an existing one, which is the most likely selection ambiguity given the sibling set. Usage context is implied rather than framed against 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 declare the mutation/idempotency/open-world profile, and the description adds real context beyond them: approval has a public side effect (publishes the supporter unless hidden is set), and the reply is publicly published and can be refused by a word filter. The remaining gap is error semantics for already-approved or invalid supporters, which the idempotentHint partly 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?

Three tight sentences, front-loaded with the action, then the side effect, then the safety rule. No sentence is filler and each contributes information the agent needs.

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 annotations plus the description cover the safety profile and the publication/reply behaviour. The only shortfall is not connecting 'id' to its source tool or describing the failure mode when the supporter was already approved.

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 both 'reply' and 'hidden' already carry descriptions, so the description's mention of them ('unless hidden is set', 'a thank-you reply can be sent at the same time') largely restates structured data. It adds no meaning for the undescribed required 'id' (e.g., that it must come from list_pending_supports).

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 scopes it to a single record, which implicitly separates it from the sibling bulk_approve_supports. An agent can distinguish it from related tools 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 an explicit precondition ('after the creator has found the payment in their own bank app') and an explicit prohibition ('never approve on their behalf without being asked to'). It also implies the alternative route by scoping to a single supporter, so both when and when-not are 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 already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds genuine context beyond them: a 'Part of Premium' gate and the skip semantics of 'anything already settled is left alone', which explains why the operation is idempotent.

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 action and resource, with every clause adding a distinct fact (scope, Premium gate, skip behavior). 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?

An output schema exists so return values need no explanation, and annotations cover safety. The description supplies the Premium requirement, the bank-check precondition, and idempotent skip behavior, leaving only the parameter-format details thin.

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

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

Schema coverage is 50% -- the required 'ids' array has no description in the schema. The description partially compensates by implying the ids target 'waiting' supporters and that settled ones are ignored, but it says nothing about the 100-item cap or the identifier format. Baseline 3 fits given schema does half the work.

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), resource (waiting supporters), and scope (several at once), which clearly distinguishes it from the singular approve_support sibling. The bulk nature is unambiguous from the phrasing.

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

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

Provides a meaningful precondition -- 'after the creator has checked their bank' -- but never explicitly contrasts with approve_support or states when bulk is preferable to single approval. Usage is implied rather than guided, with no exclusions named.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds value the annotations cannot: irreversibility ('cannot be undone') and an entitlement gate ('Part of Premium'). It still doesn't say what happens on partial failure within a batch.

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 action, then the gating condition, then the safety warning. 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 the description covers irreversibility, Premium gating, and pre-confirmation. The remaining gaps are batch-size limits and partial-failure behavior, which are minor but non-trivial for a bulk destructive operation.

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 one parameter (ids) at 0% schema description coverage, and the description never explains it, nor mentions the 1–100 batch limit encoded in maxItems/minItems. The meaning is only weakly inferable from 'several waiting supporters', leaving the agent to guess at ID semantics and bounds.

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 (waiting supporters), and batch scope (several at once), which cleanly separates it from the singular reject_support and from bulk_approve_supports. 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?

Adds two real usage conditions: the tool is Premium-gated, and the list should be confirmed with the creator beforehand. It stops short of explicitly naming reject_support as the single-item alternative, so the when-to-use-vs-sibling routing 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, 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 already declare the write/non-idempotent/non-destructive profile, so the bar is lower. The description adds real value: the created goal becomes the one shown on the page unless active=false, and the free plan runs only one goal at a time, both of which are behavioral effects not present in 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, each carrying distinct information, with the core action front-loaded and the side effect and limit following. 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the key behavioral caveats; only the premium/precondition aspects of impact and deadline are left implicit.

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

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

Schema coverage is 67%, so the schema already documents active, impact, and deadline. The description reinforces title/targetAmount and the meaning of active, but adds nothing for impact, deadline, or description, leaving partial gaps relative to the remaining coverage.

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

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

States a specific verb and resource ('Create a goal') and names the two identifying fields (title, target amount). However, it never distinguishes itself from nearby siblings like update_goal or set_active_goal, so the agent must infer the difference.

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 and no named alternative among the many goal-related siblings. The free-plan sentence is a constraint on the operation, not selection guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that: the no-support precondition, the fact that supported goals persist in history, and the explicit 'cannot be undone' warning about irreversibility.

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 precondition, then consequence, then the irreversibility warning. No filler and each sentence adds a distinct constraint.

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 preconditions and consequences well. The only gap is the semantics of the required 'id' argument, which is left entirely to the bare schema.

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

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

Schema description coverage is 0% for the single 'id' parameter, and the description says nothing about what the id refers to (goal id vs. other identifiers) or its expected form. With one undocumented param, the description fails to compensate for the schema 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 (Delete) plus resource (a goal) and adds a hard precondition ('that nobody has given to yet') that separates it from update_goal and delete_goal_update. An agent can identify the exact object and condition 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?

Explicitly defines when the tool applies (no support given) and what happens in the alternative case (a supported goal can only be turned off, never deleted), which routes the agent toward a different action. It stops short of naming the specific sibling tool to use instead.

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 covered. The description still adds value beyond that: it makes the blast radius explicit ('one progress note') and states irreversibility ('This cannot be undone'), which is stronger than the generic destructive hint. It stops short of describing failure behavior for an out-of-range index or permission requirements.

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

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

Two short sentences, no filler. The index semantics come first and the irreversibility warning is front-loaded rather than buried, so every sentence earns its place.

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

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

With only two required parameters, an output schema covering return values, and annotations covering the safety profile, the description supplies what is needed to invoke the tool correctly: the resource, the zero-based newest-first index, and irreversibility. The remaining gap is silent behavior on an out-of-range index.

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 already documented in the schema as 'Zero is the newest note,' which the description essentially restates. goalId is undocumented in both places, and the description does not compensate for it (e.g., whether the goal must exist or be owned by the caller). 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 ('Remove one progress note from a goal') and pins down the exact addressee mechanism ('by its position in the list, counting from zero with the newest first'). That is enough to distinguish it from sibling post_goal_update and get_goal/update_goal 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?

There is no when-to-use guidance, no statement of prerequisites, and no reference to alternatives such as post_goal_update for adding notes. The indexing rule tells the agent how to call it, not when to choose 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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that the tool is Premium-gated, but it says nothing about rate limits, whether the window is fixed or parameter-driven, or refresh latency.

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 returned data, and the Premium constraint is appended without padding. Nothing here is 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 described, and the Premium note is a real addition. However, the unresolved tension between 'last ninety days' and the days parameter (default 30) leaves the agent uncertain how 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 100%, so 'How many days back' is already documented with a default of 30 and a max of 90. The description's flat claim of 'for the last ninety days' instead conflicts with the parameter's default and makes the agent unsure whether 'days' controls the window or is ignored.

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

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

The description names the concrete data returned (daily page views, supporters, amounts, and visitor-to-supporter conversion rate), which is more specific than the vague title 'Read my page numbers'. It does not, however, distinguish itself from the plausible sibling get_dashboard_summary, so an agent gets no routing signal.

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 statement, no condition that selects this tool over get_dashboard_summary or get_wrapped, and no exclusions. The only guidance-like content is the 'Part of Premium' access note, which is a prerequisite rather than usage direction.

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

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

The 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, destructiveHint=false, and closed-world scope, so the safety profile is fully covered by structured data. The description adds value by concretely naming the metrics returned (month vs. last, all-time, supporter count, pending count), but says nothing about freshness, caching, or data staleness.

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 that leads with the resource ('headline numbers from the creator dashboard') and then lists the four metric groups. No filler, though the colon-and-list construction is slightly dense.

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 is not obligated to explain return structure, and it correctly focuses on what the summary contains at a high level. The only gap is the absence of any scoping note (whose dashboard) or distinction 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 there is nothing for the description to disambiguate; the 4 baseline applies. No parameter information is missing or misleading.

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 resource (creator dashboard summary) and enumerates exactly what the returned numbers are: month-over-month revenue, all-time total, supporter count, pending approvals. It is clear what the tool does, but it does not differentiate itself from siblings like get_analytics or get_wrapped, which could also plausibly return dashboard-style figures.

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: describing headline figures for a dashboard suggests 'use this for a quick overview', but the description never says when to prefer this over get_analytics or get_wrapped, nor states any prerequisites (e.g. that it returns only the authenticated creator's own data). No explicit when/when-not guidance is given.

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

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

Annotations already declare readOnlyHint, 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. The description adds the useful scoping detail that it targets the signed-in creator only, but discloses nothing further about freshness, pagination, or auth that isn't already structured.

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 that names the verb first and then the returned fields, with no filler or repetition. Nothing is wasted.

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

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

With an output schema present, the field enumeration is mild redundancy rather than a gap, and the read-only annotations cover the safety semantics. For a zero-parameter read this is complete, though it could have noted whether the read requires an active session.

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; the schema is empty and coverage is trivially complete. Baseline of 4 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?

Specific verb ("Read") plus resource ("page details for the signed-in creator") with an enumerated field list, which distinguishes it from setters like get_page_settings or update_profile. It stops short of naming an alternative explicitly, and the included field "plan" overlaps with the sibling get_plan_and_billing, so sibling differentiation is implied rather than stated.

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

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

The phrase "for the signed-in creator" implies this is the self-scoped read, but there is no explicit when-to-use guidance or routing to alternatives such as get_page_settings or get_plan_and_billing. Usage 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 already declare this a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: every asset is returned as a link to open or download rather than an embedded image, which changes how a caller must handle the 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 short sentences, with the payload enumerated first and the return-format caveat second. No filler and nothing redundant with the structured fields.

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 is not obligated to spell out return values, and with no parameters there is little else it must cover. It sufficiently frames what the call yields; only the missing link to related tools keeps it short of full 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 there is nothing to document and the schema imposes no burden. The description correctly does not invent parameter detail.

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

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

Names a specific verb ('Get') and enumerates exactly which assets are returned: page address, payment QR code, share images for stories/posts, and printable sheets. That is far more specific than a tautology, but it never distinguishes itself from siblings that also fetch page-related assets, such as get_embed_code or get_stream_overlays.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the sibling tools an agent might confuse this with (e.g., get_embed_code, get_custom_domain). Usage is only loosely implied by the enumerated asset list.

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

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

Annotations already declare readOnlyHint, 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?

Annotations already declare non-read-only, non-idempotent, non-destructive and open-world, so the bar is lower; the description still adds real behavioral context beyond them: public visibility ('Shown publicly'), ordering ('newest first'), a hard quota ('At most 20 per goal'), and no cost ('Free on every plan'). It does not mention auth/permission requirements or what happens past the 20-note cap.

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

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

Four short sentences, front-loaded with the core action before visibility, quota, and pricing details. Tight overall, though 'Free on every plan' is the weakest sentence for an agent deciding how to call the tool.

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

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

For a two-parameter mutation with an output schema already covering return values, the description supplies visibility, ordering, quota, and cost. It leaves auth requirements and the edit/delete counterpart (delete_goal_update) unaddressed, 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 50%: body carries a maxLength and description, while goalId has none. The description's 'short note' loosely corroborates the 280-char limit but adds no format, syntax, or identity semantics for goalId, so it does not compensate for the gap. Baseline 3 is appropriate for this coverage level.

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 ('Add a short note under a goal') and scopes the content ('saying what the money did'), which cleanly separates it from create_goal, update_goal, and the reply/support tools. An agent can identify this as the sub-resource-append operation 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 rather than stated: there is no when-to-use vs. when-not guidance, and the obvious alternative, delete_goal_update, is never mentioned. The 'at most 20 per goal' cap hints at a boundary condition but doesn't tell the agent what to do when exhausted.

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 value beyond that: the record is not published and is cleared a week later, i.e. a delayed soft-delete, plus the irreversibility. It doesn't cover auth requirements or the return shape, but the annotations plus this context are solid.

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 clauses, front-loaded with the action, then the condition, then the side effects. No filler. The trailing "This cannot be undone." could be folded in but is an effective standalone warning.

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 usage, effect, and permanence, leaving only the identity of `id` unaddressed and no routing to bulk_reject_supports for multi-record cases.

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

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

Schema description coverage is 0% and the single parameter `id` is never mentioned or explained. The description's reference to "one supporter" only weakly implies that id identifies the supporter record. With only one parameter the gap is small, but the description does nothing to compensate for the uncovered 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?

Specific verb+resource ("Reject one supporter"), with the word "one" implicitly distinguishing it from the bulk_reject_supports sibling. It is clearly not the approve path. It stops short of naming the sibling alternatives directly, so it lands at 4 rather than 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 a concrete when-to-use condition (creator checked the bank and the payment isn't there). It does not name an alternative (e.g. bulk_reject_supports) or state any exclusion, so it's clear context without routing guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the description isn't required to prove the write is destructive. It still adds real value by naming the downstream damage ('anything printed with the old domain on it stops working') and the resulting state, which annotations cannot express. It does not mention propagation timing or whether detaching is reversible.

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, with the action front-loaded and the caution placed after the consequence it justifies. Every clause earns its place.

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

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

With an output schema present and zero parameters, the agent needs only the effect and the risk warning, both of which are supplied, plus the annotation-driven safety profile. The only gap is the absence of an explicit alternative tool to consult when detaching is the wrong move.

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 baseline the description carries no parameter burden and none is needed. Nothing in the description contradicts or duplicates a parameter contract.

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 ('Disconnect the custom domain') plus the resulting state (page reverts to its kulhad.co address), which makes the operation unambiguous. It doesn't explicitly name siblings like set_custom_domain or get_custom_domain, but the verb choice alone separates it from them.

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

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

Usage is implied by the consequence statement and the caution to 'confirm with the creator first', which functions as a soft prerequisite. There is no explicit when-to-use vs. alternatives guidance (e.g., remove vs. verify vs. set), so an agent must infer the choice from the tool name.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real value beyond them: irreversibility ('this cannot be undone') and the account-level business rule that the final UPI ID is protected. It does not mention permission requirements or what the response returns, but with the output schema present that is acceptable.

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 the guardrail, then the consequence and alternative. 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 destructive single-parameter mutation with an output schema, the description covers the safety profile, the key constraint, and an alternative path. The only real gap is the meaning/format of the 'id' argument, 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% for the single required parameter 'id'. The description adds nothing about whether 'id' is the internal integer identifier or the UPI handle string, which is a genuine ambiguity given a UPI ID is normally a text handle. The description does not compensate 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?

Specific verb plus resource ('Remove a UPI ID from the account'), which cleanly separates it from add_upi_id, update_upi_id, list_upi_ids and set_default_upi_id. An agent can identify the operation 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?

It states a hard precondition ('the last one cannot be removed') and points to an alternative behavior when removal is undesirable ('switching it off instead keeps it'). It does not name the sibling tool that performs the switch-off, so routing is implied rather than explicit.

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

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

Annotations already declare mutation (readOnlyHint=false), idempotence, and non-destructiveness, so the bar is lower. The description adds two facts the annotations cannot convey: the reply is publicly visible on the page, and the operation deliberately does not alter approval state. It stops short of noting the 280-char limit or whether unapproved supporters can be replied to.

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, no filler, with the action stated first and the exclusion second. 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 cover the safety profile. For a 2-param mutation the description is nearly sufficient; only the meaning of 'id' and the public-visibility consequences on unapproved supporters are left implicit.

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

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

Schema coverage is only 50% — the 'reply' parameter is documented, but the required 'id' is not. The phrase 'beside a supporter' weakly implies id is a supporter id (versus goal/page/support ids used by many siblings), but this is inference, not specification. Baseline 3 with partial compensation.

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 pair (write/change) and a concrete resource (the public thank-you shown beside a supporter), and explicitly draws the boundary against the approval siblings with 'Does not approve them.' An agent can separate this from approve_support/reject_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 a clear negative condition ('Does not approve them'), which routes the agent away from the approval workflow, but never names an alternative tool or states a positive trigger (e.g. 'use when you want to respond to an already-approved supporter'). Clear context with no explicit 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?

With annotations already covering the safety profile, the description still adds meaningful behavioral detail beyond them: nothing is recorded, no goal advances, nobody is thanked, and the alert auto-expires after a few seconds. This is exactly the ephemerality and side-effect disclosure an agent needs for a fire-and-forget 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?

Three short sentences, front-loaded with what it does, then the non-persistence caveat, then the auto-expiry. Every sentence carries distinct information and none is padding.

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

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

An output schema exists, so return values need not be described, and there are no parameters to document. The description fully covers the only thing an agent could get wrong: assuming this produces a real support event.

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; the baseline for a 0-param tool applies. No misleading parameter language is present.

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

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

The description gives a specific verb and resource ('Fire a test alert') plus the exact reason ('so the creator can see where it lands in OBS while setting up'). It immediately distinguishes itself from the real support flow by stating 'It is not a real support', which separates it from siblings like approve_support or list_pending_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?

Usage context is clear: it is for overlay setup/positioning in OBS, not for real support events. It does not explicitly name an alternative tool or a when-not-to-use condition, but the 'not a real support' framing effectively tells the agent when this is the wrong choice for actual support handling.

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 (destructiveHint=false, idempotentHint=true, readOnlyHint=false), but the description adds genuine behavioural context beyond them: the page shows only one goal at a time, selecting one hides the others, and nothing is deleted. That directly answers the main agent worry for a mutation tool. It does not, however, describe error behaviour for an invalid id.

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 no filler. The primary action is front-loaded, and the second sentence exists to answer a specific question (does choosing a goal delete the others?).

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 idempotency and safety profile. For a two-parameter tool, the description supplies the missing semantic context (single-active-goal model, non-destructive behaviour). Nothing essential for a correct call 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 50%: the boolean 'active' is documented, but the required 'id' is not described anywhere. The description implies id selects the goal and 'turn the current one off' maps to active=false, so it partially compensates, but the parameter half-documented in the schema is the required one, leaving a real 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?

States a specific verb and resource: making one goal the one shown on the page, or turning the current one off. The phrase 'without deleting anything' implicitly distinguishes it from delete_goal, but it never names an alternative sibling outright, so it stops short of full 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?

Usage is implied by the described effect ('choose which goal the page shows'), and the mutual-exclusivity constraint tells the agent something about when this applies. However, there is no explicit comparison against update_goal or delete_goal, no prerequisites, and no statement of 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=false, idempotentHint=true, openWorldHint=true and destructiveHint=false. The description adds real value beyond them: the Premium gate, the fact that the write does not itself activate the domain, and the required external registrar action. It does not describe what happens on a repeat call for the same domain, which the idempotentHint only implies.

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

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

Three short sentences, front-loaded with the action and return value, then the limitation, then the follow-up tool. Nothing is wasted and ordering matches how an agent reads it.

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 one required parameter, an output schema covering the DNS record return, and full annotation coverage, the description supplies the missing operational context (Premium, two-step flow, registrar action). Only the behavior of re-submitting an existing domain is left to the idempotentHint annotation.

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 supplies example formats (priya.in, support.priya.in), so the baseline is 3. The description only restates the domain as 'the domain the creator wants in front of their page' without adding format, validation, or root-vs-subdomain guidance 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 ('Record the domain the creator wants in front of their page and return the DNS record to add'), which is clearly distinct from siblings get_custom_domain, verify_custom_domain, and remove_custom_domain. An agent can tell what it does without opening the schema.

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

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

Explicitly scopes the tool: it does not make the domain work, and the creator must add the record at their registrar before verify_custom_domain checks it. This routes the agent to the correct next tool. It lacks an explicit exclusion statement (e.g. what to do if a domain already exists), so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds a little scope context by stating the other UPI IDs remain on the account, reinforcing non-destructiveness, but says nothing about permissions, failure behavior, or what happens to the previously-default ID.

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 action, and the second sentence adds non-destructive scope rather than filler. 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 return values need not be described, and annotations cover the safety profile. However, for a single-parameter mutation the description leaves the parameter's meaning and the source of the ID unexplained, which is a real gap for correct invocation.

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

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

Schema description coverage is 0% and the description never references the single 'id' parameter — it neither names it nor explains that it is the numeric identifier of the UPI ID to promote, nor how to obtain it (e.g., from list_upi_ids). With one undocumented parameter, the description fails to compensate.

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 concrete verb and resource: make one UPI ID the one supporters are shown first. This is distinguishable from 'update_upi_id' (editing details) and 'set_upi_rotation' (rotating among IDs), though it never explicitly names those siblings to sharpen 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 — an agent can infer you call this when you want a different UPI ID shown first. There is no explicit when-to-use/when-not guidance and no mention of the closest alternatives (update_upi_id, set_upi_rotation), which an agent must disambiguate itself.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true, but the description adds real context the annotations don't carry: this is a full replacement rather than an append, an empty list deletes every entry, the 7-item cap, and that the feature requires Premium. The empty-list deletion is honestly disclosed, so it does not contradict destructiveHint=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?

Four short sentences, purpose front-loaded, then plan requirement, constraints, and the edge-case removal behavior. Every sentence carries information the agent needs and nothing is 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?

For a single-parameter setter with an output schema (so returns need no explanation), the description covers purpose, plan gating, limits, and the destructive edge case. Only failure behavior when caps are exceeded or Premium is missing is unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains the array's constraints (at most 7 items, 280 chars each) and, more valuably, the empty-list semantics that the schema cannot express. Only the error/behavior on exceeding limits is left implicit.

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 ("Replace") and resource ("the list of ready-made thank-you replies") plus the setting's role in the product ("the creator picks from when approving a supporter"). This is distinguishable from sibling reply_to_supporter, which sends a one-off reply, without opening either schema.

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

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

Usage is implied through the approval-support context and the "Passing an empty list removes all of them" note, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g. reply_to_supporter). Adequate but leaves 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?

Annotations already declare readOnly=false, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description's genuine addition is the plan-gating fact ('Part of Premium'), which an agent needs. It does not disclose what happens when the flag is set to off (e.g., reverting to a default UPI ID), leaving a behavioral gap for a mutation tool.

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

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

Two tight sentences with no filler; the functional effect is front-loaded and the plan-gating note follows. The phrasing 'take turns being quoted' is slightly indirect but still 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?

Complexity is low (one boolean, output schema present, rich annotations), so little detail is required. Still, the off-state behavior and any prerequisite of having multiple active UPI IDs are unstated, leaving an agent to guess at the practical effect of disabling rotation.

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 carries the burden and largely does: 'When on, active UPI IDs take turns' explains what true means in domain terms. It does not explicitly define the off-state, but it substantially compensates for the 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?

The description conveys the feature's effect ('active UPI IDs take turns being quoted') but never states the tool's own action — that it sets/toggles rotation on or off. An agent can infer it from the name and the 'when on' phrasing, but no explicit verb+resource is given, and it does not distinguish itself from siblings like set_default_upi_id or update_upi_id.

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

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

'Part of Premium' is a real usage prerequisite. However, there is no guidance on when to enable vs. disable rotation, no mention of prerequisites such as needing multiple active UPI IDs, and no routing to alternatives like add_upi_id or set_default_upi_id.

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

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

Beyond the annotations (which only flag openWorld, non-destructive, idempotent non-read), the description discloses two behavioral facts an agent cannot infer: no account is created, and the name reservation expires after fifteen minutes. The 15-minute TTL and the exclusivity guarantee ('so nobody else takes it') are exactly the kind of context annotations cannot carry.

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 action (get a link), then the human hand-off, then the scope limits. 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 only one fully documented parameter, an output schema that covers the return value, and annotations covering safety, the description supplies everything else an agent needs: the human-in-the-loop workflow, the reserved-name lifetime, and the fact that no account exists afterward.

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 already documents the single 'username' parameter with an example, so the baseline is 3. The description adds real meaning on top: the value is prefilled into a link and held for fifteen minutes, implying a uniqueness/reservation conflict if the name is taken, which clarifies what the parameter actually does.

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 a link that opens Kulhad sign-up with a page name already filled in.' The scope ('does not create an account') separates it conceptually from account-creating flows, but no sibling (e.g. check_username_available) is named, so the differentiation is implicit 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?

It clearly states how the tool is meant to be used: 'Hand the link to the person setting up the page: they finish it themselves in a browser.' That is a clear context with an implied exclusion (this is not an automated account-creation step), though it never contrasts with the closest sibling, check_username_available.

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

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

Annotations already establish non-destructive, idempotent mutation, so the description earns credit for what it adds beyond them: the patch semantics of 'only the fields you pass change' and the side effect that renaming relocates the goal's page URL. It stops short of stating permission/premium requirements or what the response returns, so it is not exhaustive.

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

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

Three short sentences, front-loaded with the action and field list, followed by the two highest-value caveats (patch semantics, URL change). Nothing is padded or 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 not be described, and the annotations cover the safety profile. Combined with the field enumeration, patch semantics, and rename side effect, an agent has everything needed to call this correctly.

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

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

With 50% schema description coverage the description meaningfully compensates by naming every mutable field and mapping 'target' and 'impact tiers' to targetAmount and impact. It still does not explain the required 'id' semantics (whose goal) or clarify the unit/limits already partially noted 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?

Opens with a specific verb+resource ('Change a goal') and enumerates the mutable fields (title, target, description, deadline, impact tiers), which cleanly separates it from create_goal, delete_goal, get_goal, and list_goals in the sibling set. The extra note that renaming moves the goal's own page address makes the scope 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?

'Only the fields you pass change' is a clear partial-update contract that tells the agent how to invoke it safely. However, it never names an alternative or a when-not condition (e.g., use set_active_goal to change active state, or get_goal first to read current values), so alternatives are left implicit.

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-read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely useful context beyond annotations: it flags which settings (themes, custom colours, own banner colour, badge hiding, GA ID) are Premium-gated. It does not describe what clearing a field does or any other side effects, but the annotations carry most of that burden.

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

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

Two sentences, front-loaded with the concrete scope and followed by the entitlement list. No filler, and the reader gets the mutation target immediately.

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

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

An output schema exists so return values need not be explained, and annotations cover the safety profile. The description supplies Premium context for a mutation tool with 8 optional parameters. It is adequate; only the missing usage routing 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 the schema already documents all 8 parameters, including clear semantics like empty string clears a value and the YYYY-MM-DD India-time end date. The description only adds Premium gating and does not contribute syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a clear verb and two specific resources: 'Change the page theme and the announcement banner across the top of it.' An agent can parse what is being modified. It does not, however, explicitly distinguish itself from closely-named siblings like update_page_behaviour or 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?

There is no when-to-use guidance, no prerequisite conditions, and no pointer to alternatives such as get_page_settings for reading or update_page_behaviour for other page-level changes. The only contextual note is the list of Premium-gated features, which is entitlement info rather than usage 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?

The annotations already declare this is a non-destructive, idempotent, open-world mutation, so the safety profile is covered. The description adds no behavioural context beyond purpose, though it does implicitly communicate that the change is a settings mutation affecting a live page. No auth or partial-update semantics are disclosed.

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 a colon-delimited list; no filler or redundancy. The list is slightly long but each item maps to a real configuration area.

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 11 optional parameters, no required fields, and an output schema present, the description omits the one fact an agent most needs for correct invocation: whether unspecified settings are preserved or reset. Otherwise the enumeration plus full schema coverage is adequate, but the partial-update semantics gap is material for a tool like this.

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 individual property descriptions are rich (the streamAlertOn enum carries its own cautionary guidance). The description only gestures at the same fields at a summary level, adding no new semantics, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Change what the page does') and then enumerates the exact behavioural settings it governs: auto-publishing, anonymity, public display, suggested amounts, and the post-payment note. This enumerations lets an agent separate it from siblings like update_page_appearance, update_seo, and update_profile without opening any schema.

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

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

The description says nothing about when to call this versus the other page-mutation tools, nor about prerequisites or the fact that all 11 parameters are optional. An agent must infer from the field list alone that this is the tool for behavioural configuration.

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond them by stating merge semantics for the mutation. It still omits the custom-domain restriction on username and the socials list-replacement behavior, but those live in the schema.

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

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

Two sentences, zero filler, with the scope of the change front-loaded and the partial-update rule immediately after. 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 annotations cover the safety profile. With 86% schema coverage and 0 required parameters, the description supplies enough for correct invocation; only the relationship to the other page-editing siblings is left unaddressed.

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

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

Schema description coverage is 86%, so the schema already documents almost every parameter in detail (including the username/custom-domain constraint and socials replacement). The description only restates the field set in prose and never mentions uiLanguage or pageLanguage at all, so it adds little beyond the schema. 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 gives a specific verb (change) plus an explicit enumeration of the editable resources: creator name, bio, page address, kind of page, and links. That field list implicitly separates it from siblings like update_page_appearance, update_page_behaviour, and update_seo, but no sibling is actually named, so the differentiation is left 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?

The sentence 'Only the fields you pass are changed; anything you leave out stays as it is' tells the agent how to invoke the tool correctly (pass only the deltas, no need to resend full state). However, there is no explicit when-to-use/when-not-to-use guidance and no mention of the neighbouring update_* tools that touch other parts of the page.

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 a non-read-only, idempotent, non-destructive, open-world mutation, so the safety profile is covered. The description adds genuinely useful context beyond that: a Premium gating requirement and the reset-to-auto behavior when a field is left blank. It stops short of 5 because it promotes a share-image field that the schema does not expose, which could mislead an agent about available 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, front-loaded with the operation, followed by the two caveats an agent needs (Premium gate, blank-reverts behavior). Tight and waste-free. The only drag is the share-image clause, which spends words on a capability the schema does not support.

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 cover the safety profile, leaving the description responsible only for gating and default semantics, which it supplies. It is nearly complete for a 2-param tool, with the main gap being the unsupported share-image mention and the absence of partial-update clarity.

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 carries the burden. It does map language to both parameters ("the title and description search engines show") and explains the blank-equals-default rule. But it adds no length/format guidance for seoTitle (60) or seoDescription (160), and its third named item (the share image) has no corresponding parameter, leaving the semantic picture partly inconsistent.

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 pairs a specific verb ("Set") with the concrete resources it governs: the search-engine title, the search-engine description, and the social share image. That scope cleanly separates it from siblings like update_page_appearance and get_page_settings. It loses a point because the share-image capability it advertises is not backed by any parameter in the schema, slightly overstating what the tool does.

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?

"Part of Premium" and "Leaving a field blank goes back to the one Kulhad writes" give real usage context: a tier requirement and a clearing/default semantic. However, it never states when to reach for this tool versus alternatives, nor that omitting a field leaves it untouched (as opposed to clearing it), which is the ambiguity an agent most needs resolved.

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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses a real side effect: changing the address clears the one-rupee verification because it proved the old address. It also states the active-count invariant. It adds genuine behavioral context, though it says nothing about auth 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?

Three tight sentences: purpose first, then two behavior/constraint notes. Every sentence carries information and nothing is redundant or buried.

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

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

An output schema and safety annotations exist, so return values and the read/write profile are already covered. The description supplies the mutation side effect and invariant an agent needs; only auth/permission requirements are unaddressed, a minor gap for this 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?

With only 20% schema coverage, the description compensates by mapping 'address' to the vpa parameter, 'label' to label, and 'switch on or off' to active, and it ties the one-rupee check (testDone's concern) to address changes. Four of five parameters gain meaning not present in the schema, though the id parameter is left implicit.

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 specific verbs and resource: changing the address or label of a UPI ID, or toggling it on/off. It clearly maps to the update operation, distinguishing it from add_upi_id and remove_upi_id by the word 'Change'. It stops short of naming siblings explicitly, but the purpose is unambiguous.

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

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

The description gives an invariant ('At least one ID has to stay active') that constrains when a toggle-off is valid, but it never names alternatives such as add_upi_id/remove_upi_id/set_default_upi_id or states when to prefer this over them. Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true and destructiveHint=false, but the description goes well beyond them: it discloses the DNS dependency, the conditional mutation of the page, the Premium entitlement requirement, and the transient propagation failure mode with an explanation that it is normal. That is exactly the operational context an agent needs before retrying or reporting an error.

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, each carrying distinct information: the action, the entitlement gate, and the expected failure window. The action is front-loaded and there is no filler.

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

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

Since an output schema exists, return values need not be described, and the description covers the mutation, the gate and the failure mode. The remaining gap is the success-vs-mismatch branch (what happens when the DNS record points elsewhere) and how it relates to the get/set/remove_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?

Schema description coverage is 0% for the single 'domain' string parameter, so the description has to compensate. It clarifies that the value is looked up in DNS, but adds no format guidance (bare hostname vs URL, subdomain handling or TLD expectations), leaving the agent to guess at input shape.

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 concrete verb chain (DNS lookup, then switch the page to the domain) that makes the tool's job unmistakable. It does not explicitly differentiate itself from the sibling set_custom_domain or get_custom_domain, which it sits between conceptually, so the boundary is left for the agent to infer.

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 implies the tool is used after the domain record exists ('fails until the record has actually propagated') and notes it is Premium-gated, which is useful eligibility context. However, it never states when to use this versus set_custom_domain or get_custom_domain, and gives no explicit when-not condition.

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