FeelingSurf

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

Annotations already declare the write/safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the description correctly focuses on behavior beyond that: the per-account label cap and the exact failure signal (403 `limit_reached`). That is concrete, actionable context an agent cannot get from annotations, though it omits auth requirements and duplicate-name behavior.

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

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

Two sentences, zero filler, with the core action front-loaded and the failure condition immediately after. 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 a simple 3-parameter creation tool with no output schema and full schema coverage, the description covers the essential action plus one important edge case. It is close to complete, though it could note whether a duplicate name errors or what a successful 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?

Schema description coverage is 100%, so name, color, and description are already documented, including the color enum. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Create a label') that an agent can immediately match to the create_label tool and distinguish from update_label/get_label/delete_label siblings. It does not explicitly contrast with siblings, 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?

The description gives no when-to-use guidance, prerequisites, or alternative tools. It never says to use update_label for existing labels or get_label/list_labels for reads, leaving the agent to infer routing from the tool 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 cover the safety profile (readOnly=false, destructive=false). Beyond that, the description adds genuine value: it discloses that new proxies start with `proven` false because FeelingSurfViewer validates before sessions, plus the 403 `proxy_limit_reached` cap behavior and 422 `validation_error` on duplicates. This is richer behavioral context than the annotations alone 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?

Front-loaded with the core purpose, then two dense sentences carrying validation and error semantics with no padding. Slightly compressed phrasing ('FeelingSurfViewer checks it before any session goes through it') but every clause earns its place.

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

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

For a 5-param create tool with no output schema, the definition supplies the mutation semantics, the initial `proven` state, and the two salient failure modes. Missing only an explicit statement of the response payload or required permissions, which are minor given the coverage.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including host/port validation rules, the type enum, and username/password socks5 constraints. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Add a proxy') and clarifies it 'registers a static proxy', distinguishing it from update_proxy and list_proxies. It does not name any sibling explicitly, but the registration semantics are clear enough to separate it from the related proxy tools.

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

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

The description implies insertion of a new proxy but gives no explicit when-to-use vs update_proxy or when-not-to-use condition. The error notes (duplicate host/port returns 422) implicitly tell the agent to use update when the proxy already exists, but this routing is left 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 readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds important behavioral context beyond annotations: exceeding the account's slot count returns 403 `site_limit_reached`, and the template_id merge behavior is shallow per top-level key. These are meaningful operational details not in 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?

The description repeats itself: 'Only `url` is required; every other field defaults to a new-site configuration' appears twice, and 'Fields for creating a site' duplicates the title. The template merge behavior is front-loaded well, but the duplication wastes space and muddies structure.

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 16-parameter creation tool with full schema coverage and annotations, the description covers the critical behavioral aspects: required field, default behavior, error on slot limit, and template merge semantics. No output schema exists, but the description doesn't need to explain returns for a creation endpoint. It's nearly complete, missing only explicit guidance on template vs manual configuration.

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 covers all 16 parameters with rich nested descriptions, so the schema does the heavy lifting. The description adds the template_id override semantics (shallow, per top-level key) which is valuable beyond the schema, but only marginally. Baseline 3 is appropriate given full schema coverage.

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

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

States a specific verb+resource ('Create a site') and clearly distinguishes from siblings like update_site and create_site_template. The duplication of the schema title ('Fields for creating a site') is wasteful but the core 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 says only `url` is required and others default to new-site configuration, which is useful context, but there is no explicit when-to-use or when-not-to-use guidance. It doesn't mention create_site_template as an alternative for reusing a template, nor when to prefer template_id versus individual fields.

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 profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond them: the all-optional-fields defaulting model and the specific failure mode '403 template_limit_reached' when the per-account cap is exceeded. It does not cover permissions/auth requirements or whether templates are mutable later.

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

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

The final two sentences ('Fields for creating a site template. Only `name` is required; all others default to a new-template configuration.') duplicate the second and third sentences almost verbatim, wasting roughly a third of the text. The quota error, which is genuinely valuable, is buried mid-description rather than front-loaded.

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

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

For a 12-parameter, deeply nested creation tool with no output schema, the description covers the essentials an agent needs (required field, defaults, quota error) and annotations carry the safety profile. It omits how a created template is used downstream and how it relates to create_site/update_site_template, leaving the agent with an adequate but thin picture.

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

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

Schema coverage is 100%, so the schema already documents all 12 parameters and the required array already marks name as required. The description's note that only name is required and everything else defaults is largely a restatement of structured data, so baseline 3 applies.

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

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

