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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is carried structurally. The description reinforces irreversibility ("cannot be undone"), which is useful confirmation, but adds nothing about what happens to associated stats/QR data or whether the delete is soft then purged.

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, zero filler, with the permanence warning placed immediately after the action. Nothing to trim and nothing buried.

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

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

For a single-parameter destructive tool with no output schema, the safety side is adequately covered by annotations plus the warning. The remaining gap is the missing identification of what `id` is and the absence of routing to the non-destructive sibling, both of which an agent needs before calling.

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

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

Schema description coverage is 0% and the description says nothing about the lone `id` parameter — whether it expects an internal link ID, a slug, or a full short URL. With one undocumented required parameter, the description needed to compensate and does not.

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 ("Permanently delete a short link") plus the permanence qualifier, so an agent immediately knows what the tool does. It does not distinguish itself from the sibling disable_link, which is the obvious non-destructive alternative, so it falls short of 5.

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

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

There is no guidance on when to use this versus disable_link or update_link, and no exclusions or prerequisites stated. The only hint is the word "Permanently," which implicitly contrasts with disabling, but the agent must infer that.

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 the real-world consequence the annotation cannot convey: visitors hitting an error instead of the destination. That plus the explicit reversal path (disabled=false) gives the agent useful behavioral context beyond the structured hints.

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

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

Three short sentences, no filler: the action and effect come first, the reversal mechanism second, the destructive consequence last. Every sentence earns its place and nothing is repeated across them.

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, non-read-only tool with no output schema, the description covers purpose, effect, and reversibility, and annotations cover the safety profile. Minor gaps remain — error behavior on invalid ids and whether re-enabling restores prior settings — but nothing essential to correct invocation is missing.

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

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

Schema coverage is 0%, so the description must carry the load. It clarifies the non-obvious polarity of the optional `disabled` boolean (false re-enables), which is genuinely valuable, but the required `id` parameter is never described — its meaning is only inferable from the name and sibling context.

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 ('Disable a short link') plus the observable effect ('so it no longer redirects'), which also implicitly separates it from delete_link and update_link by framing this as a reversible state toggle. An agent can pick this over its siblings without opening any schema.

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

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

The description explains how to reverse the operation ('Pass disabled=false to re-enable'), which implies this is the non-permanent alternative to deletion, but it never explicitly says when to choose it over delete_link or update_link. Usage is inferable but not stated, so it lands at the minimum-viable level.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the word 'account-level' and nothing about what data is aggregated, freshness, or cost of the call, so it contributes little beyond 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?

It is a single four-word fragment with zero waste, but it is under-specified rather than truly concise — there is no front-loaded verb telling the agent what action is performed.

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

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

The tool is simple (no params, no output schema, no nesting) and annotations carry the safety profile, so not much is required. Still, with no output schema the description should hint at what 'analytics overview' returns, and it does not.

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 is no parameter syntax for the description to document or omit.

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 the resource (analytics) and its scope (account-level), which implicitly distinguishes it from the sibling get_link_stats (link-level). However, it is a bare noun phrase with no verb, so it never states what the tool actually does with the analytics (fetch? summarize? export?).

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling get_link_stats as the link-scoped alternative. The agent must infer the account-vs-link split entirely from the title.

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

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

Annotations already establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered without the description. The description adds that results include country/device/referrer/daily breakdowns, which is useful return context, but it is vague ("the usual") and omits defaults, limits, or pagination.

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

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

Two tight sentences, front-loaded with the core purpose and followed by parameter and return details. "The usual" is the only slightly wasteful phrase, but overall there is little to trim.

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

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

For a read-only statistics tool with no output schema and 0% schema coverage, the description should say more about the returned shape (totals, date defaults, limits). It gestures at breakdowns but stays vague, so the agent can still call it correctly but not predict the response well.

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. It documents from/to format as YYYY-MM-DD and clarifies that both are optional, which the bare schema does not; id is left undescribed but is self-evident as the link identifier. Partial compensation merits a 3, not higher.

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

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

The description names a specific verb+resource ("Click statistics for one link id"), so an agent immediately knows it retrieves analytics for a single link. However, it never distinguishes itself from the sibling get_analytics, leaving ambiguity about which stats tool applies when.

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 use when you have a link id and want clicks, but gives no explicit when/when-not guidance and never mentions the overlapping get_analytics sibling or list_links as alternatives. The agent must infer routing on its own.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing about behavior beyond that: no mention of whether it returns a binary image vs a URL, whether the QR is persisted, or any 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?

Highly compact and front-loaded — action first, then parameter hints. The telegraphic style ('optional color, logo, print') is efficient but slightly clipped, bordering on note-form rather than a sentence.

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

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