States a specific verb and resource ('Create a site template') and adds a useful definition of what a template is: a reusable bundle of site settings lacking url/paused/labels, which implicitly separates it from create_site. It stops short of naming a sibling 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: 'Only name is required; every other field defaults to a new-template configuration' tells the agent the minimum viable call. There is no guidance on when to prefer this over create_site or update_site_template, and no prerequisites beyond the quota note.

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 (readOnly=false, idempotent=false, destructive=false, openWorld=false), so the bar is lowered. The description adds genuinely non-obvious behavior: exceeding the per-account source cap returns 403 limit_reached, which an agent needs to anticipate and handle. It stops short of covering duplicate-name behavior or auth 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 with zero filler. The core purpose leads and the error condition follows, both front-loaded and easy to scan.

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-parameter creation tool with no output schema, the description covers purpose and one error case, and the schema covers inputs. It omits what is returned on success and how duplicate names or missing required fields are handled, leaving a modest gap.

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 both parameters (name, referer) are already fully documented with examples and stripping behavior. The description adds nothing about parameter meaning or format, so the baseline 3 is appropriate when the schema does all 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 and resource ('Create a traffic source'), which is unambiguous against siblings like create_label, create_proxy, and create_site. However, it does not differentiate itself from the sibling set beyond the noun, and the second sentence is error detail rather than scope clarification.

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 alternatives such as update_traffic_source or get_traffic_source, and no prerequisites or context about when a new source is warranted. The only conditional given is the failure mode when the account cap is hit, which is a constraint 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?

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=false. The description adds no behavioral context beyond that – it does not say what deletion entails (permanent removal, cascading effects, etc.). With annotations carrying the full safety profile, the description's lack of added value warrants a low score.

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

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

One short sentence with zero waste. It is front-loaded and appropriately concise for a simple delete action, though it borders on under-specification.

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 destructive tool, the annotations cover the safety profile and the schema documents the parameter. The description, however, omits confirmation of effects and when to use it over siblings, leaving minor gaps.

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% for the single id parameter, which is documented as 'Resource identifier.' The description adds nothing about the parameter, 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 ('Delete a label'), so the action is unambiguous. However, it does not distinguish this tool from sibling delete operations (delete_proxy, delete_site, etc.) or add scope beyond the title.

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 guidance on when to use this versus update_label, list_labels, or other delete tools, nor any prerequisites or conditions. The description provides only the basic action.

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 readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing on top of that — no mention of permanence, whether the proxy can be recovered, or any cascade effects — so it contributes no behavioral context.

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

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

The one-sentence description is essentially a restatement of the tool title 'Remove a proxy' with no added information. It is short, but that brevity reflects under-specification rather than economical writing.

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 delete tool with annotations covering destructiveness and idempotency and no output schema, the minimum needed to call it is present. It is still thin: nothing tells the agent whether deletion is permanent or what happens to dependent resources.

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

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

Schema description coverage is 100% for the single 'id' parameter, so the schema already documents it fully. The description adds no meaning beyond the schema, which is the expected baseline for full 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 ('Remove a proxy'), which is unambiguous on its own. However it offers no differentiation from the many sibling delete_* tools (delete_label, delete_site, delete_traffic_source), so an agent must rely on the name alone to route correctly.

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 update_proxy, restore_site, or the other delete_* siblings, and no prerequisites or cautions are given. The description supplies nothing beyond the bare action.

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 readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: no statement about whether deletion is permanent or soft, whether restore_site can undo it, what permissions are required, or what happens to dependent resources.

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

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

The single sentence is short but not concise in the useful sense — it is under-specified rather than economical, carrying zero information beyond the title. There is nothing to front-load because nothing is said.

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 tool, the description omits the one thing annotations cannot convey: whether the deletion is recoverable and via which sibling (restore_site, list_deleted_sites). The presence of restore_site makes that context highly relevant and its absence a real gap.

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

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

Only one parameter ('id') with 100% schema description coverage, so the schema fully documents the input. The description adds no meaning about the identifier (e.g., that it must be an existing, non-deleted site), so the baseline of 3 applies.

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

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

The description is a verbatim restatement of the tool name and title ('Delete a site'), adding no scope, target, or distinction from the 30+ siblings. It is more informative than 'Process' but still tautological, and it never clarifies what a 'site' is here or how this differs from delete_site_template or delete_proxy.

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 guidance on when to use this tool versus alternatives. The sibling list contains restore_site and list_deleted_sites, which strongly imply deletion may be recoverable and that a restore path exists, yet neither is referenced. The agent must infer all routing decisions.

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 readOnlyHint=false, so the safety profile is fully covered structurally. The description adds zero behavioral context beyond that — it says nothing about permanence, cascading effects, or recoverability. It does not contradict the annotations, but it contributes nothing.

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 short sentence, so there is no padding, but this is under-specification masquerading as conciseness rather than efficient communication. The one sentence does not earn its place by conveying any information the name and annotations don't already provide.

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 delete operation with no output schema, the description should at minimum note irreversibility or how to recover (e.g., list_deleted_sites/restore_site). It omits all of this, leaving the agent with only the annotations' destructive flag.

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 a single documented 'id' parameter, so the schema carries the semantic load and baseline 3 applies. The description adds no detail about which template identifier is expected or what happens if the id is invalid.

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 restates the tool name and title verbatim ('Delete a site template') without adding scope, target, or differentiation from siblings like delete_site or delete_label. The verb+resource is technically present, but it is pure tautology with no distinguishing information.

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 alternatives named, no prerequisites or conditions. An agent learns nothing about when this tool is appropriate versus delete_site or restore_site.

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 readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that — it doesn't say whether deletion is soft or permanent, whether it can be reverted, or what side effects it has on related data.

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

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

The single sentence is front-loaded and free of waste, but it is under-specified rather than genuinely concise — it essentially restates the title. There is no additional structure or information an agent can act on.

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 mutation with no output schema, the description should convey consequences (data loss extent, recoverability). Annotations carry the safety hint, but the description leaves an agent without any notion of what deleting a traffic source actually destroys.

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

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

Schema description coverage is 100% for the single required "id" parameter, so the schema fully documents the input. The description contributes no extra meaning beyond identifying the target resource, making the baseline 3 appropriate.

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

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

States a clear verb ("Delete") and resource ("traffic source"), so the agent knows exactly what the tool does. However, it offers no differentiation from sibling delete_* tools beyond the resource name already present in the tool name and title.

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 guidance on when to use this versus alternatives such as update_traffic_source or the broader restore_site pattern, nor any prerequisites. Usage can only be inferred from the tool name 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine content beyond them by disclosing that the response is a computed rollup with specific time windows (today / last 7 days) plus live session and slot-usage counters, which tells the agent this is an aggregated snapshot rather than raw records.

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. The first sentence names the operation and the second front-loads the most decision-relevant detail (the rollup and counters) rather than burying 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?

There is no output schema, so the description carries the burden of conveying return values, and it does list the major components. 'Account summary' remains unspecified, so an agent still cannot predict the full field set, but for a zero-parameter read tool the coverage is adequate.

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 of 4 applies. There is no parameter surface for the description to clarify or obscure, and the schema is trivially complete.

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

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

The description gives a clear verb+resource ('Get the authenticated account') and immediately enumerates what the payload contains (earn-side rollup, active session count, site-slot usage). It does not explicitly contrast itself with siblings like update_account or get_referrals, but the resource is unambiguous enough that an agent can separate it from the create/delete/list family.

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

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

Usage is only implied: an agent infers 'call this to fetch the current account's state.' There is no explicit when-to-use statement, no mention of prerequisites (e.g. requires authentication context, which is implied by 'authenticated'), and no named alternative such as update_account for writes.

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 nothing beyond that, not even a note on what is returned or error behavior for a missing 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?

It is short, but the single sentence is entirely redundant with the title and conveys no information, so it does not earn its place. Conciseness without content is under-specification, not efficiency.

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 read tool with annotations covering safety and full param schema coverage, the definition is barely serviceable but omits any return-value hint (no output schema exists) and any error/not-found behavior. It falls short of what an agent needs to use it 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 100% for the single id parameter, so the baseline is 3 per the rubric. The description adds no extra meaning (e.g., what a label id refers to), but the schema already documents the parameter adequately.

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?

"Get one label" simply restates the name and title verbatim without adding scope, format, or distinguishing context. It doesn't clarify how it differs from list_labels or get_* siblings beyond the implicit singular. This is the textbook tautology case.

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, when-not-to-use, or alternative routing guidance, despite a crowded sibling set (list_labels, get_proxy, get_site, etc.). The agent must infer that this is the single-resource fetch by 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description adds no behavioral context of its own, such as what happens on a missing id or whether the response is a single object.

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 short sentence with zero waste, but the brevity comes from under-specification rather than disciplined editing. There is nothing to front-load because there is almost no content.

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, fully annotated, and has complete schema coverage, which lowers the bar, but with no output schema the description should at least hint at what is returned or how a not-found id behaves. As written it is barely adequate for an agent to call correctly with confidence.

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 documented in the schema as a resource identifier. The description contributes nothing beyond this, so the baseline 3 for full schema coverage applies.

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

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