With five parameters at 0% schema coverage and no output schema, the description should do more. It never explains the required id, the color value format, what logo/print actually toggle, or what the response looks like (image bytes? URL?), leaving real gaps for a download 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 0%, so the description must carry parameter meaning, and it does partially: it gives format values (png|svg) and names the optional color, logo, and print flags. However, the required 'id' parameter is never explained, color format (hex? name?) is unspecified, and the semantics of the boolean logo/print flags are not described.

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: 'Download a QR code for a link.' An agent can immediately tell this is a QR-generation/retrieval tool, distinct from sibling link-management tools. No sibling does anything similar, though the description doesn't say that 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?

No when-to-use guidance, no prerequisites, no mention of alternatives. Usage is only implied by the phrase 'for a link' and the id parameter. An agent must infer that this is called when a user wants a QR image for an existing link.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that results are scoped to the authenticated user (implying an auth requirement), but says nothing about pagination, result caps, or ordering for what is likely a long list.

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 short sentence with the scope qualifier front-loaded and no wasted words. It is efficient, though so terse that it edges toward under-specification rather than maximal helpfulness.

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

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

For a zero-parameter read tool with no output schema, the description should at minimum hint at the return shape or pagination behavior, since the agent cannot learn it elsewhere. It is functionally adequate but leaves the response contract completely unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; schema coverage is trivially 100%. Baseline 4 applies for a no-parameter tool.

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

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

Clear specific verb (List) plus resource (short links) and a scope qualifier (the authenticated user's). It is easy to understand, but it never distinguishes itself from siblings such as get_link_stats or get_analytics, which an agent must choose between based on the same resource.

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

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

There is no when-to-use guidance: nothing says whether this is the right tool for enumerating links versus fetching analytics or stats, and no exclusions or prerequisites are given. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write nature is covered. The description adds genuine value beyond that by disclosing UTM merge semantics ('merged without overwriting existing utm_* params'), a non-obvious behavior. It does not cover slug collision handling, required auth, or error behavior.

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

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

Two short sentences with no filler, and the core action is front-loaded ahead of the secondary merge detail. 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?

For an 8-parameter creation tool with no output schema and no parameter descriptions, the description is too thin. It omits the meaning of required and key optional parameters, conflict/error behavior, and any indication of what the response contains.

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 8 parameters and 0% schema description coverage, the description carries the full burden, yet it only touches the utm_* family generically. The required 'destination', plus 'slug' and 'note', are never explained, so the agent must guess whether slug is custom or auto-generated and what note is for.

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 first sentence states a specific verb and resource ('Create a short URL'), which is unambiguous. It does not, however, differentiate from the sibling shorten_urls (plural), leaving the agent to infer that this one creates a single link.

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

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

There is no guidance on when to use this tool versus shorten_urls or the other link-management siblings. The second sentence describes merge behavior, not usage context or prerequisites, so an agent gets no routing help.

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, destructiveHint=false and openWorldHint=true, so the write/non-destructive profile is covered. Beyond that the description adds no behavioral context: no maximum batch size, no behavior for duplicate slugs, no note on what happens on partial failure, and no output information (no output schema exists).

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

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

Two short front-loaded sentences with no filler; the core action is stated first and the parameter hint second. The brevity comes at the cost of detail, but the structure itself is clean.

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 bulk mutation tool with a nested item object, no output schema, and 0% schema coverage, the description omits critical call-time information: the required destination field, batch limits, and failure semantics. It is not sufficient for an agent to invoke this confidently.

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 only partially does. It names 'slug' and the 'utm_*' fields, but omits 'destination' — the sole required field in each item — and gives no format hints for slug or the array structure.

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 ('Bulk-create short URLs'), and the word 'Bulk' implicitly separates it from the singular shorten_url sibling. It does not name the sibling outright, but an agent can infer the distinction from the plural name and 'Bulk' qualifier.

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

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

The word 'Bulk' implies this is the tool for multiple URLs while shorten_url handles one, but the description never states when to prefer this over the sibling, whether there is a batch-size limit, or whether partial failures are tolerated. Usage is only implied, not guided.

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 supply the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), lowering the burden. The description's only added signal is the implicit partial-update semantics conveyed by 'or', but it never states explicitly whether omitted fields are preserved or cleared, nor what happens on an unknown or 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?

A single front-loaded sentence with no filler, and the field list is compacted via 'UTM fields' rather than spelled out five times. The trailing 'for a link id' is slightly awkward but costs nothing.

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

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

No output schema exists, so the description need not explain returns, but for a 10-parameter mutation with 0% schema coverage it should say more about partial vs full update behavior, clearing values, and id expectations. It is adequate as a field list but thin as a behavioral contract.

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 load, and it effectively names every mutable parameter (destination, slug, note, utm_* fields, disabled) and identifies id as the key. It stops short of format or validation detail, e.g. whether destination must be a full URL or how slug collisions are handled.

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 (update) plus resource (link) and an enumeration of the mutable fields, so the agent knows exactly what the tool changes. It does not, however, distinguish itself from the sibling disable_link even though the description claims it can flip the disabled flag, leaving a routing overlap.

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 statement of when to use this tool versus disable_link, delete_link, or shorten_url, all of which act on links. The reader must infer that this is the general-purpose field editor while the siblings are single-purpose shortcuts.

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