The description 'Get one proxy' is essentially a restatement of the tool name and title, adding no distinguishing detail. It does convey a singular retrieve-by-identifier operation, but an agent learns nothing beyond the name itself.

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

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

No guidance on when to use this versus the obvious sibling list_proxies, nor any prerequisites or conditions. The singular 'one' weakly implies it needs an id, but nothing states that an alternative exists for bulk retrieval.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by disclosing what the response contains (link, referral count, commission rate, credits earned) — important because there is no output schema to reveal the return shape.

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 and followed by the payload breakdown. The first sentence duplicates the title verbatim, which is mild waste, but nothing else is extraneous.

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, account-scoped tool with no output schema, the description supplies the missing return-value context an agent needs. Scope is implicitly the authenticated caller's own program; the description does not explicitly say whether it works when no referral program exists, which is a minor gap.

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 of 4 applies. There is nothing to mis-specify, and the description correctly implies no input is required by framing the call as retrieving 'your' program.

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

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

States a specific verb+resource ('Get your referral program') and then enumerates the concrete payload (referral link, referral count, commission rate, credits). It is unambiguous which resource it addresses, though it does not explicitly contrast itself with any sibling — which is acceptable here since no sibling covers referrals.

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: call this to read the caller's own referral program data. There is no explicit when/when-not guidance and no named alternative, but no plausible alternative exists among the siblings, so the omission is low-risk rather than misleading.

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 the useful detail that the return is the captured image itself, but says nothing about failure modes (invalid uid) or image format/size.

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, then the parameter derivation. 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 single-parameter, no-output-schema read tool, the description covers what it does, what comes back, and how to obtain the id. Only minor gaps remain (error behavior, image format), which are not essential to invoking 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 0% and the schema only says 'string', so the description carries the burden and does so well by defining uid as the last path segment of an images[].url from list_site_screenshots. It stops short of giving a literal example, but the derivation rule is actionable.

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 screenshot image) and clarifies the return is the image FeelingSurfViewer captured. It also implicitly distinguishes itself from list_site_screenshots by referencing it as the source of uids, though it never says so explicitly as a contrast.

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 tells the agent exactly where the uid comes from (the last path segment of an images[].url from list_site_screenshots), which effectively routes usage from the list tool to this one. No explicit when-not-to-use guidance is given, but the workflow context is clear.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no error behavior for a missing id, no note on deleted/restored sites, no return-shape context.

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 maximally short and front-loaded, but the single sentence is pure duplication of the title rather than content that earns its place. Brevity here reflects under-specification, not efficient communication.

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

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

For a one-parameter read tool with rich annotations and full schema coverage, the structured fields carry most of the load, so the definition is minimally viable. It still leaves an agent guessing about error/not-found behavior and whether soft-deleted sites are reachable.

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% (the single id parameter is documented as 'Site identifier.'), so the baseline is 3. The description contributes no additional meaning such as id format, valid ranges, or where ids come from.

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 is a verbatim restatement of the title 'Get one site', which is the textbook tautology case. It conveys the verb 'get' and the resource 'site', but no scope, format, or distinction beyond the singular/plural contrast implied by siblings like list_sites.

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 call this versus list_sites, get_site_template, or list_deleted_sites. The agent must infer that a specific integer id is required and that deleted sites may need a different tool.

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 the safety profile is covered structurally. The description adds no behavioral context at all — no error behavior for missing IDs, no mention of permissions or what is returned. For a read tool with annotations this is a real gap, though not a contradiction.

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 no waste, but its brevity stems from under-specification rather than disciplined editing. Nothing is front-loaded because there is nothing to load.

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 trivial (one required param, full schema coverage, rich annotations, no output schema), so the description is minimally adequate. It still leaves an agent guessing at sibling selection and what distinguishes a template fetch from a site fetch.

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 there is a single 'id' parameter documented as 'Resource identifier.' The description adds nothing about the identifier format (e.g., template ID vs site ID), so baseline 3 applies.

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

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

The description is a verbatim restatement of the tool title ('Get one site template') and adds nothing beyond the name. It does identify verb and resource, but there is no scope, no differentiation from siblings such as list_site_templates, and no detail about what a 'site template' contains.

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 mention of alternatives, no prerequisites. The agent must infer from the name alone that this is the single-resource counterpart to list_site_templates and get_site.

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 (readOnly, idempotent, non-destructive, closed world), so the description correctly focuses on other behavior: it is a fixed reference dataset of ~250 countries returned in full with no pagination, and it explains the semantics of `availability: none`. That return-shape and value-interpretation guidance is genuinely 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?

Three sentences, front-loaded with the resource, then the purpose, then the key caveat about `availability: none` and the return size. No filler and no 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?

With no output schema, the description compensates by stating the return cardinality (~250 countries) and that it is unpaginated, plus how to interpret the availability field. An agent has everything needed to call and use 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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 resource and scope: traffic availability per country, a read-only reference lookup. It is trivially distinguishable from every sibling, which are all CRUD operations on labels, sites, proxies, templates, and traffic sources.

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 use case – guiding a site's or template's location targeting – and implicitly frames when to consult it (before choosing targeting). It does not name an alternative tool or an explicit when-not condition, but no sibling overlaps this function, so the gap is minor.

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 non-openWorld, so the safety profile is fully covered. The description adds that system-owned shared defaults are also retrievable, which is useful context, but says nothing about behavior for invalid/nonexistent ids or error semantics.

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 immediately followed by the one non-obvious usage caveat. No filler.

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

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

For a single-parameter read tool with full annotation coverage and no output schema, the description covers purpose and applicability adequately. Only minor gaps remain (behavior on missing id, return shape), which are not critical given the annotations.

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% for the single id parameter, so the baseline is 3, but the description adds real meaning beyond 'Resource identifier' by noting that ids may refer to shared defaults (e.g. id 1, 'Direct visits'), expanding the agent's understanding of valid id space.

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

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

States a specific verb+resource ('Get one traffic source'), and the word 'one' implicitly distinguishes it from the sibling list_traffic_sources. It doesn't explicitly name the alternative, but an agent can tell it's a single-resource fetch versus a list operation.

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 clarifies the tool's applicability ('Works for your own sources and for the shared defaults'), which is genuine usage context, but there is no explicit when-not guidance or routing to siblings like list_traffic_sources or create_traffic_source.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: results are limited to the retention window, sorted most-recently-deleted first, and exclude downgrade-removed sites that self-restore. It stops short of stating what happens to entries that age out of the window.

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 load-bearing: the scope, the ordering guarantee, and the exclusion rule. Front-loaded with the core purpose and no filler.

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

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

For a simple two-parameter read tool with no output schema and annotations covering the safety profile, the description supplies the scope, ordering, and exclusion semantics an agent needs. Only the fate of sites past the retention window is 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 description coverage is 100% – limit and offset are fully documented with defaults, bounds, and clamping behavior in the schema. The description adds no pagination or format detail, so baseline 3 applies.

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

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

States a specific verb+resource (list deleted sites) and immediately qualifies it with the restore-eligibility scope, which distinguishes it from the sibling list_sites and pairs it with restore_site. An agent can tell exactly what set of entities is returned.

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?

Makes clear this is the discovery step for restorable sites and explicitly carves out downgrade-removed sites as out of scope, which prevents a wrong call. It does not, however, explicitly name restore_site as the follow-up tool or state prerequisites, so a 4 rather than 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 structurally. The description adds only the cross-reference fact about site `labels`; it says nothing about result size, pagination behavior, or ordering. Some added value, but thin.

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 primary purpose front-loaded and zero filler. Efficient, though the second sentence is a somewhat tangential cross-reference rather than the most valuable next detail.

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

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

With no output schema, the description should at least hint at what a label object contains or that results are paginated. Annotations and the schema cover safety and inputs, so the definition is workable but leaves the return shape 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 100% (limit clamped to 1..200, offset skip count with defaults), so the schema carries parameter meaning entirely. The description adds no syntax, ordering, or defaulting nuance beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('List your labels'), which is unambiguous against siblings like get_label and create_label even though it never names them. It is clear but lacks explicit sibling 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?

The second sentence explains that labels are referenced by id from a site's `labels`, which is contextual background, not guidance on when to call this vs. get_label or how to paginate. No when-to-use or when-not-to-use 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description contributes the ordering guarantee ('oldest first'), which is real behavioral context not present in structured fields, but says nothing about pagination or result volume.

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 immediately followed by the scope/ordering detail. No filler or restated title verbatim beyond the necessary noun.

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, zero-required-parameter list tool with annotations covering safety and a fully documented schema, the description covers what is returned (all account proxies) and their order. With no output schema, the exact record shape is unspecified, but that is a minor gap for a list 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?

Schema description coverage is 100% – both limit (clamped 1..200, default 50) and offset are fully documented in the schema. The description adds no syntax or interpretation beyond that, 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 ('List') and resource ('proxies') and adds scope: 'Every proxy on your account, oldest first.' The resource name alone separates it from sibling list tools (list_labels, list_sites). It could be sharper in distinguishing itself from get_proxy, 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?

There is no guidance on when to use this versus get_proxy (single item) or the other list_* siblings, and no mention of the pagination workflow the schema implies. Usage is only implied by the verb '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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds nothing beyond that — no note on pagination behavior, result ordering, or account scoping.

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 brief and front-loaded, but it is under-specified rather than concise — the single sentence carries no useful information beyond the tool name.

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

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

For a simple two-parameter list tool with rich annotations and a fully documented schema, the description still should clarify that it lists active sites and how pagination is expected. As written, an agent has only the name to go on.

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

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

Schema description coverage is 100% for both limit and offset, so the schema fully documents pagination semantics. The description contributes nothing extra, making the baseline 3 appropriate.

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

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

The description 'List your sites.' is essentially a restatement of the tool name and title, adding no scope, filtering behavior, or differentiation from siblings like list_deleted_sites or get_site.

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 guidance on when to use this versus list_deleted_sites, get_site, or list_site_screenshots. The agent must infer from the name alone that this returns active, non-deleted sites.

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 the safety profile is covered. The description adds genuine behavioral value beyond that by disclosing the result cap (24) and the fact that the list is not paginated, which directly affects how an agent should consume 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 short sentences, front-loaded with the purpose, then the origin of the screenshots, then the result-size constraint. No wasted wording, though the middle sentence about how screenshots were captured is more flavor than operational detail.

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 single-parameter list tool with no output schema, the description covers purpose, result cap, and pagination behavior. It could say a bit more about what each screenshot entry contains, but it is adequate 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?

There is a single required parameter (id) with 100% schema description coverage ('Site identifier.'), so the schema fully carries parameter meaning. The description adds nothing about the id beyond what the schema states, making the baseline 3 appropriate.

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

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

The description states a specific verb (List) and resource (a site's FeelingSurfViewer screenshots) and clarifies that these are screenshots captured while the app surfed the site. It implicitly distinguishes itself from the singular get_screenshot sibling via 'List', but never names that sibling explicitly, so 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?

It gives useful scoping context (most recent, up to 24, not paginated) but offers no explicit when-to-use guidance or comparison to alternatives like get_screenshot or list_surf_sessions. 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, fully covering the safety profile. The description adds nothing beyond that — no note on pagination behavior, ordering of results, or what a "site template" represents. It does not contradict 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?

A single short sentence that is trivially front-loaded, but it is under-specified rather than genuinely concise — the sentence earns its place only as a restatement of the title, carrying no extra 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?

This is a simple, zero-required-parameter read tool with rich annotations and no output schema. The description covers the bare minimum, but with no output schema an agent gets no hint about what the returned template objects look like or how pagination results are ordered.

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%: limit and offset are both documented in the schema with defaults, ranges, and meanings. The description contributes no additional parameter meaning, but the schema 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?

"List your site templates" restates the tool name and title almost verbatim, adding no distinguishing detail. It does contain a verb and resource, but an agent gets no information about scope, filtering, or how this differs from get_site_template or list_sites.

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 indication of when to use this tool versus the sibling get_site_template (single item) or the create/update/delete template tools. No prerequisites, exclusion conditions, or alternatives are mentioned, so the agent must infer everything from the 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: results are 'most recent first' and scoped to the caller's own instances with IPs exposed. It still says nothing about pagination behavior or result limits, which matters for a list endpoint.

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 no filler. Slight redundancy in repeating 'FeelingSurfViewer sessions' in each sentence, but nothing that wastes meaningful space.

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-required-parameter, read-only list tool with full schema coverage and annotations covering safety, the description supplies the remaining essentials: whose sessions, what ordering, and what data (IPs) is returned. No output schema exists, so a brief note on return shape would be the only meaningful addition.

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

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

Schema description coverage is 100%, with limit and offset fully documented including clamping and defaults, so the schema carries this dimension. The description adds no parameter meaning (no mention of paging, ordering interaction with offset, or max page size), leaving it at the baseline.

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

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

States a specific verb and resource ('List your FeelingSurfViewer sessions') and clarifies the scope: the caller's own sessions on the earning side, with their IPs. It is distinguishable from the sibling set, which contains no other session-listing tool, though it never contrasts itself with list_* alternatives like list_sites or list_proxies.

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 alternatives. The agent must infer usage from the name alone, which is adequate for a simple listing tool but falls short of explicit 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 readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds one useful behavioral fact – that results include shared/built-in sources, not just your own – but says nothing about ordering or return shape, so with annotations carrying the load a 3 is appropriate.

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 little waste; the core action comes first and the scope note follows. Slightly less crisp than ideal, but appropriately sized for a simple list 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 zero-required-parameter list tool with 100% schema coverage and annotations, the description supplies the key extra context (which sources are returned). No output schema exists but return composition is described; only minor details like ordering 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 description coverage is 100% with only two pagination parameters (limit, offset), both fully documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource ("List your traffic sources") and clarifies scope by noting it returns your own sources plus shared/built-in ones. This distinguishes it from get_traffic_source (singular), though it does not explicitly name sibling alternatives.

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 via the reference to a site's `traffic_sources`, suggesting this is how you obtain those ids. There is no explicit when-to-use guidance and no named alternative (e.g., get_traffic_source for a single source).

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

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

Annotations only declare the mutation profile (readOnly=false, destructive=false, idempotent=false). The description goes well beyond them by disclosing what is restored (settings), what is deliberately left suspended/empty (geo targeting, blocked domains, unsupported actions), and the two error codes with their triggers.

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, restoration semantics second, error conditions last. Every sentence adds information an agent needs and none 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 no output schema, the description covers the essentials for a single-parameter mutation: what it does, what state comes back, and the two failure modes. Annotations cover the safety profile, so nothing material is missing.

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

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

Only one parameter (id) with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the identifier's format or source (e.g., from list_deleted_sites), so baseline 3 applies.

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

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

States a specific verb (restore) and resource (deleted site) plus the effect on settings, so it is unambiguous against siblings like delete_site or create_site. It does not name list_deleted_sites, the natural precursor, so sibling 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?

The failure conditions ('Returns 404 once the retention window has passed, and 403 site_limit_reached when you have no free slot') give clear context for when the call is valid and what blocks it. No alternatives are named and no exclusions beyond the two error cases 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 the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), so the bar is lower. The description adds real value beyond that: the non-sensitive scope and the intentional exclusion of email/password/billing, which an agent would otherwise have to discover by failure.

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

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

Front-loaded and short, but the opening is redundant: "Update account settings. Update non-sensitive account settings... Writable account settings." says the same thing three ways, and "Provide at least one" is stated without connecting it to the parameter list.

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

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

With no output schema needed, a 6-param optional-only update tool whose annotations cover safety, the description supplies the missing pieces: what scope is writable and what is deliberately not. Only a note on the destructive/idempotent implications of clearing values 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 100%, so the schema already documents all six parameters, including the timezone null-clears-to-UTC behavior. The description only cites visit_own_sites and timezone as examples and adds no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource (update account settings) and scopes it as non-sensitive settings only, naming example fields. It implicitly separates from get_account and create_* siblings, 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?

Gives a clear precondition ("Provide at least one" setting) and explicit exclusions (email, password, billing are not editable via the API), which steers the agent away from unsupported attempts. No explicit routing to an alternative tool for those excluded fields.

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, readOnlyHint=false, so the safety profile is covered. The phrase 'provide at least one field' usefully implies partial-update semantics (omitted fields are left unchanged), but the description never explains what makes the operation destructive or which fields get overwritten.

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 very short sentences, front-loaded, with no filler. However, the first sentence is pure redundancy with the tool name/title, so it does not fully earn 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 annotations covering safety and a fully documented schema, most of what an agent needs is present. The gap is explanatory: nothing states that this is a partial update of an existing label, what happens to unspecified fields, or any permission requirement, which matters for a destructive mutation.

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

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

Schema coverage is 100%, so id, name, color (with enum), and description are all documented in the schema. The description only restates the 'at least one optional field' rule already implied by the required-only-id schema, adding no new semantics. Baseline 3 applies.

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

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

The description repeats the tool title verbatim ('Update a label') and adds only an input constraint, not a functional statement. Unlike sibling update_* tools, it gives no hint of what a label update touches or how it differs from create_label/delete_label. This is a tautology restating the name.

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?

'Provide at least one field' is a validity constraint on the call, not guidance about when to use this tool versus alternatives like create_label or delete_label. There is no context, no prerequisites, and no exclusions.

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

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

Annotations already flag destructiveHint and idempotent, but the description adds substantive behavior the annotations cannot convey: pausing/resuming clears `last_error` and its error history, and a resumed proxy is re-checked immediately, which can recover a proxy that was disabled after failure. That is meaningful side-effect disclosure 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?

Three sentences, front-loaded with the action, then side effects, then the alternative path. Every sentence carries information and none is redundant.

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

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

With no output schema needed and annotations covering the safety profile, the description fills the remaining gaps: mutation scope, destructive side effects on error history, immediate re-validation, and the workaround for unsupported edits. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a constraint the schema does not state: only `enabled` can change, framing `id` as the immutable resource reference. This meaningfully guides how the two parameters are used together.

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 and resource ('Pause or resume a proxy'), which cleanly distinguishes it from create_proxy, delete_proxy, get_proxy, and list_proxies. An agent can identify the tool's job without opening the schema.

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

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

Explicitly scopes the tool to toggling `enabled` and routes the agent elsewhere for other needs ('To change the host, port or credentials, delete the proxy and add it again'), naming the delete/add alternative. No explicit when-not conditions beyond that, but the boundary is clear.

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=true, and idempotentHint=true, so the mutation profile is covered structurally. The description adds the valuable partial-update semantic (only present fields change), but says nothing about what an update destroys or overwrites, which matters for a destructive-hinted 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?

Three short sentences with no filler, and the core update action plus the partial-update rule are front-loaded. It is efficient, though the middle fragment ('Writable fields of a site.') is a label rather than a full sentence.

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

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

For a 15-parameter tool with nested objects and no output schema, the description is thin: it never explains interactions between fields (e.g. limits, schedule, device splits) or the effect on unspecified fields beyond the PATCH hint. Annotations cover safety, so it is minimally viable rather than 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% across 15 parameters, so the schema carries the field-level meaning. The description only adds the generic 'writable fields' framing and the PATCH rule, which is baseline-level value rather than compensating for gaps.

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 ('Update a site') that distinguishes it from the many other update_* siblings, and the second sentence scopes it to writable fields. However, it does not distinguish it from sibling operations on the same resource (e.g. delete_site, restore_site) beyond the verb itself.

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

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

'For PATCH, provide at least one; only the fields present are changed' gives an implied usage rule for partial updates. It offers no guidance on when to use this versus create_site, restore_site, or get_site, so alternatives and preconditions are left 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 idempotentHint=true, destructiveHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds the meaningful merge semantics (only present fields are mutated), which is not derivable from annotations, but it omits permissions, validation failures, and what happens to omitted nested objects.

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 short and front-loads the operation before the partial-update rule. The middle fragment 'Writable fields of a site template' is a dangling noun phrase that reads like a leftover header and earns little, keeping it out of 5 territory.

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 13-parameter tool with nested objects and no output schema, the description is thin, but 100% schema coverage and the annotations carry most of the burden, and the PATCH rule fills the main behavioral gap. It is adequate but not complete.

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

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

Schema description coverage is 100%, so every one of the 13 parameters (including deeply nested limits, actions, schedule, and location_targeting fields) is already documented in the schema. The description adds no syntax, format, or constraint detail 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?

The first sentence states a specific verb+resource ('Update a site template') that cleanly maps onto the tool name and distinguishes it from the sibling create/delete/get/list site-template tools by naming the mutation. It does not explicitly route against update_site or create_site_template, but the resource 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 phrase 'For PATCH, provide at least one; only the fields present are changed' tells the agent it is a partial update and that at least one field is needed, which is genuine usage guidance. However, there is no explicit when-to-use versus create_site_template / delete_site_template / update_site, so the guidance is implied rather than comparative.

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 destructiveHint=true and idempotentHint=true, yet the description never mentions that this mutates existing data, whether omitted fields are preserved or cleared, or that the operation is idempotent. For a destructive mutation, the description adds essentially nothing beyond the annotations' safety profile.

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 second sentence carries a real constraint, though the description is arguably under-specified rather than optimally concise.

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, idempotent mutation with no output schema, an agent still lacks key facts: what happens to unspecified fields, whether the update is partial or full, and what a successful call returns. The description is too thin to cover this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'at least one field' note reinforces that name/referer are optional but adds no format or semantic detail beyond what the schema already documents (e.g., referer scheme stripping is only 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?

States a specific verb+resource ('Update a traffic source'), which cleanly distinguishes it from the get_/list_/create_/delete_traffic_source siblings. It does not, however, say anything about what a traffic source is or which fields are updatable beyond the generic 'field'.

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

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

The only guidance is the constraint 'Provide at least one field', which implies at least one non-id field must be supplied. There is no when-to-use context, no mention of prerequisites, and no routing against alternatives such as create_traffic_source or update_site.

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